RBF transactions to be enabled at the next core update

[matthewh3]

Can anyone tell the major benefits of this update apart from what I understand is to help induce a free market for transaction fees.  Won't it break the ability to accept zero confirmation transactions?  As there are currently methods to do so with great certainty that a zero confirmation transaction will go through the next block.  And also doesn't this break the core ethos of bitcoin being a pure push system only.  I've read the RBF transactions update is being merged into bitcoin core at the next update.  Isn't that a little hasty for such a drastic change to the protocol to be brought in so quickly.  After it took us a good several months to agree on re-increasing the blocksize.

[1714056296]

1714056296

[shorena]

Can anyone tell the major benefits of this update apart from what I understand is to help induce a free market for transaction fees.  Won't it break the ability to accept zero confirmation transactions?  As there are currently methods to do so with great certainty that a zero confirmation transaction will go through the next block.  And also doesn't this break the core ethos of bitcoin being a pure push system only.  I've read the RBF transactions update is being merged into bitcoin core at the next update.  Isn't that a little hasty for such a drastic change to the protocol to be brought in so quickly.  After it took us a good several months to agree on re-increasing the blocksize.

My limited understanding is that the first transaction needs to raise a flag in order to allow RBF. Merchants that accept 0-conf TX could scan for the flag and wait to deliver their part if it is set. On the other hand I am not sure how ready merchants or even regular wallet implementations are.

[achow101]

Can anyone tell the major benefits of this update apart from what I understand is to help induce a free market for transaction fees.  Won't it break the ability to accept zero confirmation transactions? 

Nope. Those transactions are opt-in, meaning that if the transaction doesn't opt-in to use RBF, then it can't be Replaced later.

As there are currently methods to do so with great certainty that a zero confirmation transaction will go through the next block.

Not really. The currently consist of CPFP, waiting for the transaction to disappear, or attempting an RBF transaction without really having RBF enabled anywhere. All of them take a while and are rather difficult to do.

And also doesn't this break the core ethos of bitcoin being a pure push system only.

How does this break that?

I've read the RBF transactions update is being merged into bitcoin core at the next update. 

Already merged in.

Isn't that a little hasty for such a drastic change to the protocol to be brought in so quickly. 

It isn't a protocol change, it is a node policy change. This change is something that only nodes will decide whether they want to accept the transaction into their mempool or not. It has nothing to do with consensus or protocol.

After it took us a good several months to agree on re-increasing the blocksize.

That is because this is a node policy change, not consensus or protocol. Consensus changes and protocol like increasing the block size limit require a fork, hard fork in the case of block size and soft fork in others like OP_CLTV. Forks require consensus and agreement since those can fork the blockchain. Node policy changes don't since it is specific to individual nodes, not the entire network nor the blockchain. Since this is just a node policy change, nothing is being affected on the network, just whether nodes want to accept or reject RBF transactions.

If you think that this change was too hasty, I'm here to tell you it is not. The subject of RBF has been discussed for years already. Peter Todd has had the code implemented in a fork for a while and this code has been tested and tested and discussed for ages. In fact, the idea of replacing transactions is not original. It was originally implemented by Satoshi but removed due to DoS concerns, which have been fixed by requiring that the fee be raised. Hence Replace-By-Fee.

[xdrpx]

I'm sorry if I'm wrong, but I'd love someone to correct me if I am. What I've understood is an RBF Opt-in enables a user who has made a payment to find the lowest possible amount he needs to negotiate or bid for the transaction fee that he has to pay, so that his payment transaction is sure to be completed when a block is full and his wallet.

If that's right, should his Wallet client remind the user after a couple of hours that in order for his transaction to be recognized earlier for him to determine via an RBF Opt-in the best possible fee? Will the user have to keep monitoring his transaction for a long period of time? 

[letsplayagame]

Can anyone tell the major benefits of this update apart from what I understand is to help induce a free market for transaction fees.  Won't it break the ability to accept zero confirmation transactions?  As there are currently methods to do so with great certainty that a zero confirmation transaction will go through the next block.  And also doesn't this break the core ethos of bitcoin being a pure push system only.  I've read the RBF transactions update is being merged into bitcoin core at the next update.  Isn't that a little hasty for such a drastic change to the protocol to be brought in so quickly.  After it took us a good several months to agree on re-increasing the blocksize.

My limited understanding is that the first transaction needs to raise a flag in order to allow RBF. Merchants that accept 0-conf TX could scan for the flag and wait to deliver their part if it is set. On the other hand I am not sure how ready merchants or even regular wallet implementations are.

If this is correct then what is the disadvantage of RBF? The free market for transactions fees is created and merchants that want to keep allowing 0 conf transactions without risk can just exclude those who use the RBF flag.

[achow101]

If this is correct then what is the disadvantage of RBF? The free market for transactions fees is created and merchants that want to keep allowing 0 conf transactions without risk can just exclude those who use the RBF flag.

There is no disadvantage, but people don't realize this. All they do is spread FUD about this and not understand what it is actually doing.

[spiderbrain]

That is because this is a node policy change, not consensus or protocol. Consensus changes and protocol like increasing the block size limit require a fork, hard fork in the case of block size and soft fork in others like OP_CLTV. Forks require consensus and agreement since those can fork the blockchain. Node policy changes don't since it is specific to individual nodes, not the entire network nor the blockchain. Since this is just a node policy change, nothing is being affected on the network, just whether nodes want to accept or reject RBF transactions.

If you think that this change was too hasty, I'm here to tell you it is not. The subject of RBF has been discussed for years already. Peter Todd has had the code implemented in a fork for a while and this code has been tested and tested and discussed for ages. In fact, the idea of replacing transactions is not original. It was originally implemented by Satoshi but removed due to DoS concerns, which have been fixed by requiring that the fee be raised. Hence Replace-By-Fee.

Really good summary, thanks.

[unamis76]

My limited understanding is that the first transaction needs to raise a flag in order to allow RBF. Merchants that accept 0-conf TX could scan for the flag and wait to deliver their part if it is set. On the other hand I am not sure how ready merchants or even regular wallet implementations are.

Can anyone tell the major benefits of this update apart from what I understand is to help induce a free market for transaction fees.  Won't it break the ability to accept zero confirmation transactions? 

Nope. Those transactions are opt-in, meaning that if the transaction doesn't opt-in to use RBF, then it can't be Replaced later.

So this means that when a transaction is broadcasted it has a flag saying that RBF can be enabled, or that it can't?

[theymos]

So this means that when a transaction is broadcasted it has a flag saying that RBF can be enabled, or that it can't?

If all of the inputs of a transaction have nSequence = UINT_MAX or UINT_MAX-1, then they have RBF disabled. Sending transactions with nSequence = UINT_MAX is the default for ~all wallets.

[BlindMayorBitcorn]

Ok I know this isn't a technical question, but: What do businesses that regularly deal with Bitcoin have to say about this? And wallet developers? It still seems like a strange new feature.

This is from Reddit:

Separate but related question: I'm happy to use core, but I don't want my fullnode forwarding or honoring RBF. I would like to treat them as doublespends.

Is there a setting or compile option for this behavior ?

Also, Ill be setting up wallet software to ignore any non-final transaction, regardless of confirmations. It will be up to the sender to use their RBF feature to take back their transaction, if they are silly enough to send it RBF.

[theymos]

Ok I know this isn't a technical question, but: What do businesses that regularly deal with Bitcoin have to say about this? And wallet developers? It still seems like a strange new feature.

As Peter Todd demonstrated with his Coinbase double-spend, it is (and always has been) very easy to double-spend 0-conf transactions even without RBF. In most cases, it is only slightly less difficult to double-spend with RBF compared to non-RBF.

I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.

I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.

[BlindMayorBitcorn]

Seems harmless enough. Thanks!

[BlindMayorBitcorn]

Who would use it and why?

[theymos]

Who would use it and why?

The idea is that eventually most people will use it most of the time.

I don't know if this is actually exactly how it's planned, but how I imagine it working in the future is:
- By default, you'll send transactions with RBF. Then if the transaction doesn't confirm after a long time, RBF will allow you to easily increase the fee. You'll be taking responsibility for the transaction
- If a merchant requests that you not use RBF, you won't. Likely this request will be done via the Bitcoin Payment protocol (ie. bitcoin: URIs). So when you click "pay this" (or whatever it says) on a BitPay page, your wallet will automatically send the transaction without RBF. Then the merchant is taking responsibility for the payment, and they can adjust the fee later if necessary using the child-pays-for-parent (CPFP) mechanism. I'd expect most payment processors like BitPay to do this so that customers don't have to worry about fees and they can try to do fraud detection on 0-conf transactions.

[unamis76]

So this means that when a transaction is broadcasted it has a flag saying that RBF can be enabled, or that it can't?

If all of the inputs of a transaction have nSequence = UINT_MAX or UINT_MAX-1, then they have RBF disabled. Sending transactions with nSequence = UINT_MAX is the default for ~all wallets.

Thank you, I was not aware of that.

[Jet Cash]

So can we avoid all this just by saying "only accept confirmed payments" ?

[achow101]

So can we avoid all this just by saying "only accept confirmed payments" ?

Yup

[Quickseller]

Ok I know this isn't a technical question, but: What do businesses that regularly deal with Bitcoin have to say about this? And wallet developers? It still seems like a strange new feature.

As Peter Todd demonstrated with his Coinbase double-spend, it is (and always has been) very easy to double-spend 0-conf transactions even without RBF. In most cases, it is only slightly less difficult to double-spend with RBF compared to non-RBF.

I would disagree with this. In order for a 0-confirmation transaction to get double spent (assuming you have zero influence on any amount of mining hardware/pool) without RBF, as a general rule most of the network needs to have not seen the transaction, AND the transaction needs to either not have been seen by the miners' nodes or not be a transaction that the miners will generally confirm. In order for the above to be true, you generally will need to create a transaction with a very low fee, and/or otherwise be non-standard. Companies that accept 0/unconfirmed transactions need to filter out the above types of transactions until they have at least one confirmation (or more) in order to prevent financial losses to themselves. When the spam attacks were taking place over the summer, luckybi.it was the victim of several double spend attacks, and they made adjustments accordingly, the same is true for PocketDice, and in light of Peter Todd's double spend, the same will likely be true for coinbase.

If a transaction has been seen by the majority of the network, has no reason to not be relayed by most nodes, has a sufficient transaction fee to get quickly confirmed, and some amount of time has elapsed (generally <10 seconds), then it is very difficult to double spend a 0/unconfirmed transaction if you do not have any influence in any mining hardware/pool.

I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.

I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.

Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.

I really doubt Core is ever going to provide an easy UI for fraudulently double-spending

This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.

From what I understand RBF is similar to CPFP in a sense that both share the same goal of getting a transaction to confirm that would probably not otherwise confirm. However there are potentially fraudulent uses for RBF while there are not (that I am aware of) for CPFP. Additionally CPFP puts the "burden" of the cost of getting a transaction confirmed on the receiver, which is generally the status quo for retail transactions (especially those involving credit cards), which consumers are used to, and often demand.

I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part).   
 

[achow101]

I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.

I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.

Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.

What's the point of broadcasting the conflicting transaction? Since the network would have already seen the first one with RBF enabled, if the conflicting transaction doesn't have RBF enabled, then AFAIK it will be rejected as a double spend.

I really doubt Core is ever going to provide an easy UI for fraudulently double-spending

This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.

From what I understand RBF is similar to CPFP in a sense that both share the same goal of getting a transaction to confirm that would probably not otherwise confirm. However there are potentially fraudulent uses for RBF while there are not (that I am aware of) for CPFP. Additionally CPFP puts the "burden" of the cost of getting a transaction confirmed on the receiver, which is generally the status quo for retail transactions (especially those involving credit cards), which consumers are used to, and often demand.

I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part).   

In most cases, what I have seen is that the sender usually wants the transaction to confirm, not the receiver although both do happen somewhat frequently. Many times the receiver doesn't care about the transaction as it might just be a deposit which the sender wants done quickly. With CPFP, there may not be any change addresses for the sender to use to attempt a CPFP. RBF allows that.

Also, CPFP adds additional transactions to the blockchain and to mempools while RBF will not thus helping to reduce blockchain bloat.

[Quickseller]

I think that it's always been a hopeless effort, but some services try to predict when 0-conf transactions are high-risk using a number of network nodes listening for double-spends and other such things. For these, it's a simple matter to check for the RBF opt-in and treat these transactions as automatically high-risk.

I feel like most people are imagining that with RBF there's going to be a button in wallets that says "take back this money", but that's very unlikely. Right now you have to use createrawtransaction to send a RBF-enabled transaction, and in the future there will be a button to increase fees (or something), but I really doubt Core is ever going to provide an easy UI for fraudulently double-spending. As is the case today, 0-conf transactions will often work despite being totally insecure because a large percentage of people are honest, and of those who are dishonest, a large percentage of them haven't bothered to figure out how to double-spend.

Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.

What's the point of broadcasting the conflicting transaction? Since the network would have already seen the first one with RBF enabled, if the conflicting transaction doesn't have RBF enabled, then AFAIK it will be rejected as a double spend.

Maybe I have misspoke in some way due to my lack of technical understanding of RBF. I guess the conflicting transaction would also have RBF enabled, allowing it to be accepted by the nodes.

I really doubt Core is ever going to provide an easy UI for fraudulently double-spending

This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.

From what I understand RBF is similar to CPFP in a sense that both share the same goal of getting a transaction to confirm that would probably not otherwise confirm. However there are potentially fraudulent uses for RBF while there are not (that I am aware of) for CPFP. Additionally CPFP puts the "burden" of the cost of getting a transaction confirmed on the receiver, which is generally the status quo for retail transactions (especially those involving credit cards), which consumers are used to, and often demand.

I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part).   

In most cases, what I have seen is that the sender usually wants the transaction to confirm, not the receiver although both do happen somewhat frequently. Many times the receiver doesn't care about the transaction as it might just be a deposit which the sender wants done quickly. With CPFP, there may not be any change addresses for the sender to use to attempt a CPFP. RBF allows that.

If the sender is making a deposit to, say coinbase, then the sender can notify coinbase they are willing to have x deducted from their deposit if coinbase broadcasts a CPFP transaction that contains a fee of x.

Today when someone buys a cup of coffee from Starbucks with their credit card, it is Starbucks that bears the costs of accepting the Credit Card. I don't see why it should be any different with Bitcoin, so Starbucks could receive a payment with a very low/no fee and then could use a CPFP transaction with a sufficiently high fee to get both transactions to confirm.

Also, CPFP adds additional transactions to the blockchain and to mempools while RBF will not thus helping to reduce blockchain bloat.

Many/most bitcoin related services will spend deposits/payments to another internal address/wallet after one confirmation anyway for a various number of reasons. It will often go deposit address --> internal hot wallet address --> possibly more hot wallet addresses/transactions --> unrelated withdrawal and/or transaction to cold wallet. Often each transaction waits for one confirmation until the next transaction is broadcast.