rich1.0npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hhttps://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://nostr.ae📅 Original date posted:2021-12-19 📝 Original message: On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote: > I updated my article [0], people jumping on the thread now may find it > helpful to better understand this discussion. > [0] https://github.com/t-bast/lightning-docs/pull/16 Since merged, so https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md So imagine that this proposal is finished and widely adopted/deployed and someone adds an additional feature bit that allows a channel to forward PTLCs only, no HTLCs. Then suppose that you forget every old PTLC, because you don't like having your channel state grow without bound. What happens if your counterparty broadcasts an old state? * the musig2 channel funding is irrelevant -- the funding tx has been spend at this point * the unspent commitment outputs pay to: to_local: ipk = musig(revkey, mykey) -- known ; scripts also known to_remote: claimable in 1 block, would be better if ipk was also musig *_anchor: dust, who cares -- might be better if local_anchor used key = revkey *_htlc: irrelevant by definition local_ptlc: ipk = musig(revkey, mykey) -- known; scripts also known * commitment outputs may be immediately spent via layered txs. if so, their outputs are: ipk = musig(revkey, mykey); with fixed scripts, that include a relative timelock So provided you know the revocation key (which you do, because it's an old transaction and that only requires log(states) data to reconstruct) and your own private key, you can reconstruct all the scripts and use key path spends for every output immediately (excepting the local_anchor, and to_remote is delayed by a block). So while this doesn't achieve eltoo's goal of "no toxic waste", I believe it does achieve the goal of "state information is bounded no matter how long you leave the channel open / how many transactions travel over the channel". (Provided you're willing to wait for the other party to attempt to claim a htlc via their layered transaction, you can use this strategy for htlcs as well as ptlcs -- however this leaves you the risk that they never attempt to claim the funds, which may leave you out of pocket, and may give them the opportunity to do an attack along the lines of "you don't get access to the $10,000 locked in old HTLCs unless you pay me $1,000". So I don't think that's really a smart thing to do) Cheers, aj