Hi Peter, No, we currently cannot get rid of the remote anchor in favor of the main remote output. That was considered during the design of anchor outputs, but that would create the following vulnerability.
Alice opens a channel to Bob: Bob doesn't have a main output in the commit tx yet. Alice sends HTLCs to Bob. Bob still doesn't have a main output in the commit tx yet. Bob sends `update_fulfill_htlc` and his corresponding `commit_sig`, but Alice doesn't send `commit_sig` back and broadcasts her commit tx. Bob needs to be able to claim the HTLCs on-chain before they timeout. Bob thus needs to ensure that Alice's commit tx confirms, which requires having a remote anchor in it. Note that Bob cannot simply broadcast his own commit tx and use the local anchor on it, because its feerate is exactly the same as Alice's commit tx. Since we don't have package relay and Alice was the first to broadcast, it's likely that Alice's commit tx won the race in every mempool, so CPFP-ing Bob's commit tx won't help it replace Alice's. The only way to get rid of this would have been to rework HTLCs to allow using them as "anchors", but that was a more complex change with its own set of drawbacks. I'd rather wait for v3 transactions and package relay to move to a single ephemeral anchor, which fixes this issue altogether. Thanks, Bastien Le mer. 13 déc. 2023 à 13:59, Peter Todd <p...@petertodd.org> a écrit : > 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
