pull down to refresh

21 sats \ 1 reply \ @Murch 19 Feb 2023 \ parent \ on: Lightning Channels with more than 2 peers? Could 3 ways be better? bitcoin
The Lightning Network currently guarantees that any conflict can be resolved fairly or to the detriment of a cheating party. You introduce the new assumption that channel participants trust their counterparties. If we trust each other, we may as well use a custodial solution or shared ownership of a single Lightning Node—you don’t need a multiparty channel at all.
If you however wish to solve the conundrum of multiparty channels with the same security assumptions as used by the Lightning Network today, you need a cryptographic protocol that guarantees a fair outcome in all cases, e.g.
  1. All three parties are collaborating
  2. All three participants are unavailable
  3. A single participant becomes temporarily unavailable, the other two want to update the channel
  4. A single participant becomes permanently unavailable
  5. Two participants are unavailable
  6. Two participants are unavailable permanently
  7. A single participant is unavailable, another party tries to cheat
  8. Two participants collude to cheat the third party
  9. Two participants collude to cheat the third party that is currently unavailable
  10. Two participants are temporarily unavailable, the third participant cheats
  11. …
write
preview
21 sats \ 0 replies \ @l0k18 OP 19 Feb 2023
yeah, the whole thing about how LN runs "hot" is problematic. Sometimes stuff gets out of sync. I'm sure there is many more things, the 3 node channels idea was just about improving path efficiency and chain transaction costs.
It reminds me of a whole stream of ideas I've been cooking up over the years related to precisely providing adequate experience without more or less signing a contract with the devil in the blood of your firstborn.
Nostr, for example, is a distributed generic event log. It could do things especially for async issues like about half the issues you name above.
I just got done building two neat little cryptographic protocols for source routed onion relay network. The more I dig into this stuff the more I realise how broad the horizon actually is.
Also, on my subject of post: I don't think the guarantees of 2 party 2 of 2 multisig based channels is any different from 3 of 3 in any real, material way, while cutting 1/3 of your message cost over the whole network and enabling shallow transparency of channel balances.
What does someone do if it is necessary for them to close a channel? Or if they simply can't run their server for a day here and there. LN doesn't really prescribe punishments for absentees. Payments fail, counterparty gets antsy about logs full of failed payment probes and attempts.
Almost all bad scenarios with LN involve active, not passive attacks. Humans are lazy. Half of them are even lazier than that. Fat fingers close channels accidentally. Sometimes misunderstood configuration options too.
More work needs to be done on the cryptographic/game theory protocols to advance things. I'm pretty handy at this kind of thought process, and just got done with two small pieces that are central to Indra. I'm staring at my IDE wishing I could get back to solving cryptographic protocol problems and not boring crap like implementing empty, mostly boilerplace APIs, managing configuration, persisting state.
reply