{"type":"rich","version":"1.0","author_name":"npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0","author_url":"https://nostr.ae/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-02-18\n📝 Original message:\n\u003e As I said, it's a new kind of pinning attack, distinct from other types\nof pinning attack.\n\nI think pinning is \"formally defined\" as sequences of transactions which\nprevent or make it less likely for you to make any progress (in terms of\nunits of computation proceeding).\n\nSomething that only increases possibility to make progress cannot be\npinning.\n\nIf you want to call it something else, with a negative connotation, maybe\ncall it \"necromancing\" (bringing back txns that would otherwise be\nfeerate/fee irrational).\n\nI would posit that we should be wholly unconcerned with necromancing -- if\nyour protocol is particularly vulnerable to a third party necromancing then\nyour protocol is insecure and we shouldn't hamper Bitcoin's forward\nprogress on secure applications to service already insecure ones. Lightning\nis particularly necromancy resistant by design, but pinning vulnerable.\nThis is also true with things like coinjoins which are necromancy resistant\nbut pinning vulnerable.\n\nNecromancy in particular is something that isn't uniquely un-present in\nBitcoin today, and things like package relay and elimination of pinning are\ninherently at odds with making necromancy either for CPFP use cases.\n\nIn particular, for the use case you mentioned \"Eg a third party could mess\nup OpenTimestamps calendars at relatively low cost by delaying the mining\nof timestamp txs.\", this is incorrect. A third party can only accelerate\nthe mining on the timestamp transactions, but they *can* accelerate the\nmining of any such timestamp transaction. If you have a single output chain\nthat you're RBF'ing per block, then at most they can cause you to shift the\ncalendar commits forward one block. But again, they cannot pin you. If you\nwant to shift it back one block earlier, just offer a higher fee for the\nlater RBF'd calendar. Thus the interference is limited by how much you wish\nto pay to guarantee your commitment is in this block as opposed to the next.\n\nBy the way, you can already do out-of-band transaction fees to a very\nsimilar effect, google \"BTC transaction accelerator\". If the attack were at\nall valuable to perform, it could happen today.\n\nLastly, if you do get \"necromanced\" on an earlier RBF'd transaction by a\nthird party for OTS, you should be relatively happy because it cost you\nless fees overall, since the undoing of your later RBF surely returned some\nsatoshis to your wallet.\n\nBest,\n\nJeremy\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220218/83410688/attachment.html\u003e"}