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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
