📅 Original date posted:2012-06-16
📝 Original message:On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:
> As replied on the github issue:
>
> Personally I still think it's better to have a clear standardized
> "protocol version", that implies what capabilities are supported,
> instead of a capability-based system that explicitly lists them.
>
> Capability-based systems (just look at OpenGL) tend to become
> horrendously complex, as you have to take into account all possible
> combinations of possible interactions, and constantly check for support
> of specific features instead of just comparing a version number.
>
> Sure, it can be necessary to distinguish between different types of
> nodes, but there is no need to make it this fine-grained.
It's less of a problem in a (nearly) stateless protocol like Bitcoin.
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.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 10:15:35
in reply to nevent1q…yse8
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 10:15:35Event JSON
{
"id": "ac4d5169abe98a1ee9df92dd3f9f3822d37b9d281087746b8e1029de6ce219b2",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686132935,
"kind": 1,
"tags": [
[
"e",
"76f83e7269d7cdc3a12f52c2cf18660afe267f079ced72d533a304a164bd5ac9",
"",
"root"
],
[
"e",
"54c69d071b12429d2bf1d7ba5c220e4f2ce254a7ab29f8627d6053e271b79f8f",
"",
"reply"
],
[
"p",
"30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722"
]
],
"content": "📅 Original date posted:2012-06-16\n📝 Original message:On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:\n\u003e As replied on the github issue:\n\u003e \n\u003e Personally I still think it's better to have a clear standardized\n\u003e \"protocol version\", that implies what capabilities are supported,\n\u003e instead of a capability-based system that explicitly lists them.\n\u003e \n\u003e Capability-based systems (just look at OpenGL) tend to become\n\u003e horrendously complex, as you have to take into account all possible\n\u003e combinations of possible interactions, and constantly check for support\n\u003e of specific features instead of just comparing a version number.\n\u003e \n\u003e Sure, it can be necessary to distinguish between different types of\n\u003e nodes, but there is no need to make it this fine-grained.\n\nIt's less of a problem in a (nearly) stateless protocol like Bitcoin.\n\nI like the idea of a capabilities command; as time goes on and the ecosystem \nof thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-\nblockchain/memory-pool-query clients becomes more varied, it's going to be \nmore an more important. The particular example that occurs is thin clients \nconnecting to the network are going to want to ensure they are connected to \nat least one non-thin client.\n\n\n\nAndy\n\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "8b4e63efe011596157c9ec1bfa317a4379378350a6519d6a352461434be3fe2d9a78fb0996e3adf7efbe905a9650ba7af97098008770904da75936a048409fe6"
}