RBF fee bump payment transactions

[MaxHillebrand]

This is about fee bumping only single user transactions that are initiated from the users wallet (user has all inputs). Receiving transactions cannot be trivially fee bumped because we don't know the fee rate of that transaction, so this is out of scope of this issue.

In the user payment case, CPFP is not blockspace efficient, Therefore it should work with RBF.

In the UI transaction history of unconfirmed transactions, add a right click menu with speed up transaction, then show the fee rate graph with optional sats/vByte texbox, and a green confirm button. In the background, reduce the value of the change output until new fee rate is met. Or add another private input if necessary, Do not add non-private inputs.

[MaxHillebrand]

The effective fee rate calculation gets difficult if there is a chain of unconfirmed transactions prior to the users transaction.

[yahiheb]

The effective fee rate calculation gets difficult if there is a chain of unconfirmed transactions prior to the users transaction.

This shouldn't be a problem if we are doing this for only single user transactions that are initiated from the users wallet (user has all inputs).

[MaxHillebrand]

the UX should warn the user about the privacy downsides [change output detection and potential additional non-private inputs]

[turbolay]

In case there is enough change, RBF is really easy to implement -> Just reduce change

If there is not enough change, there are 4 possibilities:

• Wallet has other private/same pocket coins bigger than some selected so swapping some selected coins with other could be enough to cover the fee -> only downside is potentially (more) change
• Wallet has other private/same pocket coins smaller than the selected ones, some inputs can be added to cover for the extra fee -> it will increase size of the TX + potentially create (more) change
• Amount sent can be reduced to cover for the extra fee -> best solution but causes issues for payments.
• An extra non private output from another pocket -> degrades privacy, increases size of the TX and potentially create (more) change

In all cases it's probably better to just re-run the automatic coin selector but making sure that old TX will be replaced by the new one. One remaining question: If these are the only possible outcomes, should the user have an actionnable choice whether he wants to degrade his privacy by adding another pocket, have change, or reduce the amount?

[petertodd]

@turbolay

From the point of view of simplicity, I'd recommend that the original transaction inputs always be kept when RBF fee bumping. You don't want to accidentally create two distinct transactions, eg by selecting a different input to keep in different, successive, fee bumps. Better to lose a bit of privacy for the first version of this feature than accidentally create a double-payment bug.

[nopara73]

From the point of view of simplicity, I'd recommend that the original transaction inputs always be kept when RBF fee bumping.

Although originally, I was up for the challenge of not following your advice, during implementation, I quickly realized that'd quickly lead to a bugfactory.

Anyway, this feature is finally done! We've almost achieved the feature set, I envisioned a million years ago during the initial plans of 2.0 :)

[petertodd]

Awesome! Looking forward to trying this out in the next release!