Double Spend Proofs: What they are and how they work.

4 430


In my youth I read a the wonderful story about a car manufacturer that made a very fancy car which had superb traction and when you went through a corner you would not feel any vibration or other problems while steering it through even the most sharp corners. It was amazing.

And it was deadly.

When the car got tested by people that were not professional drivers, those people got confused with the total lack of vibrations, slippage and other things that happen when you go through a corner too fast. They just kept on going faster until the car eventually could not compensate, slipped and crashed.

The car maker ended up artificially added vibrations to the steering wheel when the car noticed it was getting close to its limits. This made the people realize they were getting to the limits and they slowed down.

No system is perfect and the average human operator will use it within limits. The problem with the car was that it didn't make clear what its limits were.

A system that is hiding all its inner working may forget that showing weakness and limits are features that we, humans, require in order to understand how to use it. Having added vibrations to the steering column made the car a very popular type which is still sold to this day.

Bitcoin Cash is a similar system that hides most of its inner workings.

In Bitcoin Cash the Double Spend Proofs (DSPs) create notifications when bad things happen. So we don't have an illusion of the system being perfect. And by getting accurate feedback of where the limits are, we will be more comfortable in using the system to its fullest.

Double Spend Proofs identify people and systems that are faulty or intentionally trying to break the system for their own gain.

This identification of such bad actors comes with a cryptographic proof of the deed and allows users to take action to avoid being stolen from.

Zero-conf and double spends

When in 2009 Satoshi rolled out the Bitcoin system he solved, for the first time in history, the decentralized avoidance of double spends in a chain of transactions.

We have since then started to explore the safety of transactions that are not yet part of the chain. The so called "zero confirmations" transactions.

We can say that the risk of accepting a payment is directly related to how many confirmations it has. Where 1 confirmation is when it first gets mined in a block. As such the greatest risk is when it has not yet appeared in a block.

Before DSPs the risk for the thief to try and defraud a merchant was zero. The merchant would not find out and not be notified in all the cases where the attempt to defraud failed. Allowing the thief to keep on trying with zero risk.

Empirical research has been done on the current network. People tried different ways to double spend and realized that the risk of a double spend is actually quite low. They concluded its not easy to pull a successful double spend which defrauds a merchant.

What this research also concluded is that the mono-culture of the network is very important in keeping the double spends from being accepted. All miners run with practically the same settings which makes timing the main tool for the attacker to defraud a merchant.

As the network grows it will become inevitable that miners will change their miner settings in order to become more profitable with their specific setup. The loss of a mono-culture in Bitcoin Cash mining is inevitable and likely healthy. The side-effect is that it will become easier to work around the "first seen" principle that is our main defense against double spends. And this in turn means that the double spend proof will end up being a increasingly valuable tool in the toolbox to keep the network healthy and the instant payment feature low risk.

Two conflicting transactions, how does that work?

The basic Bitcoin Cash transaction takes an existing "output" and spends it. The value embedded in that output we are spending is then send elsewhere in our transaction, itself in turn creating a new output. This triple entry accounting where your transaction removes one output and creates a new one assumes that there is only one entry that spends any single output. Should there be two independent transactions which both spend the same output and send it to different places, that is what we call a double spend.

Because in Bitcoin Cash all transactions are cryptographically sealed, the attempt to move one output twice is a standalone proof that the owner is responsible for those two transactions. This follows from the simple fact that the owner of the output is the only one that can move the funds. A double spend proof is not much more than a pointer to the output it tries to double spend and essential parts of the transactions doing the spending.

Including both cryptographic signatures, of both spends, that only the owner could have made. It is then just a matter of validating both signatures that allows us to establish without a doubt that the output has been spent twice.

The full specification of the Double Spent Proof is here.

$ 8.60
$ 5.00 from @powellquesne
$ 1.00 from @JonathanSilverblood
$ 0.50 from @Read.Cash
+ 5


If I understood this post you're saying Double spent proofs would help when there's diverging mempool policy on the network.

This is the exact opposite of what Jonald Fyookball wrote on this : "Double-Spend Proofs work WITH Unified Mining Policies. They Are Not a Substitute for Them." (

Amaury also stressed this point and said that it would mainly benefit point of sales systems

$ 0.00
4 years ago

If I understood this post you're saying Double spent proofs would help when there's diverging mempool policy on the network.

Yes, and as with any open market it is inevitable that we will see such divergence.

This is the exact opposite of

I can see how you read it that way, but he doesn't say that. The main difference is that Jonald started with the conclusion and worked his way back. The conclusion is that all miners should keep the same policies (and, implied, run ABC).

You can understand the point of view of the article: miners want to run with different settings, specifically greater unconfirmed depth, and ABC doesn't support this. Miners could switch to another implementation. Then an article comes out making clear why all miners should keep the same settings...

To the DSP problems Jonald sees:

The main reason that double spend proofs don’t fix inconsistent mining policies is that these proofs can only be used as an alert, (a notification or message). They don’t actually prevent double spending or compel nodes to change their behavior.

Notice that he talks about "inconsistent mining policies" as though they are a problem to be fixed. That is an assumption that is not supported in his article. And more important it is dishonest writing as the real problem we were talking about was keeping zero conf low risk. A problem that DSPs in actual fact does fix.

So what happened in that article is that Jonald looked at a completely different "problem", and was indeed able to state that DSPs don't fix this new problem. But the "problem" he came up with is a natural effect of competition. Is it really a problem?

The underlying reason for writing his article was that miners already wanted to diverge their policies (which jonald labeled the problem in the above quote). Quod erat demonstrandum.

$ 0.00
4 years ago

The side-effect is that it will become easier to work around the "first seen" principle that is our main defense against double spends.

This side-effect is possible but not necessary. So far, different implementations* generally manage to apply the same consensus rules - so they should also be able to apply the same node policy.

  • At least ABC and BU. Perhaps some less popular nodes still have some shortcomings here.
$ 0.00
4 years ago

so they should also be able to apply the same node policy.

The difference between consensus rules and a node policy is that policies are allowed to be changed by miners with zero effect on the block being a good block and accepted by other miners.

For instance the transaction size is by consensus rules max 1MB, while at the policy level is max 100KB. What this means is that if a miner includes a 200KB transaction his block will be perfectly Ok .

Miners are allowed to change their policies.

$ 0.00
4 years ago