Replying to Avatar waxwing

I was recently trying to remember something about lightning: how "LN penalty", the current mechanism, makes multiparty channels not work. This is what I came up with:

Suppose A B C are in a multiparty channel and each hold commitment transactions of the normal form: output 1: to remote X, output 2: (to local Y after time delay, to revoc. secret Y immediately). The obvious problem is, "to revocation secret" - *whose* revocation secret? Obviously "Alice gives revocation secret to Bob and Charlie" makes no sense; then they're competing over the punishment funds.

A little thought and you might come up with "split it equally". So the idea there would be, instead of "to me after delay OR to to them with revocation secret", change it to "to me after delay OR to a multisig script for A and B and C with revoc. secret" and, to revoke old state, as well as sending revoc. secret, sign a payout, from that script, to B and C with a 50/50 split. Setting aside a counterparty going offline, this is still terrible: imagine Alice tries to revert from having 0% of balance to having 100%, then the punishment gives 50% to B and 50% to C. But if Bob was colluding with Alice, Alice now has e.g. 25% (half of Bob's share of the punishment). I'm deliberately glossing over how the B and C balances were at the time of the contract breach, because even this is enough to see that it plainly doesn't work to just say "split the punishment between the honest parties".

This is why both covenants and sighash_noinput ideas are powerful: they can push state forwards, i.e. "enforce a contract" rather than "take corrective action when a contract is broken".

The latter requires *justice*, which is to say, it requires apportioning blame (if A breached, A is clearly to blame, but that doesn't mean B and C aren't!). The former does not; at least, if the contract is well written.

I'm not a technical person. But I recently came across the Nucleus propasal. It seems like an amazing improvement.. Any chance we could see some multiparty channel implementation in the near future?

Reply to this note

Please Login to reply.

Discussion

Thanks for the heads up, I hadn't looked at it.

I share harding and Zman's suspicion that this kind of construction is unlikely to work with a majority voting mechanism. Sorry for the slightly boring opinion there :)

It's interesting on this topic, that we still don't have any functioning kind of coinpool/joinpool setup today. There's some threshold of interactivity complexity that current LN sits under because it sticks resolutely to 2 party relationships, and which coinjoin sits under because it has no cross-block interactivity or game theory assumptions for funds safety, but these more complex ideas sit above and so somehow never get implemented. (In case it wasn't obvious, that whole paragraph is basically my *guess*).

nostr:nevent1qqsws3g3qgxaz4k22zmqpn3y3zlup5l5p8mjza3wed3nwuzmzr5568cpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgs0f69gx2y9mlkrcy2v66d8t3qnm952xxwv2gtyvek38ed59zr042qrqsqqqqqpdtetgl