Awemany’s 0-Conf Solution
Awemany is a Bitcoin Cash developer who contributes to the Bitcoin Unlimited project. He just unveiled a new scheme to handle 0-conf transactions, based on the upcoming OP_CHECKDATASIG op code. For the uninitiated, “0-conf” refers to transactions that haven’t been confirmed in a block. As you probably know, Bitcoin (BCH) blocks arrive every 10 minutes on average. But in a retail environment, who is going to wait 10 minutes? That’s why its important to improve the reliability of “zero” confirmation… in other words: just send the transaction and you’re done, instantly. Today, 0 conf is mostly reliable because miners respect the “first seen rule”. If there’s an input for a transaction that is then used in another transaction, miners will ignore the second transaction. However, the reliability thus depends on the good will of miners. Although miners normally have no incentive to undermine the system, it is good to think about ways we can improve 0-conf reliability. This is the motivation for Awemany’s proposal.
The idea is based on a special kind of zero confirmation transaction (ZCF) that includes a security deposit. In the traditional world of credit cards, you might have a temporary charge (a “hold”) of $100 when you buy gas, since the gas pump doesn’t know exactly how much gas you’ll put in your car. The hotel may put a hold of $400 since they don’t know if you’ll raid the minibar or trash the room like a rockstar :) And so with Bitcoin, in addition to the normal purchase, you would at the same time be making a security deposit which would then be returned back to the consumer, or forfeited to a miner in the case of an attempted double spend.
First part of the solution is using an additional “forfeit output”
Transactions can have multiple inputs and outputs. In this scheme, you still have your ordinary output to the merchant and usually a change output back to your wallet, but you also have one additional output going to a “forfeit script”. This is the security deposit. But it’s all part of just one transaction when you pay the merchant, just like you only have to swipe your card once at the gas pump.
Second component: spending the forfeit for multiple transactions
OP_CHECKDATASIG (CDS) is a new op code that allows signature checking against a message and public key. With CDS it is possible to have a message that is part of the redeem script (like in a sports betting use case), but it is also possible to simply require any message as is the case here. (In other words, you could have a specific message to be signed for, or not.) In this scheme, the idea is that the security deposit money can be spent by a miner as long as they have two different signatures on the same public key.
How the security deposit works
The script that can spend the output of the security deposit can do so in two different ways. In the normal case, the consumer will be able to spend his deposit back to himself. In the malicious case, he will double spend the original transaction, but in doing so, must necessarily reveal a signature on the public key. At that point, miners will see both transactions and will be incentivized to spend the bounty.
Summary of the Scheme
Ok, so to summarize, the consumer will make a special ZCF transaction that pays the merchant and simultaneously posts a security deposit. If the transaction is honest, the consumer can later reclaim his deposit. If he tries to double spend, he necessarily reveals a second signature over the same public key which is then used by miners to claim his deposit for themselves. Pretty clever!
So has 0-conf been solved definitively and forever? Well, maybe, maybe not. Here are some considerations:
- Address re-use. Obviously if the bounty spend only needs any 2 signatures from a public key, an old signature from a previous transaction could be used. Wallets implementing this would need to be sure the address is fresh. Not a big deal, but something to be aware of.
- Institutionalization of claiming bounties. The scheme only works if miners actually claim the bounties on a regular basis. This probably requires some new code to be introduced on full-node clients. It doesn’t require a consensus change however.
- Game theory dependence. Note that the scheme doesn’t really protect the merchant in the sense of getting their money back. It only punishes the consumer by giving their money to a miner. So it depends on the fact that most consumers don’t want to lose money. This is a weaker guarantee, could be open to some attacks, and needs to be tested in practice.
- Standardization. Exactly how much should the security deposit be? Unless the amount is known or there’s a standard way to derive the amount, it will be chaos. So there needs to be a standard method. As with the traditional fiat security deposits, probably the merchant should specify… which means a payment request needs to be made, so this needs to be worked into some request format like Bip70 or maybe a simple URI request.
- Capital requirement. In order to provide sufficient incentive, the security deposit will need to be of ample size. Perhaps as big or bigger than the primary transaction output, depending on the case. This could put a burden on consumers, although if you think about it, it is not worse than the existing fiat solutions.
This seems to be a pretty good idea. It doesn’t require any BCH protocol change. It also doesn’t require any “preparation” from the user in terms of a transaction that you must do ahead of time. A wallet like Electron Cash could implement this as an optional feature. But before doing so, we should see how much the Bitcoin Cash community likes the idea and if we think it would be used in practice. A big question is "do we really need it?"
3 of 3 reviewers say it's worth paying for
0 of 3 reviewers say it's not worth paying for