<p>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.</p>

<p>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.</p>

<p>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 <a href="https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d">contentious</a> solution to make RBF acceptable.</p>

<p><a href="http://bitcoin-development.narkive.com/NgSiQBmM/bitcoin-development-first-seen-safe-replace-by-fee">First-Seen-Safe Replace-By-Fee</a> 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.</p>

<p>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.</p>

CC BY-SA 3.0
2015-07-01T19:04:32.990Z
2015-07-01T19:04:32.990Z
Steve Ellis
<p><a href="https://github.com/bitcoin/bitcoin/pull/6176" rel="nofollow">This pull request</a> describes first-seen replace-by-fee. How is it different from normal replace-by-fee, and how does it compare to child-pays-for-parent?</p>

<replace-by-fee><child-pays-for-parent>
How does first seen replace by fee work?
Nick ODell
# How does first seen replace by fee work?

(Asked by: username_0 on 2015-06-21)

[This pull request](https://github.com/bitcoin/bitcoin/pull/6176) describes first-seen replace-by-fee. How is it different from normal replace-by-fee, and how does it compare to child-pays-for-parent?

**Tags:** replace-by-fee, child-pays-for-parent


---

## 1 answers

### Answer by username_1 on 2015-07-01. Score: 5 | Accepted answer

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](https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d) solution to make RBF acceptable.

[First-Seen-Safe Replace-By-Fee](http://bitcoin-development.narkive.com/NgSiQBmM/bitcoin-development-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.


---

