Good morning Michael,
> A couple of follow ups please:
>
> 1) Poon-Dryja (LN penalty), Decker-Wattenhofer and Decker-Osuntokun-Russell
> (eltoo) just refer to the process for claiming funds when an old state is
> broadcast? Poon-Dryja doesn't require a soft fork but
> Decker-Osuntokun-Russell does?
They are different channel protocols with various tradeoffs. Poon-Dryja, as
mentioned, does not have a CSV that interferes with transported contracts, and
generally can get away with smaller practical timeouts on unilateral closes.
Decker-Wattenhofer channels have no "toxic waste", i.e. old transactions that
are dangerous for you to accidentally use or malicious third parties to
maliciously use, and can use existing Bitcoin, but timeouts on unilateral
closes are longer and need to be the same for both parties, also that timeout
affects HTLC delay routing (the highest such timeout on a route is added to the
total practical HTLC delay). Decker-Wattenhofer channels are also extendable
to multi-party Burchert-Decker-Wattenhofer channel factories; there is no
credible method of extending Poon-Dryja to multiparty similarly.
The new Decker-Osuntokun-Russell combines the smaller practical timeouts on
unilateral closes with the lack of toxic waste, but requires
SIGHASH_NOINPUT_UNSAFE softfork in the base layer. I believe they can also be
used to host channel factories too in the same manner
Burchert-Decker-Wattenhofer extends Decker-Wattenhofer.
> 2) How does Decker-Wattenhofer claim funds when an old state is broadcast?
Old states are impossible to broadcast if new states are already known. The
final contract in the chains that Decker-Wattenhofer is a decrementing
timelock, with each newer version having a shorter timelock. This means that
as long as your node is online, old states cannot be published without the new
state having gotten published first (since the new state has a shorter
timelock). Since both the old and new state consume the same UTXO, the new
state being published leads to the old state being impossible to publish.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
