From ZmnSCPxj at protonmail.com Sun Feb 20 16:34:35 2022 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Sun, 20 Feb 2022 16:34:35 +0000 Subject: [Lightning-dev] [bitcoin-dev] [Pre-BIP] Fee Accounts In-Reply-To: References: <590cf52920040c9cf7517b219624bbb5@willtech.com.au> Message-ID: 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