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
