Transaction details: Design the fee bump user flow

[GBKS]

Transactions in the mempool can be sped up, by making the same transaction again with a higher fee. This will lead miners to prioritize the new one, and the old transaction will be discarded. This is a useful tool for users with urgent outstanding transactions.

There are two methods, replace-by-fee (RBF) and child-pays-for-parent (CPFP) with different properties. I am not sure which ones core supports, but here's a quick outline of the two (via Claude).

1. Replace-by-Fee (RBF):

• Mechanism: RBF replaces the original transaction entirely with a new one.
• Setup: The original transaction must be flagged as replaceable when it's first broadcast.
• Process: A new transaction is created with the same inputs but a higher fee, replacing the original.
• Control: The sender has full control over this process.
• Timing: Can be done anytime before the original transaction is confirmed.
• Impact: The original transaction is effectively cancelled and replaced.

2. Child-Pays-for-Parent (CPFP):

• Mechanism: CPFP creates a new, child transaction that depends on the original (parent) transaction.
• Setup: No special flagging is required on the original transaction.
• Process: A new transaction is created that spends the outputs of the unconfirmed parent transaction.
• Control: Can be initiated by either the sender or the recipient.
• Timing: Can be done even if the original transaction isn't flagged as replaceable.
• Impact: Both the original and the new transaction must be mined together.

Key Differences:

1. Transaction Replacement: RBF replaces the original transaction, while CPFP keeps the original and adds a new one.
2. Fee Calculation: In RBF, miners consider the fee of the new transaction. In CPFP, miners look at the combined fees of both transactions.
3. Flexibility: CPFP can be used even when RBF isn't available, making it more flexible.
4. Initiator: RBF can only be initiated by the sender, while CPFP can be done by either the sender or the recipient.
5. Complexity: RBF is generally simpler to implement and understand, while CPFP can be more complex.

So let's first figure out what's supported (if anything), and then come up with respective UI specs and user flows.

This would likely be an addition to the transaction details screen, covered in the activity page in the design docs.

[stackingsaunter]

Bitcoin core supports both

[GBKS]

Since RBF is a user option, we need to have an idea of how users decide whether they want it and when they don't. Some thoughts on that from Claude:

Users might choose not to flag a transaction as replaceable (i.e., not enable RBF) for several reasons:

Payment finality: For merchants or recipients who want to consider a transaction final as soon as it's broadcast, non-replaceable transactions provide more certainty. This can be important for point-of-sale transactions or time-sensitive exchanges.

Simplicity: For users who don't anticipate needing to modify their transaction, keeping it non-replaceable simplifies the process.

Reduced double-spend risk: Non-replaceable transactions are harder to double-spend, which can be a security consideration for recipients.

Wallet compatibility: Some older or simpler wallets may not fully support RBF, so users might opt for non-replaceable transactions for broader compatibility.

Network congestion mitigation: RBF transactions can potentially increase network load if frequently replaced, so some users might avoid it to reduce network strain.

Privacy considerations: RBF transactions can potentially leak more information about the sender's fee preferences and urgency, which some privacy-conscious users might want to avoid.

Reduced complexity for recipients: Recipients don't have to worry about monitoring for potential replacements or updates to the transaction.

Regulatory compliance: In some jurisdictions, the ability to easily replace transactions might complicate regulatory compliance, so businesses might prefer non-replaceable transactions.

User preference: Some users simply prefer the idea of transactions being "final" once sent, aligning more closely with how they conceptualize traditional financial transactions.

It's worth noting that even without RBF, users can still potentially use other methods like CPFP to adjust fees if necessary. The choice often depends on the specific use case, the user's technical understanding, and the balance between flexibility and immediacy of transaction finality.

So it's a no-go for anything urgent, where the recipient wants assurance that there can be no bait-and-switch. But it's a nice feature for less time-sensitive things and the sender may want to low-ball fees.

[GBKS]

For reference, there was a request for fee bumping in the QT application.