BUIP004: RBF/double spending support Proposer: Pete Waterland (inca) Submitted: 2015-12-31 Status: passed
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
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
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
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
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.
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.
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