How well does zero-conf work?
hey guys,
just wanted to add some details around the actual state of the zero-conf transaction security right now on the Bitcoin Cash chain as this is pretty exciting and I feel its in need of more attention.
For those that are just tuning in, zero-conf transactions are the ones that have not been put in a block yet and double spending is absolutely solved by a transaction being mined. So, the question is sometimes raised on how risky it is to consider a payment final before it is mined.
Lets find out.
First of all, sending a second transaction to double spend your own can only lead successfully to a double spend in a very small amount of time. Within 3 seconds the entire network has the first one sent, so if you wait longer your new transaction will simply get rejected by each and every peer. No effect. You basically need to do it at the exact same time as the original one that the merchant has to see.
A user that successfully sends two transactions and is already extremely lucky to make it into some miners mempools then gets into the gamble of getting the one they want mined. If that miner didn't get the block, no luck.
This is a big gamble and most of the DS-attempts fail with simply paying the merchant anyway.
Double Spend Proofs
Today we have on bitcoin cash a double spend proof. A set of crypto details that prove 100% that one transaction is trying to double spend another. So if someone pays you in a transaction and then your server gives you a double-spend-proof for that transaction, you know that they try to steal from you.
Merchants can act on it as they want. We didn't make DSProofs any more strong than just a message to the merchant because the human factor is important. People testing, people confused and all that are relevant and various service minded companies will prefer to decide for themselves what the policy is. Anything from calling the police, confiscating the funds (in most cases the attempt fails to double spend) to simply giving a stern talking to. The currently deployed DSProof solution allows all of this. So ask your wallet to support it! (Link them to this).
When you are in front of a cashier they can decide what to do. But an anonymous service or casino or vending machine are most likely just going to cancel the order and if the money arrives it will cover the administrative costs. The thief that ran some specialized software to double spend loses. I can't lose any sleep over that...
Payment Protocol improvements
There is another thing we want to do. An improvement of behavior when it comes to payment protocols. The most used payment protocol (BIP 70) specifies that the customer is to send the transaction to the merchant and the merchant is then the one responsible for broadcasting it to the network. But this doesn't happen in any current implementations.
Yet, having the merchant send the transaction to the network is super useful as it allows them to play with timing (we are talking about some 100s of milliseconds) of broadcasting the transaction.
This is super useful because the attacker has to know the timing in order to broadcast his offending transaction himself and have the right effect of his second transaction landing in the mempool of a miner. If the attacker is too fast, the merchant will instantly know as the transaction is rejected by the node he connects to (and he gets a bonus double spend proof).
If the attacker is too slow, the chance of the attack succeeding drops massively. (and still the merchant gets a double spend proof).
In short, in mainnet today:
stealing from a receiver by double spending has a very low probability of succeeding.
Any DS needs to be sent within a second, max two, in order to have any realistic chance at all. The merchant-run-full-nodes simple reject it as they are the ones that value the first-seen rule to be kept, there is no reason to think it won't be kept.
We can still improve when we start to develop better payment protocols which makes it even more certain that the money will go to the merchant.
There is in practice no risk to a merchant that uses a proper backend (which all wallets and point of sale software do anyway) because then they WILL learn about the double spend attempt.
Matching the ridiculously low chance of success with a certainty of being caught and the repurcussions.
Here is a video example of what happens when a wallet checks for double spend proofs. Notice that the wallet doesn't need to check very long, it really keeps payments instant.
Is it possible for a double-spend proof message to be generated when the sender is not attempting to double-spend? For instance, perhaps a node changes how the transaction looks (malleability) before sending it on? I ask because I think I once had to wait for a confirmation in spite of the service I was using taking advantage of double-spend proofs. I was under the impression they just didn't get proof I was NOT double-spending, but based on your article here, it sounds like they got proof that I was attempting to double-spend (when I wasn't).