tldr The reason we started GreenAddress was to provide a way of third party assured, zero-conf transactions: our customers have enjoyed since the service was launched. RBF means these transactions won’t get stuck, and their bitcoin experience will be even smoother, even in the case of massive usage spikes. For us and our customers, there is no downside, and only upside to this change, so of course we support it!
First, what is replace by fee (RBF)?
The short answer is that RBF is a mechanism to update a transaction that is not getting confirmed by miners because its fee is too low – the idea is to increase the fee to give miners an incentive to mine it.
The idea of RBF is quite simple, yet the topic is undoubtedly controversial as it makes something unreliably unreliable (and insecure) like zero-conf transactions reliably unreliable.
We have been advocating for RBF since as early as April 2014: the first time we publicly discussed RBF was when BitUndo was announced and when Peter Todd suggested miners should implement it. The reason we support RBF is simple: transactions are constantly getting stuck (especially as blocks get fuller and fuller) and even if you use the state of art in terms of fee estimation, predicting spikes is unreliable at best. Inevitably, unconfirmed transactions for hours or even days will occur, which is incredibly frustrating for bitcoin users.
We think RBF is inevitable and can’t be prevented, as it is not a consensus rule but a mere mining policy: miners can decide at any point in time to support RBF (just like they can decide to mine an empty block) without any need for anyone to agree. This makes accepting zero-conf an especially risky business as miners have a strong economic incentive to support RBF (increased fees!) and some have been known to take advantage of their position in the past.
RBF and vandalism?
Many have been saying that RBF (also known as Full RBF) is vandalism, as it breaks some unsupportable use cases by making them reliably unreliable. This is true to a certain extent; however, we always believed that one should always think adversarially and avoid relying on zero-conf, because if something can go wrong it inevitably will. We are also worried that perceived tacit consent of zero-conf would lead to an increase of adoption, which once attacked could be disastrous to the Bitcoin industry as a whole.
How many types of RBF exist?
There’s three types of RBF that have been largely discussed in the last few years:
- Full RBF (most controversial)
- First Seen Safe RBF (bad user experience or bad privacy)
- Opt in RBF (best of both worlds)
We already discussed Full RBF above so we’ll talk about the other two now.
First Seen Safe RBF (FSS RBF) is a way to support RBF without the perception of vandalism: allow people to update stuck transaction, but without the ability to change or remove any of the inputs and outputs. Users are only allowed to add new inputs to increase the fee (and new outputs as necessary).
While this sounds great, in practice it is quite bad because every FSS RBF update increases the amount of coins stuck and always requires users to have multiple unspent transaction outputs (UTXOs), but a large part of users have only one (and even if they had more, they wouldn’t want to tie up more and more of them as they attempt to update a transaction fee). Unfortunately, we can’t increase the fee by decreasing the change amount as miners have no idea which output(s) are change. While users could let miners know by flagging the change this, would be an incredibly reckless idea as it would harm privacy for all participants in the space – even when RBF is not used.
Welcome Opt In RBF
Recently Bitcoin Core has merged Opt-in RBF, which will be part of the 0.12 release scheduled to be released in the upcoming months. What is it? It’s a way to make RBF opt in, that is, transactions will have to be flagged in order for RBF updates to work (using an unused field in transactions called nSequence). This way, recipients can instantly detect the transaction is updatable (just like they can currently detect a fee being too low for a timely confirmation).
Merchants and payment processors don’t need to make more changes that they would normally do during normal updates to things like minimum relay fee or dust amounts in order to handle opt-in RBF.
This is great right? Indeed it is, best of both worlds, yet it is still quite misunderstood. Luckily, a great FAQ has been worked on by the community, which should clarify any doubt left.
GreenAddress’ users have been enjoying third party trust instant transaction for a long time now, which has allowed people to hold their own Bitcoin. By using supported exchanges like The Rock Trading they retain the ability to trade fast without waiting for confirmation.
With RBF this is even better, as it allows to more aggressively reduce fees and have better confirmations speed guarantees.
One last important point to make is that opt in RBF doesn’t actually prevent Full RBF – miners can still decide to adopt Full RBF, so people should be very careful when accepting zero-conf regardless. The practice should never be encouraged.
Phasing Out Third party trust
In the long term assurance based on third party trust is not great because you are trusting someone and it is possible for that trust to be broken, willingly or not. Lightning is posing to be the superior mechanism for instant confirmation without the need to trust anyone. We intend to support Lightning in the future and believe that RBF will be extremely important for maintaining the trustlessness of Lightning (as you need to be able to update the fee for transactions timing out from lightning peers).