BUIP085: Double spend relaying

[Tom Zander]

@sickpig

XT introduced the sending out of both transactions. It does this via the same method that all transactions are relayed. Using an 'inv' and all that.

No critisism to XT, proofs were impossible at that time. But the downsides were already then discussed and well understood. Point is we can do better.

The 'first seen' adage gives a lot of certainty to the network, avoids unpaid (fee-wise) bandwidth to be used and makes sure that the only obvious attack is that we have a race condition in the first seconds of the network.

More details on the 'why' in the BU PR 1018
[doublepost=1522917744][/doublepost]

I wonder if we could go even further and make the merchant the one who's going to broadcast the txn to the network and not the buyer.

I would be a great proponent of that as well.

We need a protocol that allows the transfer of a transaction between two parties in a standard way. The example you give is a good one, but there are various other reasons why this would be great to have.
For instance a transaction can be sent partially unsigned. The receiver can sign one of the inputs and hand it back. This allows multi-sig multiple parties signing a transaction to become possible.

Bottom line is that a QR code assumes one p2pkh output (and maybe a simple p2sh payment). Nothing else is possible. To allow a well constructed but not fully signed transaction to be sent leads you to be able to do anything. This would be a wonderful buildingblock for many next-gen applications and hardware (like the kaching project)

 

[Christoph Bergmann]

1. BUIP085 does a great job in detecting a simple double spending attempt (sending the same inputs in milliseconds to a miner) - with 100 percent certainty after ~2seconds. A merchant can simply refuse to accept such a payment. I don't know how @Tom Zander s proposal can make this better.

2. BUIP085 does not help anything against the "Peter Todd Attack", which is to send a transaction some miners deem invalid to the merchant (irregular property, very low fees), while sending a valid transaction to the miners later. This can happen at any time between the initial payment and the next block. BUIP085 does not just not protect against this (it can happen even 8 minutes later), it helps to do this attack by relaying the double spending transactions. I don't know if Tom's proofs do it better, but I can't imagine how such proofs help 0conf if the double spend is done minutes later. However, what @sickpig proposed - that the merchants relies the initial transaction by himself - would fight this attack with near 100 percent certainty.

3. What remains is a double spending with help of a miner. It is impossible to protect against this. But with BUIP085 and sickpigs proposal you can reduce any other double spending attempt with up to 100 percent certainty.

 

[Tom Zander]

@Christoph Bergmann Did you make a typo?

BUIP88 is the one that sends the inputs to the miner. Not BUIP85 (which sends the entire transaction). And only with BUIP88 do you have 99% certainty after some seconds, as you point out the "peter todd attack" isn't caught by BUIP85, it IS solved with BUIP88.


One minor thing, you write;

> I don't know if Tom's proofs do it better

I would ask you, and anyone else, to avoid making this about people. I reject any ownership of the idea. I don't want credit, I don't want to pick a name. I just call it "double-spend-proof".

All I want is that the best solution is chosen for Bitcoin Cash. And I will explain the concepts as I understand that to anyone, but I expect others to actually do the work as I don't do protocol work anymore.

 

[torusJKL]

as you point out the "peter todd attack" isn't caught by BUIP85, it IS solved with BUIP88.

How would BUIP088 protect against this better?
Assuming the first tx has very low fees and thus is not accepted/relayed how would a double spend proof (as defined in BUIP088) be triggered?
Wouldn't the second tx just been accepted as "the first seen"?

 

[Christoph Bergmann]

I'd be interested in this too, and I find it hard to believe that BUIP088 can protect against the Peter Todd attack.

I also don't think it makes sense to introduce something new, when the combination of BUIP085 + SickPig's proposal to extent the payment protocol to let merchants sent the transaction would basically eliminate every non-miner double spend with a certainty which is enough for nearly everything.

 

[Tom Zander]

How would BUIP088 protect against this better?

Apologies, I thought that was obvious.

A transaction is either in zero mempools (in which its not an issue) or in at least one mempool. The beauty about a double-spend-proof is that any node that has access to both transactions can create it. Any other node (even with none of those transactions in the mempool) can validate and forward it.

The effect is that while the distribution of a transaction is limited due to rate-limiting, policies and other such things, the distribution of a double-spend-proof has no such limitations.

Therefore, even if there is only one node that has the low-fee transaction (again, if nobody does, its not a double-spend) in their mempool then it will be known shortly by the entire network.

This is one of the most interesting parts of a proof, it sidesteps all the limitations of transaction broadcasts which would have been possible to use to fool the system.
[doublepost=1522959217][/doublepost]

I also don't think it makes sense to introduce something new, when the combination of BUIP085 + SickPig's proposal to extent the payment protocol to let merchants sent the transaction would basically eliminate every non-miner double spend with a certainty which is enough for nearly everything.

It would be rather trivial to abuse that system. I mentioned this in several locations. You even mentioned the low-fee option, there are the large-tx option, the delayed option and my favourite, the option to saturate the network with huge unminable transactions because they are all double-spends of a tx that pays you back at zero-fee.

 

[Christoph Bergmann]

A proof does not help anything when you want to accept 0-conf tx in seconds, but the double-spending transaction is sent a minute after the initial transaction, for example.

But I agree, double spend proofs can be superior to simply relaying double spends. If they can't be faked, I'm all for it. Is your proposal similar / the same as Chris Pacia's?

The beauty of letting the merchant initiate a transaction is that he can control that the transaction is accepted by the miners.

 

[Tom Zander]

> A proof does not help anything when you want to accept 0-conf tx in seconds, but the double-spending transaction is sent a minute after the initial transaction, for example.

But it does. It may be that at that time the merchant already let the customer leave the building, in which case it is not for the merchant to act on, but for the miner. And, again, a proof is better than sending both transactions.

I explained that usecase here;


Additionally, a good point-of-sale software will be able to still update the database of this double-spend proof. As such they will know why the transaction to them never got confirmed.

 

[Christoph Bergmann]

Ok, got this, it does some help, not as much as letting the merchant submit the transaction by himself, but if we count on miners being honest, it at least prevents that they accidently confirm this transaction.

What happens if I send the same inputs with different outputs at the same time? Will NodeA think a is the right tx, and NodeB, b? Will they confuse the miners with strange double spend proofs?

And are there DoS-attacks, sth like building tx which cost a lot of cpu to build / validate double spend proofs?

 

[Tom Zander]

> not as much as letting the merchant submit the transaction by himself

Did you know what BIP70 (the thing that bitpay now uses) is already quite old and it actually sends the transaction to the merchant. No change in protocol is needed to make this work, just the merchant software.

> What happens if I send the same inputs with different outputs at the same time?

Thats the definition of a double-spend. All we talked about in these threads is what will happen.

> Will they confuse the miners with strange double spend proofs?

I don't understand, what is strange. What problem do you see?

> And are there DoS-attacks, sth like building tx which cost a lot of cpu to build / validate double spend proofs?

The double-spend-proof is the solution to various DoS attack scenarios that the relaying of both transactions introduced. I mentioned some of them before:

The 'first seen' adage gives a lot of certainty to the network, avoids unpaid (fee-wise) bandwidth to be used and makes sure that the only obvious attack is that we have a race condition in the first seconds of the network.

More details on the 'why' in the BU PR 1018

Also see the FAQ;
https://www.yours.org/content/zero-conf-and-double-spend-faq-a7b728f7bc2c

 

[Christoph Bergmann]

> What happens if I send the same inputs with different outputs at the same time?

Thats the definition of a double-spend. All we talked about in these threads is what will happen.

I know, but this doesn't help. Let me try to explain what I mean:

I send my TX to Node A.
Then I send TX' with a different output to B.
I do this so fast that both A and B think the TX they got is the first.

In "normal" Bitcoin this is settled by a race which transaction reached the miners first. Payment Providers deal with it by having several nodes and deciding after some seconds if a tx has reached mining nodes without being double-spend.

BUIP085 solves this by relaying both transactions, so that the merchant nodes sees: "This is a double spend"

With BUIP088 Node A relays TX and a Double-Spend-Proof of TX', while Node B relays TX' and a Double-Spend-Proof of TX. So, what to do with it?

 

[Tom Zander]

There really is nothing weird about your example, this is by far the most common usecase.

At any node when (their local) second transaction comes in, they create a byte-for-byte identical double-spend proof and propagate it (so the rest of the network knows it too).

The proof idea explicitly states that the order of incoming transactions doesn't matter for the proof.

The entire point of a proof is that it doesn't matter who created it, or which transaction they saw first. The proof is byte-for-byte identical and only states that two (or more) transactions, with their transaction-ids, are double-spends.

 

[torusJKL]

With BUIP088 Node A relays TX and a Double-Spend-Proof of TX', while Node B relays TX' and a Double-Spend-Proof of TX. So, what to do with it?

At this point it does not matter which tx triggered the proof or if there will be even more double spend attempts (e.g. a tx with a higher fee) between now and the time the tx is included in a block.

The vendor is alerted by the proof and should wait until the tx is mined before giving the product to the customer.

 

[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?

Wrong thread

 

[torusJKL]

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