ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes: > In a retaliation construction, if a party misbehaves, the other party gets > the entire amount they are working on together, as disincentive for any party > to cheat. > > That works for the two-party case A and B. If A cheats, B gets money. > > How do you extend that to the three-party case A B C? If A cheats, what > happens? > > Suppose the correct current state is A=2, B=99, C=3. Suppose A cheats > and attempts to publish A=102, B=1, C=1. C detects it because B is > asleep at that time. Does C get to claim the money that A claimed for > itself, basically 101+1 and thus 102? But the correct state has > almost all of the money assigned to B instead. Obviously that is > unjust. Instead C should get to claim only 3 from A (its 3 in the > final state) in addition to its 1 in the published state, and should > give the 99 to B. So now B also needs another retaliatory > construction for the case "A cheated first and C found out and and > also cheated me", and a separate construction for "A cheated but C was > honest". And that is separate construction for the case "C cheated > first and A found out and also cheated me" and a separate construction > for "C cheated but A was honest". > > As should be obvious, it does not scale well with number of > participants on a single offchain "purse"; it quickly becomes complex > fast.
The need to identify the misbehaving party and punish just that one party could be addressed by having pre-committed retaliation transactions. However this results in a large number of pre-committed transactions that need to be carried around just for the case that someone really misbehaves. In addition colluding parties may be able to punish each other when an cheat attempt seems doomed to fail, which reduces the cost of the attack. This could also be partially fixed by pre-committing retaliation transactions that split the misbehaving party's funds. Overall a very unsatisfactory solution. > Retaliatory constructions however have the major advantage of not > imposing limits on the number of updates that are allowed to the > offchain "purse". Prior to Rusty shachains it was thought to require > storage linear in the number of updates (which could be pruned once > the channel/"purse" is brought onchain), but Rusty shachains also > require O(1) storage on number of updates. Thus retaliatory > constructions are used for channels. > > Note that channel factories, to my understanding, can have the Duplex > construction near the root of the initial onchain anchor transaction, > but be terminated in Poon-Dryja retaliatory channels, so that a good > part of the current LN technology has a good chance of working even > after channel factories are implemented. This strikes me as a good > balance: restructuring channels is expected to be much rarer compared > to updating them normally for normal usage, so each construction plays > its own strengths: the Decker-Wattenhofer construction which imposes a > limit on the number of updates, but has no limit on number of > participants, is used for the rarer. massive "channel restructuring" > operations, while the Poon-Dryja construction which imposes a > practical limit on number of particiapnts, but has no limit on number > of updates, is used for "day-to-day" normal operation. That's not as bad a tradeoff as people usually interpret, the DMC construction has parameters that allow tweaking the number of invalidations, and with parameters similar to LN we can have 1.4 billion updates. Which is years of operation without need to re-anchor. In addition penaltyless invalidation has a number of advantages, for example it doesn't have the state asymmetry inherent in LN and there is no toxic state information that, when leaked, results in your funds being claimed through a retaliation. This happened to me btw last month when I accidentally restored a wallet from backup and attempted to reconnect. Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
