<div>Good morning Alejandro,<br></div><div><br></div><div>There is no assumption involved, merely a large number of questions.<br></div><div><br></div><div>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.<br></div><div><br></div><div>That works for the two-party case A and B.&nbsp; If A cheats, B gets money.<br></div><div><br></div><div>How do you extend that to the three-party case A B C?&nbsp; If A cheats, what happens?<br></div><div><br></div><div>Suppose the correct current state is A=2, B=99, C=3.&nbsp; Suppose A cheats and attempts to publish A=102, B=1, C=1.&nbsp; C detects it because B is asleep at that time.&nbsp; Does C get to claim the money that A claimed for itself, basically 101+1 and thus 102?&nbsp; But the correct state has almost all of the money assigned to B instead.&nbsp; Obviously that is unjust.&nbsp; 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.&nbsp; 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".&nbsp; 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".<br></div><div><br></div><div>As should be obvious, it does not scale well with number of participants on a single offchain "purse"; it quickly becomes complex fast.<br></div><div><br></div><div>Retaliatory constructions however have the major advantage of not imposing limits on the number of updates that are allowed to the offchain "purse".&nbsp; 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.&nbsp; Thus retaliatory constructions are used for channels.<br></div><div><br></div><div>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.&nbsp; 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.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div>