Hey AJ, Right, I was probably confused between local/remote, especially when we're talking about our anchor in the remote commitment (should it be called local anchor, which is from our point of view, or remote?).
Let's call them Alice and Bob, and Bob is publishing a commitment. Correct me if I'm wrong there, what you're suggesting is that: * Bob's anchor on Bob's commitment can be spent with revkey * Alice's anchor on Bob's commitment can be spent with Alice's pubkey This does ensure that each participant is able to claim their anchor in the latest commitment, and Alice is able to claim both anchors in any of Bob's outdated commitments. But I think it defeats the `OP_16 OP_CHECKSEQUENCEVERIFY` script branch. We have that branch to allow anyone to spend anchor outputs *after* the commitment is confirmed, to avoid keeping them around in the utxo set forever. However, the trick is that the internal pubkey must be set to something that is publicly revealed when the channel closes. Now that we put the revkey in internal pubkeys everywhere instead of script branches, that revkey is *not* revealed when channels close with the latest commit. So it would prevent people from using that script branch to clean up the utxo set... I have currently used <local_delayedpubkey> and <remote_pubkey> because they're revealed whenever main outputs are claimed, but there is probably a smarter solution (maybe one that would let us use revkey here as you suggest), this will be worth thinking about a bit more. Thanks, Bastien Le mar. 21 déc. 2021 à 17:04, Anthony Towns <a...@erisian.com.au> a écrit : > On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote: > > The reason we have "toxic waste" with HTLCs is because we commit to the > > payment_hash directly inside the transaction scripts, so we need to > > remember all the payment_hash we've seen to be able to recreate the > > scripts (and spend the outputs, even if they are revoked). > > I think "toxic waste" refers to having old data around that, if used, > could cause you to lose all the funds in your channel -- that's why it's > toxic. This is more just regular landfill :) > > > *_anchor: dust, who cares -- might be better if local_anchor used key = > > > revkey > > I don't think we can use revkey, > > musig(revkey, remote_key) > --> allows them to spend after you've revealed the secret for revkey > you can never spend because you'll never know the secret for > remote_key > > but if you just say: > > (revkey) > > then you can spend (because you know revkey) immediately (because it's > an anchor output, so intended to be immediately spent) or they can spend > if it's an obsolete commitment and you've revealed the revkey secret. > > > this would prevent us from bumping the > > current remote commitment if it appears on-chain (because we don't know > > the private revkey yet if this is the latest commitment). Usually the > > remote peer should bump it, but if they don't, we may want to bump it > > ourselves instead of publishing our own commitment (where our main > > output has a long CSV). > > If we're going to bump someone else's commitment, we'll use the > remote_anchor they provided, not the local_anchor, so I think this is > fine (as long as I haven't gotten local/remote confused somewhere along > the way). > > Cheers, > aj > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
