Can Bitcoin transactions actually be reversed/"undone" by the sender by using/abusing the newish "replace-by-fee" feature?

Question

I am watching a live stream of Roger Ver talking about Bitcoin. Yes, I know that a lot of people violently hate him and I will say that I don't like Bitcoin Cash. I sold all mine for Bitcoin very early on, and it seems to me that bigger block sizes are a bad thing.

However, I must admit that many things that he said then and says now seem to make sense. I'm very open to the possibility that he's lying or warping the truth, but this in particular is something which stuck out to me:

Basically, he is saying that Bitcoin has been fundamentally broken on purpose by introducing the "replace-by-fee" feature, which, according to him, allows you to "reverse" (take back) Bitcoin transactions for minutes, hours and "sometimes even weeks" after it was sent.

Is there any truth to this? Is he purely making this up to cause fear and doubt? If so, please give me all the details.

My understanding of the feature is that it simply allows you to "unstuck" a stuck-in-memory-pool transaction by essentially throwing it a few more satoshis for the transaction fee, so that it will not be ignored but rather included quicker by the miners while a lot of Bitcoin transactions are happening at the same time.

Please let him be lying. Another thing that makes me doubt myself and my own understanding of the whole situation is what he says about the Lighting Network, which I agree is "ultra-complex" and "never seems to come into actual use".

Answer 1

Basically, he is saying that Bitcoin has been fundamentally broken on purpose by introducing the "replace-by-fee" feature, which, according to him, allows you to "reverse" (take back) Bitcoin transactions for minutes, hours and "sometimes even weeks" after it was sent.

Not true. Bitcoin transactions with ZERO confirmations were always unsafe to accept as final. RBF just allows you to manage transactions in a better way because fee estimation is difficult in Bitcoin. For example: You can use any algorithm or manually check mempool stats and use a fee rate to broadcast a transaction but lot of other transactions broadcasted at almost the same time with a higher fee rate will decrease the probability of your transaction getting confirmed soon. If required you can replace this unconfirmed transaction with another transaction by using higher fee rate and fee.

Another thing that makes me doubt myself and my own understanding of the whole situation is what he says about the Lighting Network, which I agree is "ultra-complex" and "never seems to come into actual use".

Its easy to use with wallets mentioned in this link: https://blog.bitrefill.com/top-11-lightning-network-wallets-bitrefill-328b5465b1b4

Exchanges: Bitfinex, Okex, Paxful, Kraken(soon), LNMarkets, fixedfloat, sideshift

DEX Protocols using LN: OpenDEX, OmniBOLT

Answer 2

Yes, the rules of RBF explicitly allow changing the outputs of RBF transactions. But Roger Ver's concerns are blown out of proportion.

Bitcoin has been fundamentally broken on purpose by introducing the "replace-by-fee" feature, which, according to him, allows you to "reverse" (take back) Bitcoin transactions for minutes, hours and "sometimes even weeks" after it was sent.

Generally, you should wait for transactions to be confirmed before putting any trust in them. As Prayank already wrote, unconfirmed Bitcoin transactions are essentially payment promises.

However, since most nodes on the network operate their mempools with a "first-seen safe" admittance policy and will not allow conflicting transactions to replace prior transactions. In practice replacements of regular transactions occur almost exclusively after an initial transaction has timed out or via a sender collaborating with a miner to prioritize a replacement. So, while unconfirmed transactions are not reliable per se, depending on a transaction's specific properties, it may be make sense for a business to choose to accept a transaction before it is confirmed. For example Bitrefill considers it an acceptable risk to process unconfirmed transactions below $200 with "high fee rates" in trade-off for being able to serve their customers more quickly.

On the other hand, replace-by-fee transactions exhibit a flag that explicitly announces that they are unreliable and can be replaced by the sender before confirmation. The rules of RBF allow changing the outputs, so RBF transactions can indeed be redirected, but in practice RBF is mostly used to simplify fee estimation for transactions. The operational solution is simple, as well: it is to read the label, and never accept RBF transactions before they are confirmed. But it was already good practice not to accept unconfirmed transactions.

So, Roger Ver's concern is exaggerated. For regular transactions nothing changed, the (bad) practice of accepting unconfirmed transactions is exactly as safe or unsafe as before. BIP125 merely introduced a new optional feature that explicitly marks transactions as replaceable and unreliable which means that RBF transactions should never be accepted before confirmation. In practice, this placed a small onus on business operators that they should not-accept unconfirmed RBF transactions even if they want to accept some unconfirmed transactions. However, a business that accepts unconfirmed transactions should have evaluation mechanisms in place to assess which transactions are an acceptable risk to accept in the first place, so the onus should be trivial.