Announcing Des Coin: the first bitcoin meetup in Des Moines, Iowa
We are a group of bitcoiners who meet to use bitcoin and spread use of bitcoin throughout our community. Steak n Shake recently started accepting bitcoin. Let's meet at the Steak n Shake, pay for our meals with bitcoin, and discuss bitcoin as well as ways to grow adoption of this special currency within Des Moines.
If you know someone in or around Des Moines who might be interested in bitcoin, tell them about this meetup!
https://www.meetup.com/des-coin-bitcoin-meetup-in-des-moines/
Also, your app is really cool -- I shilled it here:
and here: https://x.com/SuperTestnet/status/1929653539430715715
Someone made a cool nostr app called Liquiditystr. It's a FOSS market for LN channels, similar to Liquidity Ads or Lightning Pool but (1) it runs on nostr (2) it's web friendly (3) buyers need not run special software. Oh yeah, and you can earn money with it by "becoming" an LSP!
Peep the frontend here: https://liquiditystr.space/
The backend is called PubLSP and you can run it on your computer: https://github.com/smallworlnd/publsp
If you do, your LN node will advertise the rate at which people can buy or rent a channel from you. Thus *you* can be an LSP and an alternative to buying channels from big companies like Acinq or Voltage.
Buyers can sort the offers by price and buy a channel from whoever offers the best rate. If you think the LSP marketplace is too concentrated and want to earn money while also helping the lightning network become more resilient and more private, run PubLSP!
Check it out today!
Frontend: https://liquiditystr.space/
Done -- thanks!
sounds like we'd have corn in common
I am working from a local library in Des Moines, Iowa. If anyone knows any bitcoiners in this area who would like to cowork, hit me up!
I'm not sure what you mean by "alone." I think you mean something like, "does lnproxy use 2 proxies automatically like how obscuravpn automatically passes your traffic through 2 vpns." If that is what you mean, no. But there are 2 different proxies running lnproxy's software and you can pick which one you want to use on their website, otherwise it selects onr at random. So nothing stops you from wrapping your invoice twice, once via each proxy. Moreover, anyone who starts running the lnproxy software can do a pull request to get added to their list, and the more people who do so, the better for user privacy.
> the sender doesn't know what happens afterwards, therefore trackign isnt possible
Chainalysis managed to do it multiple times in the attached video, starting at 26:55.
They start with the easy "first step" where Morphtoken told them they sent the money to the perp. From there, they trace it forward four times. At 30:43 they identify a payment from the perp to either ChangeNow or Liquid Exchange; at 32:49 they identify a payment from the perp to Exodus Wallet, though they say even their advanced tracing software was not able to generate high confidence for this particular trace, and they aren't sure where he sent it, nor which output was his change output.
The trail runs cold for that particular txo, so at 34:55 they go back to the drawing board and identify a different "first step" where Morphtoken told them they sent money to the perp. At 35:08 they conclude that he sent this txo to one of two places: Exodus Wallet or a mining pool.
From there, they successfully identify his change output (at 36:36) so they continue tracing the perp's money, where they learn -- at 36:51 -- that sent his money to a centralized exchange or a merchant's point-of-sale website. One of those confirmed that he sent his money to them and that they had his identity info, which is how they nabbed him.
So yeah, saying it "isn't possible" is completely false -- Chainalysis sometimes manages to do it and there is a video explainer of how they do it with plenty of screenshots so you can follow what's going on.
One nice thing about vpns, and lnproxy, is that they stack. You can put multiple vpns in your network stack, so that first your traffic goes to VPN A and then the VPN B and then to your destination. You can do the same with your money: first it goes to proxy A, then proxy B, then your destination. No proxy knows if the node they forward your money to is the real destination or just another proxy.
Sure, watching to see what happens next is *critical* but sending the money in the first place is *also* a critical part of the trace, unless you can find someone who already sent money to your target. You need a pubkey to watch -- where so you get it? Either by paying it yourself or finding someone who already did. You don't get to exclude that critical step in almost every trace just because you find it inconvenient that monero makes it easy.
> you can do the first half (send dust!) but not the second (know what happens next!) therefore it is not tracing
First half of what? If your answer is "first half of tracing" then QED, sending money and identifying the destination is part of tracing. And that is what your answer "should" be because dust attacks are a perfect example of tracing -- a textbook example. And they completely rely on what you call "the first half." It's a critical step of practically every trace except ones where someone you're working with already sent the target some money.
> in what way is it "crackable"?
I answer in this post:
> How about I'll pick a transom and you'll "crack" the true spend?
Sure, I'll do my best! I wrote a free and open source tool for this -- you can paste any monero tx and it will try to identify the true spend: https://github.com/supertestnet/examiner
It doesn't usually find it but sometimes it does. Give me a tx and I'll try it!
Then you do my challenge, OK? The one where you pay a lightning invoice of my choice and tell me (1) the recipient's pubkey (2) the total balance held by that pubkey -- i.e. the same info I can get by paying a monero address
For future reference, here is the invoice I'd like you to pay after I've completed your challenge:
lightning:lnbc10079970p1p5rhqjdpp5wmje0gndr5cmnxwzala7jmuc3jylc33ef4kyhurgx5fdjks3rkwshp5he4v6k88ag5vmms9j7z43lc4u8apl0qd8ftdx2zqzdmtx596x60scqzdyxqrrxssp55gdlkuh6zp2mxx8sqwcz4372y7vhc757pn6rzf0y779e2k8c2yfs9qxpqysgqzl2v27xj5jzm8x45wt6kzkcnxnakmac5xy0c40y79jw6v2s43vqqcv9jralfaz7dl6nxkp0r8qxm7rwppydrfm2spmtu3f24thk5nycq9a9upl
A wild XMR challenge approaches! Nostr user nostr:nprofile1qqs0npwnpyvheqz7zuvuwvv9k460c0hyqlturds40hhfn34vufvehwcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmjv4kxz7fwdehhxarj9e3xzmnyqyw8wumn8ghj7mn0wd68ytfsxyh8jcttd95x7mnwv5hxxmmds76tlq challenges me to identify the true sender of a monero transaction of his choice. I agree to the challenge and await his tx. I also offer him a counter-challenge when I'm done with his: pay an LN invoice of my choice and tell me the receiver pubkey and its total balance -- i.e. the same data I get by paying a monero address. What will happen? Find out on nostr!
> in what way is it "crackable"?
I answer in this post:
> How about I'll pick a transom and you'll "crack" the true spend?
Sure, I'll do my best! I wrote a free and open source tool for this -- you can paste any monero tx and it will try to identify the true spend: https://github.com/supertestnet/examiner
It doesn't usually find it but sometimes it does. Give me a tx and I'll try it!
Then you do my challenge, OK? The one where you pay a lightning invoice of my choice and tell me (1) the recipient's pubkey (2) the total balance held by that pubkey -- i.e. the same info I can get by paying a monero address
For future reference, here is the invoice I'd like you to pay after I've completed your challenge:
lightning:lnbc10079970p1p5rhqjdpp5wmje0gndr5cmnxwzala7jmuc3jylc33ef4kyhurgx5fdjks3rkwshp5he4v6k88ag5vmms9j7z43lc4u8apl0qd8ftdx2zqzdmtx596x60scqzdyxqrrxssp55gdlkuh6zp2mxx8sqwcz4372y7vhc757pn6rzf0y779e2k8c2yfs9qxpqysgqzl2v27xj5jzm8x45wt6kzkcnxnakmac5xy0c40y79jw6v2s43vqqcv9jralfaz7dl6nxkp0r8qxm7rwppydrfm2spmtu3f24thk5nycq9a9upl
List of people who say that tracing includes sending money to a pubkey or address and watching it to see what happens next:
- Chainalysis
- Coinbase
- Gemini
- Wikipedia
- Bitcoin wiki
Many sources: https://www.google.com/search?q=%22dust+attack%22+or+%22dusting+attack%22+%22to+trace%22+or+%22tracing%22+%22bitcoin%22
List of people in denial:
- Kanzan
> [that] isn't "tracing the payment
Yes it is, it is the first step in very many traces. Everyone knows this, e.g. here's a coinbase article explaining how dust attacks are part of many traces -- and they rely on the sender's ability to know the destination of their funds. Lightning, of course, fixes this.
https://cdn.nostrcheck.me/dde1dd228d19983b35f01fc2a510601fc1dc2538143424fc0aaad845f441a33a/dd3df333a39d3802ec8fe4225564b73db8379023bd37021f4213c62bc2d3b554.webp Thanks master, I believe you mean "blinded paths" in Zeus invoices settings, rigth?
Correct
Even when you use monero over tor, the sender still has to publish his transaction info on the blockchain, including (1) the sender's pubkey (2) the recipient's pubkey. That is bad for the privacy of both parties. So don't do that. Lightning fixes this.
> Smart people don't want a "layer 2"
Smart people don't want to publish all of their transactions for everyone to see (and analyze)
> How is that a use case, let alone a non-niche one?
It is a use case because many people get in trouble due to the sender disclosing info about the recipient to the police. E.g. read this case about tracing a monero user from Finland: https://www.reddit.com/r/Monero/comments/19emsfe/finlands_national_bureau_of_investigation_claims/
The Finnish police "made an information request to the [monero user's] exchange." It was an anonymous exchange, so they did not have his identity, but they did have his monero public address and his on-chain pubkeys, because he withdrew from the exchange to his self-custodial wallet. The exchange gave that info to the police, who watched the blockchain to see where the money went next, and traced it to Binance, a KYC'd exchange, where they got his identity info and arrested him.
The first step in this case was asking the sender (a no-KYC exchange) for whatever info they had about the recipient. Since they knew what pubkey they sent the money to, they were able to give this info to the police, and it was very useful to them. So it's not "niche" -- it's a verhy common thing for the sender to log info about the recipient, and among exchanges, it's very common to share that info with law enforcement officers.
Not letting exchanges have that info in the first place is very good for your privacy, and lightning makes this easy: you can give the exchange an invoice with a decoy pubkey in it, so that it doesn't even belong to you, but even if you *do* give them a pubkey that belongs to you, your future transactions don't show up on a blockchain, so there's far less info for them to track.
> is [there] some time where you need to not know where you're sending money?
Yes, the above example is precisely that kind of scenario: the non-KYC exchange in the Finnish case did not need to know what pubkey received their money. Lightning gives us a way to get the money to the right guy without revealing his pubkey to the sender. So why not do that? Why not adopt this superior privacy technology when the alternative is to keep using monero and keep going to jail?
> what are you asking the devs to encrypt here that they haven't already? In other words, what's the problem?
I recommend the devs (1) implement payment channels so the sender can create his payment data on a second layer instead of the base layer (2) implement onion routing between payment channels so that even the sender's channel counterparties aren't in a position to know if he's the sender or not (3) within those channels, actually encrypt all communication between counterparties so that ISPs can't read it (4) do not publish payment data on a blockchain, not even the encrypted blobs transmitted between channels
Or, you can just use lightning, because it already has all of those features
by "unencrypted" I mean this: (1) all 16 members of the ring signature are provided in plaintext -- everyone can see them (2) the "real" sender is definitely one of them -- only 15 ring members are decoys, you can't make them "all" decoys because, as part of monero's design, you must put the real sender's pubkey in the ring signature
by "crackable" I mean this: chain analysts can use data from their own wallets and those of their partners to eliminate some of the decoys in the ring signature -- e.g. if one of the decoy pubkeys belongs to them, and they know they didn't sign the transaction, they can remove that decoy, thus narrowing down the list of possible senders. Often, they can narrow it down to just one person, thus "cracking" monero's ring signature privacy and identifying the real sender. Here is a video where they do this multiple times, starting at minute 26:55
Monero is designed to protect the sender's info from the receiver, but unfortunately it uses a crackable, unencrypted "1 out of 15" technique. It also makes no attempt to hide the receiver's info from the sender; in fact, the receiver's pubkey is published in plaintext for all to see.
By contrast, lightning is designed to protect the sender's info from the receiver by (1) actually encrypting it, (2) using onion routing, and (3) not publishing anything.
The same techniques also protect the receiver's info from the sender, plus lightning's design makes rendezvous routing easy. This technique lets the receiver easily give the sender an invoice with a decoy pubkey in it, so that even if they DO find the node associated with that pubkey, it's the wrong person's pubkey.
Monero: designed to protect the sender's info from the receiver -- but unfortunately uses a crackable, unencrypted "1 out of 15" technique -- and makes no attempt to hide the receiver's info from the sender (the receiver's pubkey is published in plaintext for all to see)
Lightning: designed to protect the sender's info from the receiver by (1) actually encrypting it (2) using onion routing (3) not publishing anything -- and also protects the receiver's info from the sender through the same methods, plus it makes rendezvous routing easy, allowing the receiver to easily give the sender an invoice with a decoy pubkey in it (so that even if they DO find the node associated with that pubkey, it's the wrong person's pubkey)