Can't bump fee after abandoning child transaction #26667

Steps:

1. Send transaction (A) to a different wallet
2. Using the change, create another transaction (B) to a different wallet
3. abandontransaction B
4. bumpfee A fails with Transaction has descendants in the wallet

This is particularly annoying now that -zapwallettxes has been removed.

<img width="426" alt="Scherm­afbeelding 2022-12-08 om 14 55 29" src="https://user-images.githubusercontent.com/10217/206554825-fa31ba91-73d3-4c13-94dc-b726243eef7b.png">

Having trouble replicating. When I try to abandontransaction on B, I get:

Transaction not eligible for abandonment (code -5)

I'm using 24.0.

@john-moffett that error happens because the transaction is in your mempool. One way around that is to stop the node, delete mempool.dat and start again with -connect=0 -walletbroadcast=0.

The first argument makes it so your node doesn't connect to other peers that would echo the transaction back. The second ensures your wallet doesn't put the transaction in the mempool.

@Sjors Thank you!

It appears that HasWalletSpend doesn't make an exception for abandoned transactions:

https://github.com/bitcoin/bitcoin/blob/7d515600034b84ebf23346a3642cf0a714880e25/src/wallet/wallet.cpp#L646-L657

However, IsSpent does make an exception:

https://github.com/bitcoin/bitcoin/blob/7d515600034b84ebf23346a3642cf0a714880e25/src/wallet/wallet.cpp#L712-L727

HasWalletSpend appears to to be used only by feebumper (and tests). I'll take a look tomorrow to see if that will fix the issue.

On a broader level, it's unclear to me why abandontransaction won't remove transactions from the mempool and mark them as abandoned. Perhaps there ought to be a force option?

On a broader level, it's unclear to me why abandontransaction won't remove transactions from the mempool and mark them as abandoned. Perhaps there ought to be a force option?

Explicitly removing a transaction from our mempool has no effect on the network and could mislead users into thinking that they have "canceled" their transaction. Doing so may surprise users when the "abandoned" transaction ends up confirming, or a subsequent spend ends up not propagating because it conflicts with the abandoned transaction (that all of the other nodes still have in their mempool). However, by allowing abandoning when our own mempool has dropped the transaction, we can more safely assume that other nodes have dropped the transaction as well. Abandoning in this case has a higher likelihood of the transaction actually having been forgotten by a significant portion of the network.