{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-12-21\n📝 Original message:\nHey AJ and list,\n\nThat's a very good point, it's really worth highlighting!\n\nThe reason we have \"toxic waste\" with HTLCs is because we commit to the\npayment_hash directly inside the transaction scripts, so we need to\nremember all the payment_hash we've seen to be able to recreate the\nscripts (and spend the outputs, even if they are revoked).\n\nBut with PTLCs, we commit to a payment_point outside of the scripts (in\nthe adaptor signature that is exchanged), so we're able to recreate the\nscripts independently of the payment details! This also means that the\npayment_point never appears on-chain (which is good for privacy) whereas\nthe payment_hash does appear on-chain for HTLCs.\n\n*_anchor: dust, who cares -- might be better if local_anchor used key =\n\u003e revkey\n\n\nI don't think we can use revkey, this would prevent us from bumping the\ncurrent remote commitment if it appears on-chain (because we don't know\nthe private revkey yet if this is the latest commitment). Usually the\nremote peer should bump it, but if they don't, we may want to bump it\nourselves instead of publishing our own commitment (where our main\noutput has a long CSV).\n\nBut as you already mentioned, who cares, it's dust and we don't even need\nit to CPFP the revoked commitment, we can use any other output since the\nrevocation path isn't encumbered with a CSV 1.\n\nCheers,\nBastien\n\nLe dim. 19 déc. 2021 à 23:23, Anthony Towns \u003caj at erisian.com.au\u003e a écrit :\n\n\u003e On Wed, Dec 08, 2021 at 04:02:02PM +0100, Bastien TEINTURIER wrote:\n\u003e \u003e I updated my article [0], people jumping on the thread now may find it\n\u003e \u003e helpful to better understand this discussion.\n\u003e \u003e [0] https://github.com/t-bast/lightning-docs/pull/16\n\u003e\n\u003e Since merged, so\n\u003e https://github.com/t-bast/lightning-docs/blob/master/taproot-updates.md\n\u003e\n\u003e So imagine that this proposal is finished and widely adopted/deployed\n\u003e and someone adds an additional feature bit that allows a channel to\n\u003e forward PTLCs only, no HTLCs.\n\u003e\n\u003e Then suppose that you forget every old PTLC, because you don't like\n\u003e having your channel state grow without bound. What happens if your\n\u003e counterparty broadcasts an old state?\n\u003e\n\u003e  * the musig2 channel funding is irrelevant -- the funding tx has been\n\u003e    spend at this point\n\u003e\n\u003e  * the unspent commitment outputs pay to:\n\u003e      to_local: ipk = musig(revkey, mykey) -- known ; scripts also known\n\u003e      to_remote: claimable in 1 block, would be better if ipk was also musig\n\u003e      *_anchor: dust, who cares -- might be better if local_anchor used\n\u003e         key = revkey\n\u003e      *_htlc: irrelevant by definition\n\u003e      local_ptlc: ipk = musig(revkey, mykey) -- known; scripts also known\n\u003e\n\u003e  * commitment outputs may be immediately spent via layered txs. if so,\n\u003e    their outputs are: ipk = musig(revkey, mykey); with fixed scripts,\n\u003e    that include a relative timelock\n\u003e\n\u003e So provided you know the revocation key (which you do, because it's an\n\u003e old transaction and that only requires log(states) data to reconstruct)\n\u003e and your own private key, you can reconstruct all the scripts and use\n\u003e key path spends for every output immediately (excepting the local_anchor,\n\u003e and to_remote is delayed by a block).\n\u003e\n\u003e So while this doesn't achieve eltoo's goal of \"no toxic waste\", I believe\n\u003e it does achieve the goal of \"state information is bounded no matter\n\u003e how long you leave the channel open / how many transactions travel over\n\u003e the channel\".\n\u003e\n\u003e (Provided you're willing to wait for the other party to attempt to claim\n\u003e a htlc via their layered transaction, you can use this strategy for\n\u003e htlcs as well as ptlcs -- however this leaves you the risk that they\n\u003e never attempt to claim the funds, which may leave you out of pocket,\n\u003e and may give them the opportunity to do an attack along the lines of\n\u003e \"you don't get access to the $10,000 locked in old HTLCs unless you pay\n\u003e me $1,000\".  So I don't think that's really a smart thing to do)\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211221/471cbd0d/attachment.html\u003e"}