On July 24th, Jonas Schnelli, a member of bitcoin core development team, failed in online shopping and he angrily asked BitPay why his order was rejected on Twitter.

“Screw you @BitPay! I just ordered stuff from @adafruit and you’ll fools rejected my RBFed transaction (and haven’t even told me in two days and only did because I asked “Where’s my stuff?!”)

@BitPay You’re just distraction!”

BitPay is a bitcoin payment processor established in 2011. Another payment processor, Flowee The Hub, responded in the Twitter:

“Let me get this right, your complaint is about you sending a BTC transaction with a “flag that says “I’ll double spend this later with a higher fee”, which gets rejected by merchant as a bad idea. Dramaqueen…

RBF is to steal from merchants. CPFP should be used. Or just BCH!

A Twitter account, Bitcoin, operated by members of bitcoin community, also sneered at the behavior of Jonas Schnelli:

“You guys (Bitcoin core) have spent years making BTC less and less useful for payments, and then get upset when companies take measures to deal with the mess you’ve created. What did you expect?

So, did Jonas Schnelli, a member of bitcoin core, really make a foolish mistake or it’s due to other reasons? To fully understand such a case, we’d better know what is an RBF transaction first.

 

What is RBF transaction?

We know that bitcoin mining workers have two sources of income: block rewards and service fees. When packing a block, the mining worker will give priority to the one with higher service fees. That’s why when the wallet is used for transfer, if the service fee is set too low, the waiting time to be confirmed will be very long.

If the service fee is set too low, it’s very likely that the transaction will not be packaged by the mining worker until one week later. During this period, the bitcoin is locked in the memory pool (a place where mining workers store unpackaged transactions they received in the network). So, is it possible to change the service fees which have been set too low?

The answer is yes. RBF is one of the solutions proposed by Peter Todd, another member of bitcoin core. RBF stands for “Replace By Fee”, which can replace the same unpackaged transaction issued before with higher service fee. Because the service fee of the first transaction is set too low, it lies in the memory pool without any attraction to any mining workers to conduct package. However, the second transaction can be initiated through RBF. The bitcoin to be transferred in this transaction is the same as the first one, but it’s set with higher service fee to replace the previous unpackaged transaction.

For example:

1. Mr. White transferred a bitcoin to Mr. Black and paid the mining worker the service fee of 0.001 bitcoin. Since they were not eager to have it packaged, they didn’t set a high service fee for the transaction.
2. However, a few hours later, Mr. Black realized his credit card bill was going to expire very soon and he was in urgent need of money. However, the bitcoin transferred from Mr. White had not been packaged yet, so Mr. Black was anxious and started to urge Mr. White.
3. Mr. White fully understood the pain. So, he initiated a transaction again. The bitcoin transferred by this transaction was the same as the one previously initiated and even the paying and receiving addresses were the same as those set in the previous transaction, except that a higher service fee was set through RBF: 0.003 BTC.
4. The transaction was then packaged because the high service fee had successfully attracted the mining workers.

According to an article issued by the Money Mongers, the RBF of Bitcoin includes the following four modes:

• Full RBF: So-called “full RBF” unconditionally allows a transaction to replace older ones so long as it pays a sufficient fee.
• Opt-in RBF: The “opt-in” variant only allows the replacement when the transactions being replaced have explicitly signaled they allow replacement. This signaling is done via the “sequence” field and defined by BIP 125. One downside of this variant is that users must know in advance when they may wish to replace a transaction. As a result, opt-in RBF is often used as a default even when it might otherwise not be needed.
• First-seen-safe RBF: The “first-seen-safe” variant only allows the replacement if an additional criterion is met: the replacement transaction must pay all the same outputs as the transactions being replaced.
• Delayed RBF: Delayed RBF is a variant which allows transactions to be replaced unconditionally, but only after a given number of blocks have been mined since the replaced transactions were first seen by the node.

 

Disadvantages of RBF Transaction

Well, do you feel that the RBF design is very user-friendly? However, one point that needs to be noticed is that this design of RBF commits a big mistake — double spending.

Double spending means that the “money” has been spent twice or even more times. In the original design of bitcoin creator, Satoshi Nakamoto, the mining workers need to follow the principle of “first come, first served” for transaction package, which means that if you initiate two transactions for one bitcoin at the same time, then the transaction included by the mining worker into the memory pool first will be packaged while the later one will be considered an illegal one attempting for double spending, so it will be rejected by the mining worker.

So, it is conceivable that after Peter proposed the RBF, it was opposed by many members of the developer community.

Gavin Andresen, former chief developer of Bitcoin core, tweeted:

“RBF is a bad idea, I don’t know how many RBF transactions are done on the bitcoin network. Although it is not clear how much complexity it adds to the bitcoin network, but remember that complexity is the enemy of security.”

Gavin Andresen’s viewpoint conforms to Steve Jobs’s idea: Stay Simple, Stay Secure.

The original purpose of bitcoin was to make a simple currency payment system. Once the system was added with too many complicated functions, its security would be greatly reduced. That’s why the bitcoin development team originally proposed the mode of SegWit + Lightning Network, but it was opposed by many people. In addition to some conclusion of intrigue, it’s also because the design of such an expansion was too complicated.

In March of this year, according to the CBC news, four Canadian guys stole a total of more than US$200,000 by means of 112 double-spending attacks on bitcoin ATM within 10 days. Collin Enstad, a cryptocurrency enthusiast, believed that it’s due to the RBF function that the double-spending attack would become so simple, and bitcoin was no longer a payment system.

In response, Peter Todd, the initiator of RBF, said,

“Please don’t impose the criticism on the RBF. Bitcoin cannot guarantee the security of the 0-confirm transactions on the chain, not only in the past but also in the future. Those claiming security of 0-confirm transaction are either ignorant or dishonest. And these guys are often those who sell people unsafe products. They deserve the name “0-confirm robber”.

Unfortunately, this article didn’t not mention a flaw in Bitcoin ATM operators: they accepted 0-confirm transactions without the slightest security, which would mislead the readers to believe that’s a new drawback of bitcoin.”

 

Replaceable Transaction Was Initiated by Satoshi Nakamoto

Although it is not clear how you think about RBF while reading this article, I want to tell you that replacing the old transaction with the new one was initiated by the creator of bitcoin, Satoshi Nakamoto, instead of Peter Todd. You may be a little puzzled now because I have just said that Satoshi Nakamoto had set the rule of “First Come, First Service” for packaging transaction, how come he had also proposed to replace the new transaction with the old one?

The bitcoin system originally designed by Nakamoto had a Locktime setting which enabled delayed packaging for transactions. The function of Locktime allowed users to replace the old transaction with a new one.

The value of Locktime can be divided into three degrees:

1. If the Locktime value is 0, it means it can be packaged immediately. Usually, the transaction we initiate is set to 0 by default.
2. If the Locktime value is greater than 0 and less than 500 million, the Locktime represents the block height, which means the transaction cannot be packaged beyond the specified block height;
3. If the Locktime value is greater than 500 million, it is a Unix time stamp and the mining workers must wait until a specified point of time to complete the package.

For example (transaction fees are not considered here):

• At the block height 10, Mr. White transfers a bitcoin to Mr. Black and sets Locktime as 20. Since it’s less than the block height 20, the mining worker will not package such a transaction.
• Then, Mr. Black began to urge Mr. White to expedite the transfer. Then, Mr. White initiates a transaction again to transfer the same one bitcoin as that in the previous transaction. But this time he sets the Locktime as 0, so the mining worker will conduct the package once receiving the transaction.
• In this way, the second new transaction has successfully replaced the previous one. Then, what will happen if the previous transaction reaches the block height 20? It will be rejected by the mining workers as an illegal transaction intending to conduct double-spending and it will not access to the main chain.

The Locktime feature was later upgraded by the bitcoin core developers to the Lightning Network.

 

Make Use of Double-Spending Wisely to Make Hackers Empty-handed

RBF is not completely useless. Igor Korsakov, a foreign cryptocurrency enthusiast, shared on the Internet his experience how he made use of RBF to resolve the crisis of bitcoin extortion. A website accepting the bitcoin payment service provided by Igor Korsakov was attacked by a hacker, who extorted 2 bitcoins. They agreed to his request, but set the transfer fee as low as only 0.0001 BTC.

This transaction was packaged and confirmed by the mining workers. However, the hacker could find the transaction on the block browser, so he thought the ransom had been a sure thing. Soon, Igor Korsakov used RBF to initiate another transaction to transfer the same two bitcoins to another receiving address with 0.1 BTC as service fee to speed up the package and confirmation. In the end, the second transaction was first confirmed by the mining workers while the hacker did not get anything. The money just slipped through his fingers.

Next time when you encounter bitcoin extortion, or regret for the bitcoin transaction you have already initiated, you’d better try RBF transaction. No matter you support or oppose RBF, the function has been introduced in Bitcoin Core 0.12 as early as February 2016 as a sure thing.

So how should we ordinary people deal with such situation?

In fact, it’s very simple, just wait for the transaction to be confirmed by the mining workers. Do not perform any subsequent operations until the transaction has been explicitly recorded on the blockchain. If there are relatively large number of bitcoins to be transferred, please wait until they have been confirmed in at least 6 blocks(read more: Why It Has to Have 6 Confirmations for A successful Bitcoin Transfer?).