ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-05 📝 Original message: Good morning Alejandro, ...
📅 Original date posted:2018-04-05
📝 Original message:
Good morning Alejandro,
There is no assumption involved, merely a large number of questions.
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.
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180405/21fe4178/attachment.html>;
📝 Original message:
Good morning Alejandro,
There is no assumption involved, merely a large number of questions.
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.
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.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180405/21fe4178/attachment.html>;