Re: [bitcoin-dev] [Pre-BIP] Fee Accounts

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 3982 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]