Implement BIP 14 : separate protocol version from client version #707

1. 
   gavinandresen commented at 9:34 pm on December 16, 2011: contributor

   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.

2. 
   jgarzik commented at 4:07 am on December 17, 2011: contributor

   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.
3. Implement BIP 14 : separate protocol version from client version f8ded588a2
4. 
   gavinandresen commented at 3:25 pm on December 19, 2011: contributor

   CLIENT_NAME is now always “bitcoin-qt”
5. gavinandresen referenced this in commit 1f3bc1c239 on Dec 19, 2011
6. gavinandresen merged this on Dec 19, 2011
7. gavinandresen closed this on Dec 19, 2011

   ---

8. coblee referenced this in commit beeb732238 on Jul 17, 2012
9. destenson referenced this in commit 3736403985 on Jun 26, 2016
10. 
    rebroad commented at 2:08 am on August 27, 2016: contributor

    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?
11. 
    luke-jr commented at 2:35 am on August 27, 2016: member

    @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…
12. 
    rebroad commented at 2:45 am on August 27, 2016: contributor

    @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?
13. 
    luke-jr commented at 2:59 am on August 27, 2016: member

    1. This isn’t used for CB nor XThin.
    2. SegWit is a consensus layer upgrade, and is therefore not optional for full nodes.
    3. There is already (since 2011) a Bitcoin-wide standards process (Bitcoin Improvement Proposals; BIP) for changes to common infrastructure to be coordinated between different development teams.
    4. That said, this incrementing p2p protocol version number is probably growing increasingly useless, and it might make sense to redefine it as a pair of 16-bit version number (with the current usage) and make the remaining into additional service bits. (Someone wishing to work on this should start a discussion on the implementation-independent bitcoin-dev mailing list, and write a BIP.)
14. destenson referenced this in commit 2dec0a8c9a on Aug 8, 2017
15. kallewoof referenced this in commit 8161038c7b on Oct 4, 2019
16. rajarshimaitra referenced this in commit 33c028664a on Aug 5, 2021
17. DrahtBot locked this on Sep 8, 2021

Contributors
gavinandresen jgarzik rebroad luke-jr