login

```
BUIP 135: Use OKCoin Donation to fund DoubleSpend Proofs
Proposer: Andrew Stone (theZerg)
Submitted on: 2019-10-14
Status: draft
```

Recently Bitcoin Unlimited received approximately 9000USD from OKcoin to

encourage BCH technological development. We want to put this generous

funding to work straight away to benefit BCH and all its

implementations. Voting YES for this BUIP will devote this money towards

producing an implementation of DS (doublespend) proofs that:

- Is enabled on Bitcoin Unlimited
- Is MIT licensed and therefore available for adoption by any other

full node implementation

In alignment with the BU goal to recognize and foster independent

development, we propose to first offer this money to and work with the

Flowee project. Flowee has implemented a GPLv3 licensed implementation

of doublespend proofs, and may be willing to extract this portion of the

Flowee code, offer it with an MIT license, and make some small proposed

modifications (see technical details below).

If an agreement with Flowee cannot be reached, the Developer will

evaluate proposals from any other applicants to find an alternative

solution to providing this functionality.

There are currently two specifications on double spend proofs and one

implementation within the larger BCH ecosystem.

Imaginary Username:

https://github.com/imaginaryusername/specs_n_stuff/blob/master/dsproof/dsproof.md

Flowee The Hub: https://gitlab.com/snippets/1883331

One key difference in the specifications is in how the DS proofs are

announced. Flowee specifies the DS proof identifier to be the double

SHA256 of the entire doublespend proof. Imaginary Username specifies the

DS proof identifier to be the SHA256 of the actual double spent

outpoint.

Flowee’s DS proof identifier is a probabilistically unique identifier,

similar to block and transaction identifiers. Imaginary Username’s

identifier has an additional property, which is that different DS proofs

that prove the same thing have the same hash. This is a very useful

property for DS proofs to have, since nodes are only interested in what

they prove, not the specifics of how (apart from verification).

Imaginary Username’s formulation allows nodes to ignore DS proof

messages based on the “INV” content, without actually downloading the

proof.

However, we can do slightly better. The purpose of the hashing both

specs propose is to create a probabilistically unique and short

identifier. However, the data being hashed – the outpoint – consists

of the double SHA256 hash of the prior input transaction and a 32bit

index. This data is already probabilistically unique, so there’s no need

to hash it again. Instead, let’s use the outpoint itself as the DS proof

identifier. This allows more efficient handling of DS proof and DS proof

INV messages (no hashing).

But probably most importantly, it allows recipients to easily determine

whether the DS proof is relevant to any transactions that the recipient

is interested in, when the INV is received. The recipient simply

compares the announced data to the inputs of all its transactions

looking for a match. If there is no match, a wallet does not need to

request the full DS proof.

Both specifications place DS proof announcements into INV messages along

with any other object announcements. However, this means that the DS

proof will be queued with the same priority as other transactions –

potentially waiting for the processing of the very transactions it’s

trying to warn against.

Instead DS proof announcement handling should happen at higher priority

than transaction announcements. While it would be possible to scan INV

messages for DS proof announcements and extract them, this is

inefficient and inconvenient.

A better solution is to place DS proof announcements in a separate

message. These messages can then be isolated to a high priority handling

queue immediately upon receipt, analogous to block and block headers

message handling today.

Making a new message type is not hard. And the DS specification already

requires new messages to handle transmission of DS proofs, so including

another message type is a difference of degree, not kind.