<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div>I don&#39;t understand why you say my proposal would make the protocol more stateful<span style="line-height:16px;color:rgb(51,51,51);font-size:13px;font-family:arial,helvetica,clean,sans-serif">. I think it doesn&#39;t.</span></div>


<div>Each reply is only  the result of the current request only, and there is no new session information.</div></div></blockquote><div><br></div><div>I also wondered this. My first thought was that it&#39;s basically the same as the PING message, a nonce that is repeated immediately on reply. This makes it easier to multiplex operations over a single channel. I&#39;m not against this basic idea, and it is easy to ignore for clients that don&#39;t want to use it.</div>
<div><br></div><div>I think the state comes in here:</div><div><br></div><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>
</div><div><br></div><div>&quot;*command1* sends back the requestid given in *command2*&quot;.</div><div><br></div><div>This requires keeping state on the connection between command1 and command2. Arguably, this state already exists in the current protocol, but I&#39;d rather see it reduced than extended.</div>
<div><br></div><div>Also... Many of the described commands don&#39;t need this as they already have a natural &quot;nonce&quot;. For example, the id of the requested block header. If this is passed in the reply, and the caller can correlate the request and reply without a special nonce administration.</div>
<div><br></div><div>Wladimir</div><div><br></div></div>