{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-02-18\n📝 Original message:\nOn Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote:\n\u003e That's not really pinning; painning usually refers to pinning something to\n\u003e the bottom of the mempool whereas these mechanisms make it easier to\n\u003e guarantee that progress can be made on confirming the transactions you're\n\u003e interested in.\n\nAs I said, it's a new kind of pinning attack, distinct from other types of\npinning attack.\n\n\u003e Often times in these protocols \"the call is coming inside the house\". It's\n\u003e not a third party adding fees we are scared of, it's a direct party to the\n\u003e protocol!\n\nOften times that is true. But other times that is not true! I gave examples of\nuse-cases where being able to arbitrary add fees to transactions is harmful;\nthe onus is on you to argue why that is acceptable to burden those users with a\nnew class of attack.\n\n\u003e Sponsors or fee accounts would enable you to ensure the protocol you're\n\u003e working on makes forward progress. For things like Eltoo the internal\n\u003e ratchet makes this work well.\n\u003e \n\u003e Protocols which depend on in mempool replacements before confirmation\n\u003e already must be happy (should they be secure) with any prior state being\n\u003e mined. If a third party pays the fee you might even be happier since the\n\u003e execution wasn't on your dime.\n\n\"Must be able to deal with\" is not the same thing as \"Must be happy\". While\nthose use-cases do have to deal with those exceptional cases happening\noccasionally, it's harmful if an attacker can harass you by making those\nexceptional cases happen frequently.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220218/ffb7a6b7/attachment.sig\u003e"}