ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-08-02 📝 Original message: Good morning Michael, > A ...
📅 Original date posted:2018-08-02
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180802/50ba2a40/attachment-0001.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180802/50ba2a40/attachment-0001.html>;