• 0 Posts
  • 247 Comments
Joined 2 years ago
cake
Cake day: March 10th, 2024

help-circle











  • Ah, I see what you mean. Yes and no. The receiver does need to somehow communicate the destination to the sender, I believe typically through an invoice of some sort. Been a long time since I kept up, so the details are getting hazy. Anyway, there are only two times that lightning network usage requires a publicly visible blockchain transaction: when you want to put coins on the lightning network and when you want to take them back off to the blockchain. You open a channel with a node basically saying “I’ll put X amount in this channel in if you’ll put in Y amount (one of them can be zero, i.e. send or receive only), and here’s a signed transaction you can publish on the blockchain to get your money back at any time.” Any time you make a transaction over the lightning network, you rewrite that cashout transaction so the balance shifts by however much you’re sending plus any fees you agree to pay, but you do it in such a way that you only really give them the signed transaction if they prove they’re gonna pass on what you want to send to the next node, and this process repeats with every node in the chain until everyone agrees to move the money.

    All that to say there’s really no record of any transaction ever happening outside of however your balance changes between putting it on the network and taking it back off. There’s no record of who sent what, how many transactions it took, what path any transaction took to get there, nothing at all except initial and final balance. Now, this does mean that if the money is withdrawn, there’s evidence you’ve been paid, but not for what, by who, by how many people, over how many transactions, or a anything else but the final total amount from all transactions. If they just spent everything they received back over the lightning network, there’s effectively no real evidence that any real transactions ever occurred.

    Of course, this hypothetical nonprofit is almost certainly going to be paying a company that wants US dollars. They’ll probably have to cash out in a highly traceable way, and actually buying the ICE data will require a highly traceable bank transfer or other conventional payment method. In that sense, you’re right, the nonprofit gets left exposed. But they could completely mask who sent money.



  • That’s a good point, they’d definitely just subpoena your bank records. If crypto is used properly, it can be nigh impossible to trace, though. Bitcoin isn’t very private at all on the blockchain, but if you send over lightning network, my understanding is that it becomes effectively impossible to track, unless your adversary controls enough lightning network nodes to track the payment as it bounces between nodes. They wouldn’t need to control the whole path, but they would need to control nodes VERY close to origin and destination, ideally the adjacent nodes, and enough of those in the middle to be reasonably sure they can accurately follow the money. The lightning network doesn’t leave a detailed ledger behind, so only way to trace a payment is to be involved in its processing, which means controlling the nodes the money passes through on its way to the recipient.

    Of course, that’s way too obscure and unknown for the vast majority of people, so I don’t see a nonprofit succeeding that way these days. Maybe if crypto actually does get mainstream, but that’s still a pretty big if.







  • I think the dev gave up on this when they learned about Nostr. I was really interested in Secure Scuttlebutt (SSB) for a while, but it’s been a while since I looked around, so take what I’m about to say with a grain of salt, I may be iffy on the details.

    SSB was a really cool idea, and I loved the idea of a gossip protocol. The implementation had its drawbacks, though. For example, users had a cryptographically signed and linked feed that helped ensure complete propagation of a user’s unedited content, but it couldn’t handle the consequences of a feed forking, which made multiple devices for one user on an offline-first protocol very difficult to work with because you couldn’t really guarantee that two or more clients for one feed were properly synced.

    So there was an attempt to develop an SSB v2 of sorts to address some of these shortcomings. I believe the author of Manyverse was one of the people working on that. The project was never formally named to my knowledge, but you can probably still find vestiges of it on github, particularly under the Manyverse author’s profile, for something with a name like PPPPP. At some point, though, it was discovered that another protocol had been inspired by SSB and had solved a lot of the problems they wanted to address in SSB. I’m pretty sure that protocol was Nostr. Last I knew, once that had been discovered, interest in developing PPPPP and maintaining SSB clients dropped off significantly. A bit of a shame as the SSB community was VERY different from the Nostr one. Probably still some of them left using it, but I don’t see it growing the way I wanted it to at this point.