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.