Missing test.

This decreases the output? In some cases that may desirable, but in general I think that's very unexpected (I would think it would add a new input instead).

If you don't have a change address chance are fairly high that you're simply moving coins (e.g. between wallets). Especially if you only have one utxo in, you may not want to associate other utxo's with it for privacy reasons.

"single output transactions are special in that the exact amount doesn't usually matter (the user is emptying a wallet or using coin control to move UTXOs)."

I would argue that this is not stated strongly enough. If they previously paid to a single output then it is almost always true that they do not care about the particular amount. This is especially true as the previous amount was subject to an arbitrary, variable fee.

Valid use cases where this behavior is necessary, where you really don't want to require adding more inputs in order to bumpfee:

• Emptying a wallet
• Emptying particular UTXO's

I would further suggest if the receiver was expecting a particular amount then you would expect there to be a change output.

@kallewoof You're right that in most cases right now that you don't care about the amount if there is only one output, but there is certainly no guarantee. The coin selection algorithm even explicitly tries to find a solution without change first - it's just pretty terrible at its job current (#10637 will make it succeed much more often).

I think this could be generalized and also be made safer by adding an reduce_output option to bumpfee (could also call it something like output_number or txout). This way you'd be able to bump single output transactions by specifying reduce_output: 0, but there'd be no risk of someone accidentally decreasing the amount they are trying to send by bumping the fee in other cases.

I don't think it makes sense to arbitrarily add inputs to bumpfee. I don't even know if RBF allows it (since you're suggesting it, I guess it does -- I thought I tried and failed).

Maybe a bump_from_output flag in options that did this behavior.

Edit: @ryanofsky That looks good to me.

I don't see why RBF wouldn't allow it, as long as all transactions you're replacing have been marked as replaceable.

I like the idea of explicitly marking an output that can be reduced.

Over time (especially after #10637), I think we'll inevitably need a way to bump transactions that don't have change. Depending on feerates and your wallet's UTXO set distribution, a large fraction of transactions may be created without change.

does the wallet track which outputs had subtractFeeFromOutput? In that case further reduction seems completely fine as well.

Agree that there are cases where the output(s) can't be reduced. In the cases it can be reduced, should it be re-funded?

I don't think it makes sense to arbitrarily add inputs to bumpfee. I don't even know if RBF allows it (since you're suggesting it, I guess it does -- I thought I tried and failed).

@kallewoof Currently our relay policy (and BIP 125) require that if you add a new input, it must be already confirmed -- perhaps you tested with an unconfirmed input?

(The idea behind that requirement was to ensure the new transaction was more likely to be mined than the ones it was replacing; now that we use ancestor feerate mining, we could perhaps relax this requirement and compare ancestor feerates of everything instead to ensure the new transaction has a higher mining score.)

concept ack after the current coin selection stop trying 1 output (I assume #10637 solves that?).

NAK. The only time it would be acceptable to reduce the output is if the transaction was created as subtract fee from output. Bumping should add additional inputs as required.

@gmaxwell even with an option to allow the subtract, default to false (since there is no subtract from output record)?

if it were behind a bunch of warnings, ... but even though if substract from wasn't initially selected should only be a last resort if it can't bump otherwise. The wallet shouldn't quietly direct the user into behavior that might cause them to get criminally prosecuted.

@wtogami The wallet has explicit information about transactions created where the user requested subtracting fees from amounts. Using that information would be fine but you cannot use the lack of a change output to detect this, when 2^inputs * fees_saved_from_excluding_an_output is large relative to the amount being paid an exact match frequently exists. And the PR pieter linked to will usually find it.

Summary:

• Do not implicitly assume a single-output-no-change transaction can be altered due to better coin selection in the future.
• Require the user to select the output if the user does not want additional inputs to be added to cover increased fees.
• (Allow adding additional inputs to cover increased fees -- separate PR)

For this PR, that translates to:

• Fail if no output is explicitly chosen (pre-merge behavior)
• Reduce single output to cover fees if user has explicitly picked it
• Allow user to arbitrarily pick the output that is reduced for existing multi-output transactions (i.e. not restricted to change output).

• Self-review: RPC command help needs update to reflect change

Rebase is becoming overwhelming on this. Closing until further notice (may rewrite the code).