in Bitcoin Cash we find it very valuable for people and merchants to feel secure in accepting a transaction even before it has been mined. We call those "instant transactions", some technically inclined also know them as "zero-conf".
This goal of making sure that instant transactions are secure to accept for most merchants leads the miners to always keep blocks big enough so your transaction will be included in the next block. This and priorities of mining will mean any transaction offered (and valid) will get mined.
The biggest risk we currently have in instant transactions is double-spending attacks. This is when a thief intentionally creates two transactions spending the same coin. Knowing that only one will get into a block and thus if a merchant is fooled into believing it was a good payment, he can be stolen from because the money never will arrive. (more here).
Research shows that the vast majority of attacks fail. So the worry about this attack on instant transactions is very small. But the problem we currently have is that attacks go undetected by the merchant. This means that a thief can come in every day and try again until his attack is successful. This is really bad for merchants as it gives the thief an advantage.
To make instant transactions have less risk, we need to inform the merchant about them the moment they happen. And we need to do this without making otherwise failed attempts of double spend suddenly pass (remember the vast majority fail, lets keep it that way).
As a software developer, or even an architect, we should not have the illusion we can somehow decide which transaction should be confirmed and which rejected. Any system build from rules can be manipulated and abused by a smart exploiter. Next to that, no human interaction is predictable enough to write code to decide what the expected outcome is.
As such, we do NOT have as a goal changing or influencing which of the double-spending transactions gets mined. The previous goal of notifying the person being double spend will be enough to make the people alert enough to deal with any outcome after the fact. For instance making the thief wait for the confirmation of the transaction.
Instant transactions by default have a greater risk to them than confirmed transactions. The more confirmations there are the more immutable the transactions are, which is great to kill all risk.
If we can ask the miners and other fully validating nodes to create a message which will be send around the network warning everyone the moment a double-spend transaction is seen, then we can fulfill the goal. Which is that merchants will get informed about their client actually trying to steal from them.
We can't just send a simple message because Bitcoin Cash is a permissionless network. Someone naughty could create lots of messages, even though they might not be true. So we need something that can be validated by any full node or SPV node to be an actual warning and not a false alarm. We should also be wary that some joker could create correct alarms of non-existing or irrelevant transactions. For instance create one proof and just keep sending it every minute forever.
What might solve this issue is a double-spend proof. The proof can only work if it is accompanied with one of the transactions. This means that the proof has a very limited lifetime as that transaction will get confirmed after which the proof is useless. Can't double spend an already confirmed transaction.
When a merchant, for instance using an SPV wallet, receives an incoming transaction from our thief the proof will be send shortly after, notifying them of the problem.
Naturally, if a thief makes a mistake and fails make a (double-spend) transaction that the merchant sees, the merchant will simply not get an Ok on his wallet and prod the client to make an alternative payment. A failure to double spend means we don't notify the merchant. I personally find this perfectly fine to avoid a police-state feeling where intentions of thieving are punished.
The double spend proof is described in a specification (here) where it also makes clear that this is a new feature that when people ignore it will not hurt them one bit, but should their wallet implement it they will benefit from the alert.
5 of 5 reviewers say it's worth paying for
0 of 5 reviewers say it's not worth paying for