Opponents of the newly introduced Replace-by-Fee option believe it increases the danger of double spending fraud. Others retort that the danger is greatly exaggerated.

Among other features added in the Bitcoin Core 0.12.0 edition, there is Opt-in Replace-by-Fee (RBF). It allows transactions to be flagged as replaceable. In this case, if a transaction sits in the queue to be confirmed by miners for too long, it is possible to upgrade it in order to get it confirmed faster, for instance increasing the fee associated with the transaction or merging multiple transactions into one.

The feature had already been introduced by Satoshi Nakamoto in the initial protocol but was disabled in later core versions due to potential DDoS threat. It was re-introduced in the new Core 0.12.0 probably to make bitcoin payments smoother in the situation when the 1MB block size limit slackens transaction speed. However, many Redditors have been vocal about the dangers of RBF. Indeed, it potentially enables the money sender to meddle in a delayed transaction replacing data. For instance, a bitcoiner may pretend to send an amount of money to the merchant and then send this money to another destination. Some Redditors went as far as to rechristen the new option as “Reroute By Fraud”.

However, others argue that no one compels the merchant to accept RBF-flagged transactions before they are confirmed by miners and become a part of the blockchain. According to the user jarfil, there are four options for merchants:

“1. Accept 0-conf non-RBF transactions, hoping that the transaction will ultimately — some day— be included in the blockchain. 2. Accept n-conf RBF transactions (with n > 0), being sure that once the transactions have been included in the blockchain, they can not be replaced anymore. 3. Be a total moron and honor 0-conf RBF transactions, that can be rewritten a thousand times before they get included in the blockchain. 4. Be paranoid and only accept n-conf non-RBF transactions, which are already included in the blockchain, and offer the same security as n-conf RBF transactions.”

Many users believe that the third option is the only one posing any real danger to the money receiver.

Alexey Tereshchenko