Hello all,
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.

Goal

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).

Non-Goal

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.

Basic solution

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.

Double-spend proof

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.
 

$8.25
$1.00

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

0 of 5 reviewers say it's not worth paying for
Comments
  earned 0.0¢
There are several (in my view unnecessary) default limits carried over from core which weaken zeroconf. The unconfirmed ancestors limit for example. These kinds of limits become quasi-consensus, and especially in the case that implementations differ, it creates a simple doublespend vector. The lowest hanging fruit in improving zeroconf is removing limits, or making them officially consensus rules so we can be certain all implementations are deploying them consistently.
10.0¢
   2mo ago
10.0¢ 10.0¢
  spent 10.0¢
Couldn't most of the merchant risk associated with instant transactions be solved by using a very well connected SPV wallet with low/no defaults? The SPV would use a sliding scale wait time based on the transaction amount. i.e. wait longer for larger value transactions from a few seconds for very small value transactions up to n conformations for large value txns if necessary. SPV would relay a reject back to the merchant for any instant transactions that spends the same output.
0.0¢
   2mo ago
10.0¢
  earned 0.0¢
@MJahnz SPV wallets by design limit their view of the Bitcoin system to only the part that they are interested in. Which means that they only see transactions that use the addresses the SPV wallet is interested in.
For this reason the double spend transaction that pays the thief back his own money will not be seen by the merchants SPV wallet. Because none of the addresses from the SPV wallet are used in that transaction.
As such, an SPV wallet is currently mostly blind to double-spend attempts. The only solution that solves this for SPV we know of are double-spend-proofs.
0.0¢
   2mo ago
  spent 10.0¢
@TomZ Apologies I meant to say SPV service. e.g. a merchant would run an SPV wallet that connects to and SPV service. The SPV service would be very well connected and monitor all transactions for double spends. Does Flowee expect to be very well connected and does it have the potential to monitor all txns for double spends?
0.0¢
   2mo ago
10.0¢
  earned 0.0¢
Thanks for the followup, sorry for the slow reply @mjahnz
Yes, Flowee intends to cater to that audience. The point with a double spend proof is that the full node doesn't have to be well connected. There no longer is a reason to.
That said, yes, Flowee intends to be well connected. But there will always be a larger risk that double spends are not seen that way than with the proofs.
0.0¢
   2mo ago