I feel compelled to re-share Mike Hearn's counter-argument *against *
replace-by-fee:
https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Please carefully consider the effects of replace-by-fee before applying
Peter's patch.

On Sun, May 3, 2015 at 9:36 PM, Peter Todd <pete@petertodd.org> wrote:

> My replace-by-fee patch is now available for the v0.10.1 release:
>
>     https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1
>
> No new features in this version; this is simply a rebase for the Bitcoin
> Core v0.10.1 release. (there weren't even any merge conflicts) As with
> the Bitcoin Core v0.10.1, it's recommended to upgrade.
>
>
> The following text is the copied verbatim from the previous release:
>
> What's replace-by-fee?
> ----------------------
>
> Currently most Bitcoin nodes accept the first transaction they see
> spending an output to the mempool; all later transactions are rejected.
> Replace-by-fee changes this behavior to accept the transaction paying
> the highest fee, both absolutely, and in terms of fee-per-KB. Replaced
> children are also considered - a chain of transactions is only replaced
> if the replacement has a higher fee than the sum of all replaced
> transactions.
>
> Doing this aligns standard node behavior with miner incentives: earn the
> most amount of money per block. It also makes for a more efficient
> transaction fee marketplace, as transactions that are "stuck" due to bad
> fee estimates can be "unstuck" by double-spending them with higher
> paying versions of themselves. With scorched-earth techniques⁵ it gives
> a path to making zeroconf transactions economically secure by relying on
> economic incentives, rather than "honesty" and alturism, in the same way
> Bitcoin mining itself relies on incentives rather than "honesty" and
> alturism.
>
> Finally for miners adopting replace-by-fee avoids the development of an
> ecosystem that relies heavily on large miners punishing smaller ones for
> misbehavior, as seen in Harding's proposal⁶ that miners collectively 51%
> attack miners who include doublespends in their blocks - an unavoidable
> consequence of imperfect p2p networking in a decentralized system - or
> even Hearn's proposal⁷ that a majority of miners be able to vote to
> confiscate the earnings of the minority and redistribute them at will.
>
>
> Installation
> ------------
>
> Once you've compiled the replace-by-fee-v0.10.1 branch just run your
> node normally. With -debug logging enabled, you'll see messages like the
> following in your ~/.bitcoin/debug.log indicating your node is replacing
> transactions with higher-fee paying double-spends:
>
>     2015-02-12 05:45:20 replacing tx
> ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with
> c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for
> 0.00798 BTC additional fees, -1033 delta bytes
>
> Additionally you can tell if you are connected to other replace-by-fee
> nodes, or Bitcoin XT nodes, by examining the service bits advertised by
> your peers:
>
>     $ bitcoin-cli getpeerinfo | grep services | egrep
> '((0000000000000003)|(0000000004000001))'
>             "services" : "0000000000000003",
>             "services" : "0000000004000001",
>             "services" : "0000000004000001",
>             "services" : "0000000000000003",
>             "services" : "0000000004000001",
>             "services" : "0000000004000001",
>             "services" : "0000000000000003",
>             "services" : "0000000000000003",
>
> Replace-by-fee nodes advertise service bit 26 from the experimental use
> range; Bitcoin XT nodes advertise service bit 1 for their getutxos
> support. The code sets aside a certain number of outgoing and incoming
> slots just for double-spend relaying nodes, so as long as everything is
> working you're node should be connected to like-minded nodes a within 30
> minutes or so of starting up.
>
> If you *don't* want to advertise the fact that you are running a
> replace-by-fee node, just checkout a slightly earlier commit in git; the
> actual mempool changes are separate from the preferential peering
> commits. You can then connect directly to a replace-by-fee node using
> the -addnode command line flag.
>
> 1) https://github.com/bitcoinxt/bitcoinxt
> 2) https://github.com/bitcoin/bitcoin/pull/3883
> 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
> 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
> 5)
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
> 6)
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
> 7)
> http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>