As per BOLT #3, https://github.com/lightning/bolts/blob/8a64c6a1cef979b3f0cecb00ba7a48c2d28b3588/03-transactions.md#commitment-transaction-construction
9) If option_anchors applies to the commitment transaction:
* if to_local exists or there are untrimmed HTLCs, add a
to_local_anchor output
* if to_remote exists or there are untrimmed HTLCs, add a
to_remote_anchor output
For reference, both the remote and local anchor output has the following form:
<local_funding_pubkey/remote_funding_pubkey> OP_CHECKSIG OP_IFDUP
OP_NOTIF
OP_16 OP_CHECKSEQUENCEVERIFY
OP_ENDIF
In the event that a CPFP fee bump is necessary, it is not possible to use the
to_local output because of the CSV delay that gives the remote party a chance
to use the revocation pubkey:
OP_IF
# Penalty transaction
<revocationpubkey>
OP_ELSE
`to_self_delay`
OP_CHECKSEQUENCEVERIFY
OP_DROP
<local_delayedpubkey>
OP_ENDIF
OP_CHECKSIG
However the to_remote output in anchor channels has a much simpler form,
almost, but not quite, allowing the funds to be spent in a CPFP while
unconfirmed:
<remotepubkey> OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY
This delay has no justified purpose, and indeed, non-anchor channels simply use
a P2WPKH output spendable by the remotepubkey. Functionally, the output is
identical to the remote anchor output, making it redundant; rather than use the
to_remote_anchor output for CPFP the to_remote could have continued to be a
P2WPKH, and to_remote output could have been used for CPFP directly.
# Conclusion
Having both remote and local anchor outputs was a design flaw that needlessly
wastes chain space when using anchor outputs. This design flaw is doubly
wasteful due to the tendency of Lightning implementations to always spend the
CSV-delayed to_remote output immediately in a separate transaction to move the
funds to a "normal" scriptPubKey, rather that treating them as a normal wallet
output.
Further work: when HTLCs are in flight, it may also be possible to omit the
to_local anchor at the cost of additional implementation complexity with
careful consideration of exactly who has the ability to spend the HTLCs.
Credit goes to Matt Corallo for discussing this flaw with me and confirming its
existence.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
