An Appeal for Zero-Conf
This is a guest post by Erik Voorhees.
The recent addition of Peter Todd’s “Replace by Fee” (aka RBF) to Bitcoin Core ignited a discussion over the past several days, related both to RBF specifically and to “zero-confirmation transactions” more broadly (zero-confirmation, aka zero-conf, refers to accepting Bitcoin transactions before they are confirmed in a block).
This post isn’t intended to debate the merits of RBF itself. Personally, while I’m not sure I see the benefit (is it a net-beneficial feature?), I’m open to the possibility that it may be. I don’t know. Smarter people than I can debate its merits. I consider Peter Todd to be a brilliant mind, and he is someone from whom I’m always eager to learn.
What this post IS intended to highlight, however, is the importance of zero-conf in the Bitcoin world. It has been too quickly dismissed and vilified by some in the community.
The ramifications of RBF are still being debated, but it’s fair to say that RBF makes double-spends more likely for some portion of zero-conf transactions, and potentially all of them (see details on RBF at the bottom of the post). This means zero-conf may become too risky for anyone to ever accept, period. Waiting for a block could become necessary for every use case of Bitcoin.
So, is this a problem?
In my humble opinion, Bitcoin is made worse to the extent zero-confs become more dangerous. The ecosystem will be made poorer. The industry-wide average time to complete a transaction with “reasonable safety” will increase, adding friction. It’s not clear whether RBF’s advantages (what are they, again?) more than make up for that added friction.
There are many in the community (including many very intelligent people) who have long said that zero-conf should never be done, anyway. They say it’s always unsafe. They argue that anyone accepting coins at zero-conf is a fool and will get burned eventually. For these people, RBF has no drawback, because they don’t think zero-conf should be done in the first place.
I understand that point of view. It is true that zero-conf is risky, and true that many have gotten, and will get, burned by supporting it.
I get it. I’m one of those who has gotten burned by it, numerous times.
Let’s harken back to the age of SatoshiDICE, which became something of a legend. SatoshiDICE, at its peak during the second half of 2012, was responsible for more than half of all Bitcoin transactions on Earth.
SatoshiDICE became popular for a number of reasons. One of them was the frictionless, near-instant “tactile” feedback it provided for players. Without ever signing up with an account, or depositing funds, a player from anywhere on the planet could place bets, and receive his winnings (or a dust tx informing of his tragic loss) moments later.
SatoshiDICE thrived by accepting zero-conf transactions, and kicked off a universe of Bitcoin gaming sites that helped bring the industry out of stasis in mid-2012. The player didn’t need to wait 10 minutes (or 30 or 60 minutes due to block variance) in order to get his win or loss. Imagine if you walked into a Vegas casino and had to wait 10-30 minutes for your token to activate the slot machine. Vegas wouldn’t exist.
On the surface, it may not seem like a big deal. 10 minutes isn’t that long. But it is. Ten minutes is the difference between, “wow this is awesome” and “okay let’s go do something else,” especially when 10 minutes turns into 30. For better or worse, people online have extremely short attention spans. If you’re actually reading this post, instead of just the headline and reddit comments, you have a longer attention span than many.
Zero-conf was crucial in the user experience of SatoshiDICE at its founding. The same is true with ShapeShift today, which enables zero-conf for certain transactions. The same is true for a BitPay invoice, or a digital content delivery service, or tokenized access, or any of the myriad blockchain business models yet to be born. And while we (as ShapeShift, or SatoshiDICE before it) have constantly struggled to balance the risk of zero-conf with the value of user experience, it is a challenge worth our time and money. Sometimes we’ve been double-spent. We’ve lost money because we accepted zero-conf deposits.
But, and this is the key, we made far more, because the user experience was superior. And making the user experience superior is what pulls Bitcoin out of the niche and into the mainstream. Why do you think CoinBase and Circle have gotten so popular? They understand this priority.
This is what many in the debate fail to appreciate: while it is true that zero-conf is risky and will almost certainly cause $X in loss, if it improves customer experience and thus business revenue by more than $X, then it is still a net positive. The cost of zero-conf risk must be understood in the context of its benefits. If your logic is, “zero-conf is risky, therefore nobody should do it,” then you are doing the calculous wrong, for you are only looking at the costs of the feature, not the benefits.
And there is some hypocrisy in a Bitcoiner who vilifies zero-conf because it “carries significant risk” while also holding Bitcoin as an asset (which is one of the riskiest financial assets to hold, period).
Owning Bitcoin as an asset, and receiving zero-conf deposits, are both risky propositions… shall we do neither? I advocate both, when done responsibly.
For some use-cases, the risk is too great. For others, it makes sense. Nobody would advise selling a $20,000 car at zero-conf, but every ice cream street vendor should be more than willing to sell you a cone, and be happy to take the double-spend risk.
Clearly, in the Bitcoin economy, which is increasingly broad and diverse, there is necessarily a segment of business models that benefit from zero-conf, likely some which require it. To them, zero-conf, with all its risks, is a feature, not a bug.
This means that if zero-conf is effectively destroyed – by RBF or any other mechanism in the future – that segment of business will shrink or go away. We can debate how big that segment is, but be careful with your assumptions. More important than any single business today, is the “unseen” business which will never happen tomorrow, because zero-conf was destroyed – nobody being permitted, ever again, to take on the risk of this useful tool.
The current Bitcoin implementation, in my opinion, offered a very elegant balance between instant settlement and security. Zero-conf was always an option for merchants or individuals – it came with risk, but it was in many cases manageable, and brilliant companies like BlockCypher rose up to make it even more manageable. For those who didn’t want any risk, they could decide to wait for one or several confirmations. Neither group infringed on the other – SatoshiDICE was able to take on the risk of zero-conf while other firms decided to wait for blocks. Mutual harmony was enjoyed.
And yet, if Bitcoin changes in such a way as to make zero-conf completely unusable for anyone, there is no longer choice or discretion permitted. The only option is to wait 10, 20, 30 mins for blocks. This won’t affect some businesses, but others will be hampered or destroyed. And businesses unimaginable today, perhaps the killer apps of the future, may never bloom. The choice between user-experience and security won’t be up to the business: it will be rigid, set in stone by the protocol – sometimes this is wise, sometimes not.
It may be that RBF is a brilliant and much-needed new feature. Perhaps RBF won’t kill zero-conf anyway. The point here is simply to convey the importance and value of zero-conf – to suggest to hardened critics of zero-conf that, in some cases, it is a valuable and logical choice, and shouldn’t be dismissed so willfully.
Consider too that if Bitcoin’s development takes it down a path that reduces use-cases, such as by destroying all use-cases which benefit from zero-conf, then necessarily other blockchain assets will fill in that void (Litecoin, anyone?). And this is okay, indeed ShapeShift benefits to the extent that there are many digital assets. But I’d like to simply appeal to the community to be careful, for none of us want to make Bitcoin worse.
If RBF is a true benefit to Bitcoin, then great. But let’s adopt it only if its benefit clearly outweighs the potential loss of valuable zero-conf functionality.
It would be unwise to abandon zero-conf merely because we were blind to its virtue.
Some background on RBF
RBF is a modification to Bitcoin confirmation handling, in which transactions currently in the mempool (ie – not yet confirmed) can be replaced by a subsequent double-spend transaction if that 2nd transaction has a higher fee. Put simply, before RBF, if you double-spent two transactions, miners would usually ignore the second one, because they operate on a “first seen” principle. Thus the first seen transaction is “probably going to confirm.” With RBF, however, when a double-spend occurs, the one with the highest fee is the one confirmed. Thus the first seen transaction is somewhat meaningless.
An important caveat here is that only transactions specifically marked with the “RBF flag” are susceptible to this new rule. A transaction without an RBF flag will still follow “first seen” rules, presumably.
This means that wallet software which defaults to adding an RBF flag will send transactions which, probably, cannot ever be accepted at zero-confirmations, because any subsequent double-spend of that transaction, if it includes a higher-fee, will replace the original, thereby defrauding the recipient.
In other words, transactions from an RBF-enabled wallet will always require 1 confirmation, because the risk of double-spend goes from “possible” to “almost certain.” If the majority of wallets and miners adopt this RBF policy, zero-conf may go away.
