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 andypark...@gmail.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
