Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2012-06-16 📝 Original message:On Sat, Jun 16, 2012 at ...
📅 Original date posted:2012-06-16
📝 Original message:On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <andyparkins at gmail.com>wrote:
>
> It's less of a problem in a (nearly) stateless protocol like Bitcoin.
>
It'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.
I like the idea of a capabilities command; as time goes on and the ecosystem
> of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
> blockchain/memory-pool-query clients becomes more varied, it's going to be
> more an more important. The particular example that occurs is thin clients
> connecting to the network are going to want to ensure they are connected to
> at least one non-thin client.
>
Which is a perfectly reasonable requirement. However, one could simply
standardize what a 'thin client' and what a 'thick client' does and offers
(at a certain version level), without having to explicitly enumerate
everything over the protocol.
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.
Letting the node know of each others capabilities at connection time helps
somewhat. It'd allow refusing clients that do not implement a certain
feature. Then again, to me it's unclear what this wins compared to
incremental protocol versions with clear requirements.
I'm just afraid that the currently simple P2P protocol will turn into a zoo
of complicated (and potentially buggy/insecure) interactions.
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 "getdata" at
protocol version 10 mean the same as offering it at protocol version 11"?
Probably not guaranteed. The arguments might have changed. So it's not
entirely self-documenting either.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120616/2a6e50dc/attachment.html>;
📝 Original message:On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <andyparkins at gmail.com>wrote:
>
> It's less of a problem in a (nearly) stateless protocol like Bitcoin.
>
It'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.
I like the idea of a capabilities command; as time goes on and the ecosystem
> of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
> blockchain/memory-pool-query clients becomes more varied, it's going to be
> more an more important. The particular example that occurs is thin clients
> connecting to the network are going to want to ensure they are connected to
> at least one non-thin client.
>
Which is a perfectly reasonable requirement. However, one could simply
standardize what a 'thin client' and what a 'thick client' does and offers
(at a certain version level), without having to explicitly enumerate
everything over the protocol.
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.
Letting the node know of each others capabilities at connection time helps
somewhat. It'd allow refusing clients that do not implement a certain
feature. Then again, to me it's unclear what this wins compared to
incremental protocol versions with clear requirements.
I'm just afraid that the currently simple P2P protocol will turn into a zoo
of complicated (and potentially buggy/insecure) interactions.
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 "getdata" at
protocol version 10 mean the same as offering it at protocol version 11"?
Probably not guaranteed. The arguments might have changed. So it's not
entirely self-documenting either.
Wladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120616/2a6e50dc/attachment.html>;