<span style>Hi,</span><div style><br></div><div style>I would like to discuss the following bitcoin protocol improvement proposal:</div><div style><br></div><div style> Adding request/reply id in all messages (in the message header, based on what was done for the "checksum" field)</div>
<div style><br></div><div style>The original reason is that I found it very hard to implement robust blockchain downloading as we are missing context information:</div><div style>The download protocol relies on the other peer sending one (or more) "inv" reponse(s) to "getblocks" and sending the "hashContinue".</div>
<div style>But if the other peer doesn't send a response to getblock, send a partial response to getblocks, mixes it with some unrelated blocks inventories or doesn't send the "hashContinue" it is very hard to detect and handle (e.g. ban the peer and switch to another). This could cause some DoS attacks by misbehaving peers.</div>
<div style>The problems are that 1/ we don't know how many "inv" messages to wait for after "getblocks" and 2/ we don't know how to distinguish between result of "getblocks" and spontaneous "inv" notifications.</div>
<div style>The same is true for "addr" messages (it is both a notification and reply) but this is less of a problem as a lack of response to getaddr doesn't constitute a DoS.</div><div style><br></div><div style>
The idea would be to add a new "requestid" field in messages and define the following:</div><div style> - verack sends back the requestid given in version.</div><div style> - inv sends back the requestid given in getblocks or a special value in case of a notification.</div>
<div style> - addr sends back the requestid given in getaddr or a special value in case of a notification.</div><span style> - tx sends back the requestid given in getdata. </span><br style><div style> - block sends back the requestid given in getdata</div>
<div style> - headers sends back the requestid given in getheaders.</div><div style> - reply sends back the requestid given in checkorder/submitorder.</div><div style> - pong sends back the requestid given in ping.</div>
<div style><br></div><div style>With the following rules:</div><div style> - getblocks always results in a single"inv" reply (0-500 elements allowed). </div><div style> - getdata still result in multiple 'tx' or 'block' 's (as currently).</div>
<div style><br></div><div style>This is inspired by the common request/reply pattern (the id is sometimes called "correlation id"). </div><div style>This would permit better asynchronous messaging (multiple request of the same type in parallel. This could be useful for getblocks/getdata/getheaders and future messages).</div>
<div style><br></div><div style>Historic note: It seems similar to the existing mechanism of "CRequestTracker, hashReply & PushRequest" in the current bitcoin source code except requestId would only be a 32bits instead of the 256bits of hashReply .</div>
<div style><br></div><div style>I have implemented a prototype here: <a href="https://github.com/sirk390/bitcoin/" target="_blank" style="color:rgb(17,85,204)">https://github.com/sirk390/bitcoin/</a></div><div style>This could allow to remove "hashContinue" in a second step like this: <a href="https://github.com/sirk390/bitcoin/tree/better_block_download" target="_blank" style="color:rgb(17,85,204)">https://github.com/sirk390/bitcoin/tree/better_block_download</a></div>
<div style><br></div><div style>I'm discussing it now as I read the PONG BIP and saw some similar nonce field added.</div><div style>I was not sure if this nonce field would still be required if we had request/reply ids . </div>
<div style><br></div><div style>What do you think?</div><div style><br></div><div style>Best Regards,</div><div style>Christian Bodt, France</div><div style><div>Note: I am working on a python implementation of bitcoin.</div>
See <a href="https://github.com/sirk390/coinpy" target="_blank" style="color:rgb(17,85,204)">https://github.com/sirk390/coinpy</a></div>