Can someone outline the full pros/cons of the various Replace-By-Fee proposals?

Question

I've done some research myself, but I find that I'm either biased myself, or my sources themselves are biased. Does anyone have an objective analysis of the various proposals and their advantages/disadvantages? First-seen-safe, child-pays-for-parent, full-RBF are the ones I know about, but would happily read more proposals if they're out there.

Answer 1

All three proposals attempt to solve the same problem, the issue of stuck transactions.

Due to the behavior of Bitcoin Core with respect to double spends (they are silently dropped, and not relayed), it is impossible to spend outputs that you've used in an existing transaction. Typically this is a good thing, but there are a few cases where a user may have created a malformed transaction (for example, accidentally setting 0 fees) that isn't acceptable or mine-able for various reasons, and it's desirable for them to be able to reissue a fixed transaction.

This is exacerbated by the undefined memory pool behavior of nodes with respect to expiring out old transactions, and not having a clear rule as to when it's safe to attempt another spend.

1. Child-Pays-For-Parent

The Child-Pays-For-Parent approach allows the fees of a transaction's child (the transaction that spends the outputs of the stuck transaction) to also pay for the parent transaction. This allows a merchant to spend the "broken" transaction they received like any other transaction, and the system should return to a consistent state.

The benefit of Child-Pays-For-Parent is that it solves the problem in a way that doesn't fundamentally change the mechanics for how a transaction is selected and kept (most notably, the first-seen memory pool behavior). In my opinion, this makes this solution the most intuitive.

However, the difficulty with Child-Pays-For-Parent is in the implementation. There are some required changes to the propagation of transactions that are required to make this work properly (since just broadcasting a valid child will cause other nodes to consider the transaction as orphaned, without the context of the parent).

2. Replace-By-Fee

Replace-by-fee attempts to address the problem by changing the fundamental rule for accepting and keeping transactions, the "first-seen" rule.

In this system, a transaction with higher fees can spend already spent inputs (that have not yet been confirmed in a block), and will replace that transaction in the memory pool.

The benefit of this system is that it changes the fundamental transaction selection rule but does not require changes to the way fees are calculated.

The downside is that this represents a significant shift in terms of expected memory pool behavior. In my opinion, this makes transactions less predictable; the first-seen rule is straightforward, predictable, and easy to understand and implement. Additionally, it breaks any functionality that relies on the predictability of unconfirmed transactions by making it trivial to issue double spends. (Double spending a first seen transaction requires a combination of moderate network and computing resources, some decent know-how, and some luck. Double spending in a replace-by-fee world requires none of the above.)

3. First-Seen-Safe Replace-By-Fee

FSS RBF attempts to make RBF compatible with first-seen memory pool implementations by requiring that the outputs from the original transaction be maintained by subsequent respends.

The benefits are that in some situations, first-seen behavior can be relied upon. A transaction sending x BTC to a merchant cannot revoke that.

In practice, however, this protection is pretty weak. It trivially breaks transactions that spend other unconfirmed transactions by allowing the first transaction in the chain to be replaced, invalidating future outputs. This means that the burden for double spending an unconfirmed transaction becomes only slightly higher than in standard replace-by-fee.

It does, theoretically, allow one to accept an unconfirmed transaction that spends a confirmed output with similar protections as the typical first-seen behavior.

---

It is impossible to talk about this without touching on the politics, though. The reason this is so contentious is that it involves a political change that breaks many systems that rely on first-seen memory pool behavior. The proponents of the change believe that since unconfirmed transactions are not subject to the same cryptographic protections as confirmed transactions, they should be pushed out of the ecosystem and tools that facilitate this should be adopted. The people who oppose this change believe that unconfirmed transactions represent an acceptable risk as with everything in Bitcoin (remember, Bitcoin requires a majority of honest miners, for example), and that breaking something many people rely on unnecessarily is a net negative.

Answer 2

Answer reposted from: How does first seen replace by fee work?

Right now, for the most part, Bitcoin miners follow a First-Seen-Safe rule: If 2 conflicting transactions show up in the mempool, the miner sticks with the one it saw first.

Replace-By-Fee would enable miners to remove transactions from the mempool based on which transaction pays the higher fee. This is problematic because it enables fraud. If I pay a merchant and walk out, I can then easily broadcast a conflicting transaction which sends the money back to me with only a slightly higher fee. The merchant doesn't get paid, but I get the goods for a slightly larger transaction fee.

With Child-Pays-For-Parent, an unconfirmed transaction(parent) can be raised in mining priority by spending their output(children). The extra fees that would come from children offer incentive for the miner to include the parent transaction. CPFP relates to RBF as a way for a merchant to fight fraud. If a merchant detects that a payment they were expecting has been rerouted, they can raise the priority of their preferred transaction using CPFP. This is a contentious solution to make RBF acceptable.

First-Seen-Safe Replace-By-Fee follows the RBF rules, but puts some requirements around replacing transactions in the mempool. When replacing a transaction based on higher fee, all the amounts of all the outputs from the original transaction need to be met. You can add and remove inputs, increase past output amounts, and add new outputs. You are allowed to modify transactions as long as you meet or exceed the past outputs.

With FSSRBF you can safely accept transactions that spend confirmed outputs, but not unconfirmed transactions spending outputs of other unconfirmed transactions. CPFP is useful beyond RBF, but is not necessary for FSSRBF usability.