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 <p...@petertodd.org> 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
