<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 &quot;checksum&quot; 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) &quot;inv&quot; reponse(s) to &quot;getblocks&quot; and sending the &quot;hashContinue&quot;.</div>

<div style>But if the other peer doesn&#39;t send a response to getblock, send a partial response to getblocks, mixes it with some unrelated blocks inventories or doesn&#39;t send the &quot;hashContinue&quot; 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&#39;t know how many &quot;inv&quot; messages to wait for after &quot;getblocks&quot; and 2/ we don&#39;t know how to distinguish between result of &quot;getblocks&quot; and spontaneous &quot;inv&quot; notifications.</div>

<div style>The same is true for  &quot;addr&quot; messages (it is both a notification and reply) but this is less of a problem as a lack of response to getaddr doesn&#39;t constitute a DoS.</div><div style><br></div><div style>

The idea would be to add a new &quot;requestid&quot; 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&quot;inv&quot; reply (0-500 elements allowed). </div><div style>       - getdata still result in multiple &#39;tx&#39; or &#39;block&#39; &#39;s (as currently).</div>

<div style><br></div><div style>This is inspired by the common request/reply pattern (the id is sometimes called &quot;correlation id&quot;). </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 &quot;CRequestTracker, hashReply &amp; PushRequest&quot; 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 &quot;hashContinue&quot; 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&#39;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>