Skip to content

Instantly share code, notes, and snippets.

@imaginaryusername

imaginaryusername/sp-relay1.md

Created July 23, 2018 06:22
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save imaginaryusername/87af893d260afd7c60606b33403063cd to your computer and use it in GitHub Desktop.
Save imaginaryusername/87af893d260afd7c60606b33403063cd to your computer and use it in GitHub Desktop.
Download ZIP
Possible double-spend proof relay mechanism - from Tom Zander
Raw
sp-relay1.md

A transaction may already have been propagated through all the network, or it may not yet be when a proof gets made. So a node that has both proof and (one of the) transaction in mempool can get asked by a peer to relay one or the other. When it gets asked to relay the transaction, it responds to relay both the transaction and the proof. If it gets asked the proof, it just gives the proof.

Now, this may cause bad use of bandwith as the proof may now be sent to a node twice. A simple solution might be to have a small message which essentially says "for the transaction you just requested, there is a double-spend proof with ID 'x'"

As such we introduce 3 parts to the network p2p layer of Bitcoin Cash.

  • an INV message-type (the next available ID) where we list the hash of the proof
  • A pre-proof message with a 64-bit txid (shortened as the pre-proof always comes shortly after the full tx) and the hash of the proof.
  • When a node asks for a respend-proof with GETDATA, the node responds with a "RESPENDPROOF" reply which contains the full proof.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment