ZmnSCPxj [ARCHIVE] on Nostr: đź“… Original date posted:2022-02-20 đź“ť Original message: Good morning Jeremy, > ...
đź“… Original date posted:2022-02-20
đź“ť Original message:
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
đź“ť Original message:
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