- Aug 28, 2015
- 517
- 1,679
BUIP004:
Date submitted: 31/12/2015
Proposer: Pete Waterland
Background:
From the Articles of Federation IV: "Since 0-confirmation transactions are practically useful for people, we encourage innovations that enhance their security without undermining other key properties of the Bitcoin network"
When you send a bitcoin transaction it enters the network via a bitcoin node and propagates network wide remaining stored within the memory pool of each node until it is either included in a mined block or drops of the network. During this time the transaction is unconfirmed and not written to the blockchain and thus is less secure than a transaction which has being mined into a block, which is in turn less secure than a transaction which has one or n more blocks mined above it in the chain.
Since blocks are mined approximately every ten minutes waiting for transactions to be confirmed into the blockchain - although highly secure - is not practical for low value transactions where the customer / merchant would prefer not to delay. These instant transactions are called 0-confirmation transactions and rely upon a) a transaction being rapidly propagated across the network and b) node behaviour to prevent a second transaction with identical unspent outputs attempting to 'double spend' the same funds to another address and defraud the merchant.
Double spends are prevented by a mechanism called the 'first seen rule' which is where given two transactions from identical unspent outputs appearing on the network simultaneously only the first transaction to reach a given node is stored in that memory pool and relayed to other nodes. The second transaction is ignored. It is therefore a race between these two transactions to propagate across the network and which ever is mined into a block first wins. Technically then it is possible to perform a double spend on the bitcoin network if a merchant accepts 0-confirmation transactions though in practice simply by monitoring the network for attempted double spending this risk can be managed and is entirely acceptable for low value transactions and has been since bitcoin's inception.
RBF:
Unfortunately recently the Core reference client merged something called replace-by-fee (RBF) which will be shipped as an opt-in setting from the next release. RBF is where the first seen rule is altered such that if a node sees a second transaction with the same unspent outputs as one previously in the memory pool, instead of discarding it as fraudulent as before, if it has a higher fee than the first it replaces that transaction in the pool and is relayed onwards. This controversial change therefore allows double spending of transactions whilst they are unconfirmed (not written to a block). It is opt-in which means that transactions that wish to allow this behaviour are flagged as being potentially double spendable and can be identified as such by a relay node.
Reasons why this may be useful are to allow a 'stuck' transaction to be returned to a users wallet, or increase the priority of a transaction during periods of congestion, or to steal from a merchant.
Core will implement opt-in full RBF. Other variants include: first seen safe (FSS) RBF where a transaction may be replaced by another with a higher fee but only if the transaction outputs are the same, and scorched earth RBF.
Proposal:
1. vote amongst members regarding which of the following options we should offer in BU.
A 1) Keep 'first seen rule', not support RBF, ignore transactions flagged as opt-in RBF
0-conf is important to the ecosystem and is safe. Allowing double spending goes against the ethos of bitcoin and the original vision by Satoshi. We should actively oppose its implementation and not relay transactions which try to do this.
A 2) same as A 1 but relay opt-in-RBF transactions
B) Keep 'first seen rule' but allow user configurable setting which offers choice of: No RBF or FSS RBF
If we expect full blocks and network congestion then allowing users to 'unstick' their transactions by raising the fees should be supported by BU nodes. It does not allow fraudulent double spending like full RBF and therefore is both giving a choice to the user and keeping 0-conf safe.
C) Give user configurable behaviour to either enable or disable RBF. With enabled options of: opt-in RBF, FSS-RBF or full RBF.
With default setting to disabled and a warning if enabled.
Suggestion:
This is a highly contentious area where I personally disagree strongly with how Core has chosen to move forward and I suspect their next release will move opt-in RBF to full RBF.
My personal view is that we should strongly support the continued safety of 0-conf transactions where possible and I would prefer option A 1 or at a push B.
EDIT: removed the breaking consensus line for A 2 as Rocks quite rightly pointed out it does not actually break consensus or alter block behaviour
EDIT2: this probably needs to be stickied. @Bloomie do you have the power?
Date submitted: 31/12/2015
Proposer: Pete Waterland
Background:
From the Articles of Federation IV: "Since 0-confirmation transactions are practically useful for people, we encourage innovations that enhance their security without undermining other key properties of the Bitcoin network"
When you send a bitcoin transaction it enters the network via a bitcoin node and propagates network wide remaining stored within the memory pool of each node until it is either included in a mined block or drops of the network. During this time the transaction is unconfirmed and not written to the blockchain and thus is less secure than a transaction which has being mined into a block, which is in turn less secure than a transaction which has one or n more blocks mined above it in the chain.
Since blocks are mined approximately every ten minutes waiting for transactions to be confirmed into the blockchain - although highly secure - is not practical for low value transactions where the customer / merchant would prefer not to delay. These instant transactions are called 0-confirmation transactions and rely upon a) a transaction being rapidly propagated across the network and b) node behaviour to prevent a second transaction with identical unspent outputs attempting to 'double spend' the same funds to another address and defraud the merchant.
Double spends are prevented by a mechanism called the 'first seen rule' which is where given two transactions from identical unspent outputs appearing on the network simultaneously only the first transaction to reach a given node is stored in that memory pool and relayed to other nodes. The second transaction is ignored. It is therefore a race between these two transactions to propagate across the network and which ever is mined into a block first wins. Technically then it is possible to perform a double spend on the bitcoin network if a merchant accepts 0-confirmation transactions though in practice simply by monitoring the network for attempted double spending this risk can be managed and is entirely acceptable for low value transactions and has been since bitcoin's inception.
RBF:
Unfortunately recently the Core reference client merged something called replace-by-fee (RBF) which will be shipped as an opt-in setting from the next release. RBF is where the first seen rule is altered such that if a node sees a second transaction with the same unspent outputs as one previously in the memory pool, instead of discarding it as fraudulent as before, if it has a higher fee than the first it replaces that transaction in the pool and is relayed onwards. This controversial change therefore allows double spending of transactions whilst they are unconfirmed (not written to a block). It is opt-in which means that transactions that wish to allow this behaviour are flagged as being potentially double spendable and can be identified as such by a relay node.
Reasons why this may be useful are to allow a 'stuck' transaction to be returned to a users wallet, or increase the priority of a transaction during periods of congestion, or to steal from a merchant.
Core will implement opt-in full RBF. Other variants include: first seen safe (FSS) RBF where a transaction may be replaced by another with a higher fee but only if the transaction outputs are the same, and scorched earth RBF.
Proposal:
1. vote amongst members regarding which of the following options we should offer in BU.
A 1) Keep 'first seen rule', not support RBF, ignore transactions flagged as opt-in RBF
0-conf is important to the ecosystem and is safe. Allowing double spending goes against the ethos of bitcoin and the original vision by Satoshi. We should actively oppose its implementation and not relay transactions which try to do this.
A 2) same as A 1 but relay opt-in-RBF transactions
B) Keep 'first seen rule' but allow user configurable setting which offers choice of: No RBF or FSS RBF
If we expect full blocks and network congestion then allowing users to 'unstick' their transactions by raising the fees should be supported by BU nodes. It does not allow fraudulent double spending like full RBF and therefore is both giving a choice to the user and keeping 0-conf safe.
C) Give user configurable behaviour to either enable or disable RBF. With enabled options of: opt-in RBF, FSS-RBF or full RBF.
With default setting to disabled and a warning if enabled.
Suggestion:
This is a highly contentious area where I personally disagree strongly with how Core has chosen to move forward and I suspect their next release will move opt-in RBF to full RBF.
My personal view is that we should strongly support the continued safety of 0-conf transactions where possible and I would prefer option A 1 or at a push B.
EDIT: removed the breaking consensus line for A 2 as Rocks quite rightly pointed out it does not actually break consensus or alter block behaviour
EDIT2: this probably needs to be stickied. @Bloomie do you have the power?
Last edited:
