I am relaying a privacy issue for Bitcoin Core that was [reported on r/Bitcoin](https://reddit.com/r/Bitcoin/comments/klk2wh) (Reddit).

The [message](https://pastebin.com/raw/ptFQityt) was:

- _Using coin control_
- _Custom change address_

_When one clicks the increase transaction fee button, it adds another input rather than increasing the fee by reducing the change output. Major privacy leak since you have no control of the input used._

From that it sounds like the observed behavior is that the replacement transaction includes an additional UTXO that was not chosen by the user, even though the transaction was composed as a Coin Control transaction.

So I'm assuming the expected behavior would be for Bitcoin Core to remember that this OUTPUT was actually a Custom Change Address and to then lower the amount of that OUTPUT by the amount needed for the fee bump.

And, now that I am thinking of this, isn't there the expectation that if my initial transaction was done using Coin Control, and then if my fee bump (RBF) needs another UTXO input to cover the increase in fee, that Coin Selection for that will occur (regardless of whether or not the change address was a Custom Change Address)?  
result.pushKV("psbt", EncodeBase64(ssTx.str()));
    result.pushKV("complete", complete);
    return result;
},
    };
}
RPCHelpMan walletcreatefundedpsbt()
{
    return RPCHelpMan{"walletcreatefundedpsbt",
                "\nCreates and funds a transaction in the Partially Signed Transaction format.\n"
                "Implements the Creator and Updater roles.\n"
                "All existing inputs must either have their previous output transaction be in the wallet\n"
                "or be in the UTXO set. Solving data must be provided for non-wallet inputs.\n",
                {
                    {"inputs", RPCArg::Type::ARR, RPCArg::Optional::OMITTED, "Leave empty to add inputs automatically. See add_inputs option.",
                        {
                            {"", RPCArg::Type::OBJ, RPCArg::Optional::OMITTED, "",
                                {
                                    {"txid", RPCArg::Type::STR_HEX, RPCArg::Optional::NO, "The transaction id"},
                                    {"vout", RPCArg::Type::NUM, RPCArg::Optional::NO, "The output number"},
                                    {"sequence", RPCArg::Type::NUM, RPCArg::DefaultHint{"depends on the value of the 'locktime' and 'options.replaceable' arguments"}, "The sequence number"},
                                    {"weight", RPCArg::Type::NUM, RPCArg::DefaultHint{"Calculated from wallet and solving data"}, "The maximum weight for this input, "
                                        "including the weight of the outpoint and sequence number. "
                                        "Note that signature sizes are not guaranteed to be consistent, "
                                        "so the maximum DER signatures size of 73 bytes should be used when considering ECDSA signatures."
                                        "Remember to convert serialized sizes to weight units when necessary."},
                                },
                            },
                        },
                        },