Re: [Lightning-dev] The remote anchor of anchor channels is redundant
On Wed, Dec 13, 2023 at 04:41:46PM +0100, Bastien TEINTURIER wrote: > Hi Peter, > > > it is more efficient to just open the channel with a dust-sized > > balance on the to_remote output. > > Yes, that would work, basically whenever the `to_remote` output would > disappear, then you add an anchor output instead paid by the channel > initiator. It isn't only at channel creation time that you'd need this > though if you want to support 0-reserve channels (for mobile wallets). Alternatively, only include a to_remote_anchor output when to_remote doesn't exist. > One of its issues is that if that dust `to_remote` output isn't claimed > by the peer (because it's too small), it cannot be claimed by anyone > else, which ends up polluting the utxo set *forever*, whereas the anchor > outputs can be claimed by anyone after 16 blocks, and there are people > regularly sweeping them in batches when the mempool is empty. Frankly a few UTXO's from the occasional lightning channel are probably pretty much entirely irrelevant compared to the huge amount of UTXOs created for data publishing, among other things. -- 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
Re: [Lightning-dev] The remote anchor of anchor channels is redundant
Hi Peter, > it is more efficient to just open the channel with a dust-sized > balance on the to_remote output. Yes, that would work, basically whenever the `to_remote` output would disappear, then you add an anchor output instead paid by the channel initiator. It isn't only at channel creation time that you'd need this though if you want to support 0-reserve channels (for mobile wallets). One of its issues is that if that dust `to_remote` output isn't claimed by the peer (because it's too small), it cannot be claimed by anyone else, which ends up polluting the utxo set *forever*, whereas the anchor outputs can be claimed by anyone after 16 blocks, and there are people regularly sweeping them in batches when the mempool is empty. It isn't entirely clear-cut which option would really be better. But hopefully v3 provides a much cleaner way of achieving those results! Cheers, Bastien Le mer. 13 déc. 2023 à 16:28, Peter Todd a écrit : > On Wed, Dec 13, 2023 at 02:27:13PM +0100, Bastien TEINTURIER wrote: > > 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 > > Obviously if there isn't a to_remote output, you need a way to CPFP. > > But even then the to_remote_anchor output is *still* unnecessary: it is > more > efficient to just open the channel with a dust-sized balance on the > to_remote > output. Either way you are giving up the dust amount. But a straightforward > pubkey output is more efficient to spend, if needed. And of course, this > doesn't require the remote anchor output implementation. > > > 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. > > Yes, I'm doing an analysis of v3 transactions, which is how I came across > this > issue to begin with. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] The remote anchor of anchor channels is redundant
On Wed, Dec 13, 2023 at 02:27:13PM +0100, Bastien TEINTURIER wrote: > 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 Obviously if there isn't a to_remote output, you need a way to CPFP. But even then the to_remote_anchor output is *still* unnecessary: it is more efficient to just open the channel with a dust-sized balance on the to_remote output. Either way you are giving up the dust amount. But a straightforward pubkey output is more efficient to spend, if needed. And of course, this doesn't require the remote anchor output implementation. > 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. Yes, I'm doing an analysis of v3 transactions, which is how I came across this issue to begin with. -- 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
Re: [Lightning-dev] The remote anchor of anchor channels is redundant
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 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: > > 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 > > OP_ELSE > `to_self_delay` > OP_CHECKSEQUENCEVERIFY > OP_DROP > > 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: > > 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
