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:
OP_IF
# Settlement branch
OP_FALSE
OP_ELSE
# Update branch. 500,000,000 is the minimum state number under
Decker-Russell-Osuntokun.
500000000 OP_CHECKLOCKTIMEVERIFY
2 Au Bu 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF
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.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
