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