rich1.0npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0https://nostr.ae/npub1xukrzempxc95ags094lgrfvnvwm7gkuwj3d98qwrzgsynskyhp9qkfzef0njumphttps://nostr.ae📅 Original date posted:2022-02-18 📝 Original message: > As I said, it's a new kind of pinning attack, distinct from other types of pinning attack. I think pinning is "formally defined" as sequences of transactions which prevent or make it less likely for you to make any progress (in terms of units of computation proceeding). Something that only increases possibility to make progress cannot be pinning. If you want to call it something else, with a negative connotation, maybe call it "necromancing" (bringing back txns that would otherwise be feerate/fee irrational). I would posit that we should be wholly unconcerned with necromancing -- if your protocol is particularly vulnerable to a third party necromancing then your protocol is insecure and we shouldn't hamper Bitcoin's forward progress on secure applications to service already insecure ones. Lightning is particularly necromancy resistant by design, but pinning vulnerable. This is also true with things like coinjoins which are necromancy resistant but pinning vulnerable. Necromancy in particular is something that isn't uniquely un-present in Bitcoin today, and things like package relay and elimination of pinning are inherently at odds with making necromancy either for CPFP use cases. In particular, for the use case you mentioned "Eg a third party could mess up OpenTimestamps calendars at relatively low cost by delaying the mining of timestamp txs.", this is incorrect. A third party can only accelerate the mining on the timestamp transactions, but they *can* accelerate the mining of any such timestamp transaction. If you have a single output chain that you're RBF'ing per block, then at most they can cause you to shift the calendar commits forward one block. But again, they cannot pin you. If you want to shift it back one block earlier, just offer a higher fee for the later RBF'd calendar. Thus the interference is limited by how much you wish to pay to guarantee your commitment is in this block as opposed to the next. By the way, you can already do out-of-band transaction fees to a very similar effect, google "BTC transaction accelerator". If the attack were at all valuable to perform, it could happen today. Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a third party for OTS, you should be relatively happy because it cost you less fees overall, since the undoing of your later RBF surely returned some satoshis to your wallet. Best, Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220218/83410688/attachment.html>