[Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts
ZmnSCPxj at protonmail.com
Wed May 2 04:12:28 UTC 2018
Good morning Christian,
It seems to me we can remove the trigger transaction.
The observation is that `nSequence`-encumbered transactions are only settlement transactions and not any update transactions.
Thus, it is not needed for a trigger transaction to exist, if we can make update transactions behave as the trigger transaction for its settlement transaction or any later update transaction.
So, let me propose, that the funding transaction outpoint could have the below SCRIPT:
# Settlement branch
# Update branch. 500,000,000 is the minimum state number under Decker-Russell-Osuntokun.
2 Au Bu 2 OP_CHECKMULTISIGVERIFY
Thus, the funding outpoint can be spent directly by any update transaction, which has `<sigAu> <sigBu> OP_FALSE` at its `witness` script.
When creating a mutual close transaction, we simply use the update branch of the funding transaction above, again signing with `<sigAu> <sigBu> OP_FALSE`. This does have the drawback that the mutual close transaction can be RBFed away by an update transaction (requiring more code to handle this case); but the latest update transaction can still be published in that case and we simply devolve down to the usual unilateral close branch.
The drawback is that the mutual close transaction increases by 1 weight unit (the `OP_FALSE` in the `witness` script) plus the size of the more complicated funding transaction SCRIPT, which is no longer a regular 2-of-2 P2WSH and indelibly marking it as a Decker-Russel-Osuntokun mutual close. Taproot would help there by implicitly including a plain 2-of-2 fallback.
Finally, we could argue that the mutual close transaction is expected to be the more common case, so increasing its size by even a small amount may outweigh the size reduction in the much rarer unilateral close case.
More information about the Lightning-dev