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

From: ZmnSCPxj <[email-masked]>
Date: Sun, 20 Feb 2022 16:34:35 +0000

Good morning Jeremy,

> opt-in or explicit tagging of fee account is a bad design IMO.
>
> As pointed out by James O'Beirne in the other email, having an explicit key required means you have to pre-plan.... suppose you're building a vault meant to distribute funds over many years, do you really want a *specific* precommitted key you have to maintain? What happens to your ability to bump should it be compromised (which may be more likely if it's intended to be a hot-wallet function for bumping).
>
> Furthermore, it's quite often the case that someone might do a transaction that pays you that is low fee that you want to bump but they choose to opt-out... then what? It's better that you should always be able to fee bump.

Good point.

For the latter case, CPFP would work and already exists.
**Unless** you are doing something complicated and offchain-y and involves relative locktimes, of course.

Once could point out as well that Peter Todd gave just a single example, OpenTimeStamps, for this, and OpenTimeStamps is not the only user of the Bitcoin blockchain.

So we can consider: who benefits and who suffers, and does the benefit to the former outweigh the detriment of the latter?

It seems to me that the necromancing attack mostly can *only* target users of RBF that might want to *additionally* add outputs (or in the case of OTS, commitments) when RBF-ing.
For example, a large onchain-paying entity might lowball an onchain transaction for a few withdrawals, then as more withdrawals come in, bump up their feerate and add more withdrawals to the RBF-ed transaction.
Such an entity might prefer to confirm the latest RBF-ed transaction, as if an earlier transaction (which does not include some other withdrawals requested later) is necromanced, they would need to make an *entire* *other* transaction (which may be costlier!) to fulfill pending withdrawal requests.

However, to my knowledge, there is no actual entity that *currently* acts this way (I do have some sketches for a wallet that can support this behavior, but it gets *complicated* due to having to keep track of reorgs as well... sigh).

In particular, I expect that many users do not really make outgoing payments often enough that they would actually benefit from such a wallet feature.
Instead, they will generally make one payment at a time, or plan ahead and pay several in a batch at once, and even if they RBF, they would just keep the same set of outputs and just reduce their change output.
For such low-scale users, a rando third-party necromancing their old transactions could only make them happy, thus this nuisance attack cannot be executed.

We could also point out that this is really a nuisance attack and not an economic-theft attack.
The attacker cannot gain, and can only pay in order to impose costs on somebody else.
Rationally, the only winning move is not to play.

So --- has anyone actually implemented a Bitcoin wallet that has such a feature (i.e. make a lowball send transaction now, then you can add another send later and if the previous send transaction is unconfirmed, RBF it with a new transaction that has the previous send and the current send) and if so, can you open-source the code and show me?

Regards,
ZmnSCPxj