rich1.0npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xphttps://nostr.ae/npub1pj9022f74rzq7d5x7gnxje6wpsgk4r5jgeck8y5awd423ydhan3q7x22xpnjumphttps://nostr.ae📅 Original date posted:2022-02-19 📝 Original message: > Necromancing might be a reasonable name for attacks that work by getting an > out-of-date version of a tx mined. It's not an "attack"? There is no such thing as an out-of-date transaction, if you signed and broadcasted it in the first place. You can't rely on the fact that a replacement transaction would somehow invalidate a previous version of it. ------- Original Message ------- Le samedi 19 février 2022 à 10:39 AM, Peter Todd <pete at petertodd.org> a écrit : > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote: > > > > 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). > > Mentioning "computation" when talking about transactions is misleading: > > blockchain transactions have nothing to do with computation. > > > Something that only increases possibility to make progress cannot be > > > > pinning. > > It is incorrect to say that all use-cases have the property that any version of > > a transaction being mined is progress. > > > 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). > > Necromancing might be a reasonable name for attacks that work by getting an > > out-of-date version of a tx mined. > > > 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. > > Your understanding of how OpenTimestamps calendars work appears to be > > incorrect. There is no chain of unconfirmed transactions. Rather, OTS calendars > > use RBF to update the timestamp tx with a new merkle tip hash for to all > > outstanding per-second commitments once per new block. In high fee situations > > it's normal for there to be dozens of versions of that same tx, each with a > > slightly higher feerate. > > OTS calendars can handle any of those versions getting mined. But older > > versions getting mined wastes money, as the remaining commitments still need to > > get mined in a subsequent transaction. Those remaining commitments are also > > delayed by the time it takes for the next tx to get mined. > > There are many use-cases beyond OTS with this issue. For example, some entities > > use "in-place" replacement for update low-time-preference settlement > > transactions by adding new txouts and updating existing ones. Older versions of > > those settlement transactions getting mined rather than the newer version > > wastes money and delays settlement for the exact same reason it does in OTS. > > If fee accounts or any similar mechanism get implemented, they absolutely > > should be opt-in. Obviously, using a currently non-standard nVersion bit is a > > possible approach. Conversely, with CPFP it may be desirable in the settlement > > case to be able to prevent outputs from being spent in the same block. Again, > > an nVersion bit is a possible approach. > > > 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. > > I just checked: all the BTC transaction accellerator services I could find look > > to be either scams, or very expensive. We need compelling reasons to make this > > nuisance attack significantly cheaper. > > > 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. > > As I said above, no it doesn't. > > ---------------------------------- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > Lightning-dev mailing list > > Lightning-dev at lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev