On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <span dir="ltr">&lt;<a href="mailto:andyparkins@gmail.com" target="_blank">andyparkins@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
</div>It&#39;s less of a problem in a (nearly) stateless protocol like Bitcoin.<br></blockquote><div><br></div><div>It&#39;s currently (nearly) stateless, however it would be short-sighted to think it will stay that way. State is being introduced as we speak; for example, connection-specific filters.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the idea of a capabilities command; as time goes on and the ecosystem<br>
of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-<br>
blockchain/memory-pool-query clients becomes more varied, it&#39;s going to be<br>
more an more important.  The particular example that occurs is thin clients<br>
connecting to the network are going to want to ensure they are connected to<br>
at least one non-thin client.<br></blockquote><div><br></div><div>Which is a perfectly reasonable requirement. However, one could simply standardize what a &#39;thin client&#39; and what a &#39;thick client&#39; does and offers (at a certain version level), without having to explicitly enumerate everything over the protocol. </div>

<div><br></div><div>This also makes it easier to deprecate (lack of) certain features later on. You can simply drop support for protocol versions before a certain number (which has happened before). With the extension system this is much harder, which likely means you keep certain workarounds forever. </div>

<div><br></div><div>Letting the node know of each others capabilities at connection time helps somewhat. It&#39;d allow refusing clients that do not implement a certain feature. Then again, to me it&#39;s unclear what this wins compared to incremental protocol versions with clear requirements. </div>

<div><br></div><div>I&#39;m just afraid that the currently simple P2P protocol will turn into a zoo of complicated (and potentially buggy/insecure) interactions. </div><div><br></div><div>So maybe a capability system is a good idea but then the granularity should be large, not command-level. The interaction between protocol versions and capabilities needs to be defined as well. Does offering &quot;getdata&quot; at protocol version 10 mean the same as offering it at protocol version 11&quot;? Probably not guaranteed. The arguments might have changed. So it&#39;s not entirely self-documenting either.</div>

<div><br></div><div>Wladimir</div><div><br></div></div>