Double Spend Proof: roadmap

Technical
#1

The number of clients on the P2P network that create and send out Double Spend Proof messages is growing. We have various full nodes actively working on it!

This first milestone took a long time, the development was halted various times which caused slowdowns, none of which stopped progress and I’m very happy with the current state.

That does not mean that now we are done. Just having the message is a fantastic first step, but people should actually use the message. It is like having an alarm on your house without a siren or light. Invisible.

So this is the time for me to present the evidence and the benefit, people can see this on mainnet today (connect to the P2P net on flowee.org) and I hope to convince many people of the benefit and that we shortly follow up with acceptance by the wider community as it needs a lot more people to take the task of double spend proofs on their shoulders. I will assist where I can, starting with this document which I hope will give people a good idea of where we are and where we want to go to.

Done

Send on pure P2P (for merkleblock based SPV and full nodes)
lowee the Hub currently provides push-APIs for point-of-sale systems and BIP70 servers to include DS-notification, other nodes may want to do something similar. (link)

Make it available to the wider audience.

Add some RPC on full nodes to forward the notification and to indicate a tx in mempool having a DSProof attached to it.

Services like Fulcrum (electronx) need to forward them too for wallets that use these servers.

Online API providers (rest services) need to also allow a client to learn that a transaction is risky because a double spend proof has been seen for it.

Block explorers which show transactions from the mempool should do the same.

Make wallets and point-of-sale software use the proof.

Receiving money in practically all wallets currently completely ignores risk . Money was seen or not, nothing else, all unconfirmed transactions are the same.
This software should really start thinking in risk gradation. A DSProof (massively) increases the risk. Other risky properties like chain-depth, low fee, non-standardness etc. will be useful too.

An important reminder(1): chain-depth ; the state when a transaction pays using another unconfirmed transaction. Use this for risk analysis!
When a transaction uses unconfirmed parents the risk is recursive. When a parent of a parent gets a DSProof, this is equally bad for that child transactions risk-assessment.

Use all we learned and iterate the dsproof message.

DSProof is a great concept, and works well, but I know that it will be possible to improve with the many people in our ecosystem starting to use this and coming up with suggestions.

Finalize the design, rename the message to be just ‘dsproof’

Yes, this is the last step.

Please use this thread if you have questions or status updates so we can keep track here.

4 Likes
#2

A positive step forward, thank you.

#3

To keep people updated here are some more resources:

You can find a text and video introducing the ideas and concepts online at: Making regular payments more secure with dsproof.

In 2018 we had a workshop which investigated the issues with a great lineup of speakers and many productive debates:

The current location of the specification is here: Double Spend Proof – Spec.

The current state of the network is this:

  • Flowee the Hub has created these messages for almost a year on mainnet, to prove that it works.
  • BU-Cash from version 1.9 also creates and announces these messages on mainnet.
  • BCHD and BCHN are both finalizing their merge requests to add support. Both stated they will include DSProof creation in a release soon.
1 Like
#4

A merchant that gets notified that a double-spend attack has been made on an actual withdrawal has to realize that there is an actual attempt to steal from him. This is the reality. And the question is how do you recover from this? Do you call the police? Sounds like a sane thing to do. At minimum you make clear that you never want to do business with the person again.

I mean, if you see someone pick your pockets, do you just walk away being happy you caught it and he failed? Or do you want to make clear to yourself and society that this is wrong and attempts to steal should not be just dismissed?

With this thought lets take a look at a flowchart of actual usage:

6917829cc07cf1b56e98016e54967422
6917829cc07cf1b56e98016e54967422452×807 29.9 KB

So, imagine you have a guy that tries to buy something. Your wallet states you just got a double-spend proof. Which includes cryptographic proof that the guy tried to steal from you. Do you continue with the transaction and try to complete it, or not?

Because if you don’t want to continue that transaction, then you don’t need preconsensus because you never actually hit that part of the flow-chart.

What this means is this: DSProof solves the usecase that preconsensus (like avalanche) means to solve, but the DSProof solution is much simpler and easier to roll out.

1 Like
#5

Update: BCHN has merged network message support

2 Likes
#6

Thank you freetrader, that makes me profoundly happy!

1 Like
#7

Wallet updates!

In the lastest release of BU full node there is in the built-in wallet support for displaying double spent proofs. source.

For the Flowee Pay wallet the UX has been designed and is shown in a nice video here:

3 Likes
Lets talk about block time
#8

Since BCHN v23.0.0 (15 April 2021) , BCHN provides RPC and ZMQ interfaces to obtain DSProof information.

Our next release with provide another call which can be used to obtain a more detailed ‘score’ for a transaction in the mempool, which can indicate whether the transaction has an associated DSProof, or whether it has ancestry that puts it at risk of being doublespent with a proof, or whether it has no proof and is therefore low risk.

I think perhaps you can update the roadmap on this point.