search

bitpay / bitcoin

Bitcore Bitcoin build with address indexes
https://bitcore.io/bitcoin
MIT License
61 stars 40 forks source link

chore: set a distinct client version string #2

Closed m-schmoock closed 8 years ago

m-schmoock commented 8 years ago

In order to find out about consensus we should change the client version string properly. This way we can track usage of this branch i.e here: https://bitnodes.21.co/nodes

kleetus commented 8 years ago

Thanks for sending this merge request. I see your point, but I would ask the following to spur conversation:

The client name of the software really is "Satoshi". Almost of the code is Satoshi's, but with some patching. Admittedly, the whole concept of having a "version" protocol message is a bit quaint. At this point, the answer to a version message ought to be "whatever you want it to be man". All things being equal, just saying this is Satoshi's client is least likely to raise an eyebrow or otherwise cause a holy war. I am all for using "uacomment=bitcore" in the config or on the command line for the daemon. Do you have a different take on this issue considering the above?

martindale commented 8 years ago

The client version string should be considered meaningless, much like the User Agent string in HTTP headers. It can be (and very often is) quite misleading.

m-schmoock commented 8 years ago

Its correct, however, as there is no established voting support within the software, the community tends to interpret node usage a weak indicator for 'users vote' (see https://coin.dance/nodes or http://xtnodes.com )

kleetus commented 8 years ago

my latest thoughts on this subject are that:

https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

this would allow nodes to report its capabilities, separate from brands like classic/core/satoshi/unlimited/bitcore. Example, if the 5th MSB is set, this might mean that this node supports adaptive block size. If the 4th bit is set, then this node might also support a 2MB hard fork.

m-schmoock commented 8 years ago

Thats sounds great. I was thinking about the same issue when announcing/voting several BIPs like 109 and BitPay simultaneously. I guess you saw my additional merge request to the BIP...

Because it totally valid to vote several BIPs at once without knowing which will be activated first. There should be a configuration option for consensus voting/announcement.