Implement BIP 14 : separate protocol version from client version#707
Implement BIP 14 : separate protocol version from client version#707gavinandresen merged 1 commit intobitcoin:masterfrom
Conversation
|
IMO, CLIENT_NAME should not vary if/if-not GUI. It's the same network logic. If a problem arises where other network peers must test for a problematic bug, they have twice as many CLIENT_NAMEs to check for one bug. Might be a privacy issue too? Gives attackers obvious server-or-client decision point. |
|
CLIENT_NAME is now always "bitcoin-qt" |
Implement BIP 14 : separate protocol version from client version
Implement BIP 14 : separate protocol version from client version
|
NACK :) It's a great idea when there is only one development team for bitcoin, but in the future I expect to see multiple development teams as part of bitcoin's decentralization, and then there will need to be a more non-linear to nodes communicating their capabilities. Does BIP 9 not already provide the functionality this is hoping to achieve? |
|
@rebroad Uh, what are you talking about/doing? This is a change that was made and merged in 2011, and does the opposite of what you seem to be thinking it does... |
|
@luke-jr Yes, I realise this is a very old one hence the smiley, but it seems that with various other bitcoin nodes out there, for example, Unlimited are using Protocol Version >80000, which means that Core will assume it provides services such as compact blocks, SegWit, etc when it does not. I am thinking that the PROTOCOL_VERSION ought not to be relied upon as developers are moving away from it for reasons that need to be better understood. I suspect those reasons are that it doesn't suit multiple development teams as it enforces a level of linearity (i.e. all developers are expected to provide functionality before they can bump their version number) but not on a "level playing field". I.e. some developers might not want to add SegWit, but might want to add XThin - what should the protocol version be in that scenario? |
|
Add clientversion.h to guiutil.cpp
…end amount message 9add5a8 Fix feature_pak.py in light of bitcoin#706 (Gregory Sanders) 817ebcd sendtomainchain_pak: Fix minimum send amount message (Gregory Sanders) Pull request description: backport of bitcoin#706 Tree-SHA512: a1f16636210eb28c221a442c113a609da906079b3688dc1dc53e33d0409096638a48036032ba7349257a4d599342272df40dd9335bbc9ac1008c439602a94f8a
Fixing some typos
4 participants
This replaces VERSION with PROTOCOL_VERSION (defined in serialize.h) and CLIENT_VERSION (defined in main.h).
I also define CLIENT_NAME as either "bitcoind" or "bitcoin-qt" in main.h.
The getinfo() RPC command returns CLIENT_VERSION as "version" (same as before) and PROTOCOL_VERSION as "protocolversion" (new).
CLIENT_VERSION is recorded in the wallet.dat as "version".
And PROTOCOL_VERSION is used for all the network serialization stuff.
There is a TODO here related to the CAlert feature, but doing it will require more thought/work. And I've got another change to CAlert (give testnet its own alert keypair) that'll be a good time to change it.
I decided against new command-line arguments / bitcoin.conf options to make it really easy to override the CLIENT_NAME or CLIENT_VERSION reported to peers; those would be easy-to-add-later features.