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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
