BUIP088: Double spend proof creation and forwarding

[torusJKL]

BUIP088: Double spend proof creation and forwarding
Submitted on 29th March 2018 by torusJKL


Background
A double spend can happen within the time from the initial broadcast until the transaction is included in a block.
Although this is on average within 10 minutes at the point of sale we need to know that a unconfirmed transaction is as safe as possible within seconds.

Currently double spend proofs are not communicated thus a merchant might not know that there is a high chance of him not receiving his transaction.
In order to detect double spends a double spend proof needs to be created and forwarded by the nodes.


Motivation
By receiving double spend proofs sellers learn about attempts to defraud them faster and can take appropriate steps.
This will make 0-conf transaction on Bitcoin Cash more safe and will give it broader acceptance.

With merchant software going in the direction of receiving the tx directly from the customer at the POS there is no need to receive the whole double spend tx and a proof of double spend inputs is enough to flag a payment.


Goal
The goal of the implementation is that any node that has access to both transactions can create the proof.
And that any other node (even with none of those transactions in the mempool) can validate and forward it.


Task
1) Create specifications for the double spend proof implementation and submit a pull request to the BitcoinCash repo so that others can implement it in their software

2) Develop a double spend proof mechanics based on only sending the minimal part of the transaction (e.g. only the inputs) that is needed to detect a double spend with the following properties:
2a) the proofs are stand-alone evidence of the respend
2b) the proofs are verifiable so that they can't be faked by a 3rd party

3) Add a double spend visualization in the wallet GUI


Timeline
The double spend proof should be developed and to be implemented for BUCash with the aim of being ready for inclusion in the scheduled November 2018 protocol upgrade.

Caveats
The lead developer will have discretion and flexibility to modify details specified in this BUIP, while keeping within the spirit of the BUIP with the goal of advancing 0-conf tx security on Bitcoin Cash.


References
Comment by Tom Zander describing that only some hashes need to be communicated

 

[torusJKL]

@Tom Zander thanks for your input on BUIP085. Based on them I have created this new BUIP.

@solex please add the BUIP to the index.

@theZerg please provide your input.

 

[Mengerian]

Chris Pacia's proposed spec on double spend alerts is relevant for this:

https://github.com/cpacia/spec/blob/master/double-spend-alerts.md

 

[Christoph Bergmann]

Chris Pacia's proposal seems nice. I guess it relays some signed part of the transaction, so that it is impossible to dos the network with wannabe double spend proofs? If yes, and people agree on it, I think this is much better than BUIP085

 

[theZerg]

double spend proof discussion:
https://github.com/bitcoincashorg/spec/pull/57

 

[dgenr8]

This BUIP088 doesn't yet have a design attached, but the descriptions of the proof message that @Tom Zander has provided appear to be better than Chris Pacia's design in two ways:
- They include a reference to two transactions, so they are stand-alone evidence of the respend
- They are actually verifiable because they contain two signatures and the complete underlying signed messages, which is critical for any proof

However there is still a problem with the proof as described so far:
- The outputs are not included
In the common fast-respend case, this means 50% of the time the victim of a respend attempt will not learn of the attempt until confirmation (if he is lucky enough to get paid) or just as likely, never.

The biggest problem is with the proof approach itself:
- There is no way for anyone to prove when they first saw a transaction
This is an observation that every node must make for itself. We can only try to assist them in doing so. The best thing a node that witnesses a respend can do is to relay it immediately, allowing other nodes to independently measure the time they receive it.

Concretely, the "proof" idea risks making UTXO's permanently unspendable as troublemakers create a new "proof" using days- or weeks-apart spends every time a new spend attempt is seen.

Counterintuitively, it is not dangerous to forward a respend. Peers will either alert on it (where today they discard it), or see it as the first spend. In the latter case, the remote node's perception of the sequence is no less valid than your own, and at least they can measure the time interval for themselves.

My position is that relaying the respend transaction itself per BUIP085 is a better first step than a proof message. However, we can do even better. In particular, to address the case of the "early non-propagating respend" a bit more is required which I'll follow up on later in a way which also removes the requirement to rate-limit respends.

 

[Tom Zander]

However there is still a problem with the proof as described so far:
- The outputs are not included
In the common fast-respend case, this means 50% of the time the victim of a respend attempt will not learn of the attempt until confirmation

This is demonstratably false.

There are two usecases;

a) TX1 is seen by merchant, followed by a double-spend notification.
b) TX2 is seen and ignored by merchant, he never gets TX1. He never gives customer his product.

The technology works in both cases and gets the wanted result.

The biggest problem is with the proof approach itself:
- There is no way for anyone to prove when they first saw a transaction

This is false. Transaction propagation is not changed, your node will still see the "first" come in just fine as normal. Proof is just looking at your own mempool.

Concretely, the "proof" idea risks making UTXO's permanently unspendable as troublemakers create a new "proof" using days- or weeks-apart spends every time a new spend attempt is seen.

Also false. A proof includes the signatures which nobody but the spender can create. A proof is also unique to one UTXO. Which is guarenteed to be spent only once (which is the entire point of Bitcoin). Replay or spoofing is impossible.

Next to that, a proof has zero effect on miners picking the first they see and including it in a block. Just like they do today. I have seen nobody suggest we change that. Your argument should basically be used against people changing what miners include when they see a double spend. No change from today has my vote.

 

[dgenr8]

@Tom Zander You don't show any of the things you claim to be "false" to be false. You offer discussion on these points which looks to be very hastily considered.

Consider the fact that relaying proofs instead of transactions greatly reduces the likelihood of nodes actually seeing both transactions.

In no way is your respend proof unique for a UTXO unless the author restricts himself to two spends.

Getting an immediate alert is the entire point of the alert exercise. The merchant should not fail to get an alert just because his peer saw the merchant-paying transaction .01 seconds after the attacker-paying one.

 

[Tom Zander]

> Getting an immediate alert is the entire point of the alert exercise. The merchant should not fail to get an alert just because his peer saw the merchant-paying transaction .01 seconds after the attacker-paying one.

Ehm, no. Its not the "entire point of the alert exercise".

The point of the excersize is to avoid the merchant (or generic recipient) being stolen from.

Maybe you are thinking too much like a technical person that wants 100% of the information to be available to 100% of the world. But I fear that will mean you lose focus on what we are trying to accomplish and who this proof is meant for.

The proofs accomplish the objective without introducing the various attack-vectors that sending the transactions does. Proofs also work for SPV clients, which is super important for the actual point of the excersize. To protect people receiving zero-conf transactions. On their professional Point-of-Sale systems as well as people on their mobile SPV wallet.

 

[dgenr8]

If I thought too much like a technical person, I might design a new p2p message despite glaring UX deficiencies vs. the simpler approach. Just ask the merchant, would you rather know what just happened, or wait 10 minutes or until whenever you decide to give up waiting?

SPV clients need an update to support either kind of alert.

 

[torusJKL]

You mean in the scenario that the merchant receives the double spend tx first and none of the nodes he is connected to relay the tx that was the payment to the merchant, we would have the situation where even if the merchant receives the proof he would not know that the proof is for the payment to him.
It could be anyone's payment because he does not know that these inputs were also used for the tx that pays him.

Whereas if he received both tx he could connect the dots and know that the double spend is for his goods/services.

 

[torusJKL]

@Tom Zander how could a merchant identify the proof if he saw the double spend tx first and none of his connecting node will send him the tx with his address as the output?

He dosn't have to give the goods to the customer because he has not been paid but he does not know why because he never saw the tx to his address and thus does not know that the proof was meant for him.

Would it be feasible to also include the output addresses into the proof even tough it will make it larger?
Or is there another way for the merchant to connect the dots and recognize that the proof was meant for him?

 

[Tom Zander]

@torusJKL I actually wrote a yours post on that very recently that you may enjoy; https://www.yours.org/content/everything-you-know-about--bitcoin--wallets-is-wrong-f9dd2dc4a7f7

The answer is that the industry is already moving to the situation where the transaction is sent to the merchant as part of the payment-protocol. BIP70 (which Bitpay uses) does this. As such the "first seen" problem is eliminated because the bitcoin transaction that pays the merchant is sent to him. He then offers it to his full node that either immediately flags it as a double-spend, or will within 2 seconds (or so) receive a double-spend warning.

So an output address is not needed to be included.

 

[torusJKL]

@solex this BUIP is ready.
Please include it for voting on 07.05.2018.