rich1.0npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hhttps://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://nostr.ae📅 Original date posted:2021-12-21 📝 Original message: 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