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