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.

Security Deposit

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!

Issues

So has 0-conf been solved definitively and forever? Well, maybe, maybe not. Here are some considerations:
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Opinion

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?"
 

$9.50
35.0¢

Reviews
3 of 3 reviewers say it's worth paying for

0 of 3 reviewers say it's not worth paying for
Comments
  spent 10.0¢
Looks clever! One question: Wouldn't the CHECKSIG part of the forfeit output need to be timelocked?
0.0¢
   1yr ago
10.0¢
  earned 10.0¢
@im_uname i think so, because otherwise the refund would be competing with the revoke tx. I forgot to mention that; Thanks :)
10.0¢
   1yr ago
10.0¢
  spent 10.0¢
Yup, and an additional "problem" is, of course, this requires reworking wallets across the ecosystem for sending (for making these in the first place), receiving (for recognizing which ones are "insured") and mining (for recognizing DS and claiming bounties).

It does no harm to existing usecases, that's a big plus.
0.0¢
   1yr ago
10.0¢
  spent 10.0¢
My question is probably silly because I think if it was possible it would have been done but... couldn't this protocol award the penalty to the merchant instead of the miner... or maybe both the merchant and the miner...?
I think the incentives would align a lot better that way, wouldn't them?
0.0¢
   1yr ago
10.0¢
  earned 0.0¢
@PedroR You could do "both". Only rewarding the merchant and not the miner doesn't really work because if the doublespend is successful the bounty won't be paid. There has to be an incentive to the miner to favor one over the other.
0.0¢
   1yr ago
  earned 95.0¢
Theres a few problems with this scheme besides the obvious one of incentivizing miners to penalize users, who may be victims of a simple mistake or wallet misbehavior, for a small to no risk reduction for merchants.
UX: no 0-conf for you tonight! Imagine you want to pay for dinner costing $20. One night you have $70 and everything is fine, the other you have $20.01 and it's not accepted as 0-conf because there's not enough to generate a significant "deposit".
Miners extra job While you are in control of your outputs, you are not in control of your inputs. After you, well behaved bitcoiner, do and A->B+F transaction (F being the forfeit output) a miner can send a small amount to A. So your wallet must be smart enough to ignore the money in A until F is spent.
First seen, except... Spending the forfeit output can be immediatly after the transaction or even by the double spender. To spend the forfeit output the miner may have to kick out a first seen transaction for that output. It seems a bad precedent to start ignoring the first-seen convention.
General first seen desincentive? If the miner sees the doublespend first and the regular transaction with a forfeit output second, should the second be accepted so that the forfeit output can be claimed? If the miner does not do this then the merchant's risk is slightly lower than the regular 0-conf but not that low. If the miner does this then any merchant accepting 0-conf without this scheme can be tricked by doing the opposite (send a transaction without forfeit to the merchant and a fake honest transaction later).
In general it seems that to reduce the merchant's risk slighlty, we change miner's incentives, increase wallet complexity, and reduce the usability of the system.
$1.05
   1yr ago
10.0¢ 25.0¢ 25.0¢ 10.0¢ 10.0¢ 10.0¢ 25.0¢
  spent 10.0¢
the use cases are many: any time one or more confirmations are required (exchange deposits, instant play on gaming/betting platforms, in-person transactions with a vendor o vending machine). perhaps also for big ticket purchases online -- although one can't double spend in this case (item is not shipped), it is still wortwhile having the feature. as a customer who never intends to cheat, i want to pay, get my receipt and forget about the transaction until item shows up at my door. in no case do i want to wait for 1-conf to get closure. (50 minute blocks happen at the darnedest of times.)
0.0¢
   1yr ago
10.0¢
  earned 25.0¢
My vote is for for the way @jonald_fyookball wrote about this - very well appreciated.
Otherwise, the concept considered opens multiple telescoping new attack surfaces. Although I am always in favor of well-investigated incremental system hardening, something like this is moving far in the wrong direction in that it:
  • creates more dependency/exposures which
  • consume more work to resolve and in doing so
  • will add hackpoints for payment hijacking or interdiction.
  • risking what works for many in favor of a very few transactions.

Although Zero-conf may seem fragile, at this time it works for almost anything reasonable.
Transactions which rely on Zero-conf already factor in a loss predictor, or they will eventually succumb to losses in a Darwinian fail.
Businesses reliant on Zero-conf recognize this.
For Businesses and transactions that wait for 1 or more confirmations this issue is almost completely irrelevant.
Any kind of solution for it must not -add- more chinks in the armour.
This does not mean that we should cease exploring how to improve, but "adding multiple moving parts" should always be a big honking red flag.
cheers to both sides of the argument: even a bad idea must be rationally considered and discussed because such deliberations illuminate the future.
35.0¢
   1yr ago
10.0¢ 25.0¢ 10.0¢
  spent 10.0¢
@79b79aa8
Yes indeed: those 50-minute blocks are a much bigger problem than zero-conf.
Those long block times affect all transactions.
Although I agree in principle we might improve zero-conf, improving the block-time consistency might be a better task to work on for now.
0.0¢
   1yr ago
10.0¢
  earned 25.0¢
What I very much dislike about this proposal is that it is not cash like. With ordinary cash payments, this is our benchmark, this is not necesarry. I don't want to place a deposit for payments up to like lets say $100 dollar. If a have 1 dollar and want to buy a item of one dollar (or any amount) I like to pay and be done with it. It als requires for you to have more money than you are able to spend as you might need money for a deposit. Also deposit amounts could be unfairly high for some in counties with high inflation. Requiring a deposit would exclude them from services. BCH is for everyone.
35.0¢
   1yr ago
10.0¢ 10.0¢ 25.0¢
  spent 10.0¢
So many people in the comments don't get that if you don't like it, you don't have to use it and it doesn't affect anyone - since it doesn't involve consensus or relay rules.
Criticisms about how the proposal would work out (or not) are valid, "criticism" about how it affects other kinds of transactions are just ignorance, especially garbage like @TheOneLaw 's "risks what works for many" - if you like your payment solution and your merchant likes it too, keep using it.
0.0¢
   1yr ago
10.0¢
  spent 10.0¢
@Jonald_Fyookball Thanks for the answer. I guess 50% for the merchant and 50% for the miner would do...
0.0¢
   1yr ago
10.0¢
  spent 10.0¢
But I don't think this method work.
Actually, 0-conf is safe enough for ordinary users'tx, or it's very easy to defend.
But only miners can double spend 0-conf tx, and merchant can't defend the miners's double spend, because miner cannot broadcast the double spend transaction tx2, and the other miners cannot get the "different signatures(that in the article)".
0.0¢
   1yr ago
10.0¢