bumpfee behavior with custom change address #11233

issue dooglus openend this issue on September 5, 2017

dooglus commented at 4:05 am on September 5, 2017: contributor
If I create an RBF transaction using the Qt GUI but specify my own custom change address, bumpfee doesn’t work because it claims it can’t find the change address:
```
"Transaction does not have a change output"
```
This is because none of the outputs satisfy
```
pWallet->IsChange(...)
```
I see there’s a “TODO” commented in CWallet::IsChange() in src/wallet/wallet.cpp:
```
// TODO: fix handling of 'change' outputs. The assumption is that any
// payment to a script that is ours, but is not in the address book
// is change.
```
I tend to put all my addresses in the address book whether I’m going to use them as change or not. I guess if the wallet was capable of creating its own SegWit change addresses I’d stop using custom change addresses, but currently it always seems to send change to a legacy address if I don’t manually specify a change address.
maflcko added the label Wallet on Sep 5, 2017
maflcko added the label RPC/REST/ZMQ on Sep 5, 2017
Sjors commented at 1:04 pm on November 4, 2017: member

I got this error as well, albeit on my own commit be758fe02. I was using a SegWit address as the custom change address. I also manually selected a segwit address for the input coins and the destination was a SegWit address.
ryanofsky commented at 4:08 pm on January 9, 2018: contributor

#12096 should provide a way to work around this. It gives you a way to manually specify which transaction output to decrease in order to increase the fee.

For fixing the root issue and determining the right change output, there are various possibilities. Sipa’s proposed future design for wallet pubkey storage would start explicitly recording whether a key is intended to be used for change or payment (https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2#future-design). Even without this, for hd split wallets (#9294), existing key metadata could provide this information.
achow101 commented at 7:37 pm on October 26, 2022: member

Since #15557, we will add additional inputs if needed, so this should be resolved now? It is also easier now to create change addresses that are actually detected as change.
whitslack commented at 11:31 pm on October 26, 2022: contributor

@achow101: The scenario is: I make a transaction that spends a 100-ksat UTxO to make one 60-ksat output to Address A and one 39-ksat output to Address B, with the remaining 1 ksat offered as a mining fee. When I run bumpfee on this transaction, Bitcoin Core doesn’t know which output to take additional funds from. You are saying it will add another input if necessary, but that’s not what we want here. We want to reduce one of the two outputs so that more goes to mining fee. This is a very common scenario when one of the outputs is a genuine payment and the other is a self-transfer, e.g., to cold storage.
ghost commented at 2:31 am on October 27, 2022: none
I don’t see the error mentioned by OP. However, unnecessary inputs are still added when using bumpfee with custom change address. Example:

Alice tries to pay 0.0005 to Bob in Tx1 by selecting one input from wallet:

bumpfee adds another input which was not required and extra output:

2af9dc2d055a5561b330501fdcb13d164e46e6c6c4f2bd3d744c374cc8f2daee
- Reason is associated with change addresses and explained in #20935
- I used change address by creating one with getrawchangeaddress and adding label with setlabel
Maybe #25979 fixes it and I will try to review it this week
fanquake closed this on Jul 20, 2023
BlackcoinDev referenced this in commit 04afe55e29 on Feb 5, 2024
bitcoin locked this on Jul 19, 2024

Contributors
dooglus Sjors ryanofsky achow101 whitslack ghost

Labels
Wallet RPC/REST/ZMQ