If running on the testnet, this disconnects and bans any peers that are running PROTOCOL_VERSION 60000 or earlier. This cuts way down on the number of peers that try to send you a testnet1 or 2 block chain.
If PROCOTOL_VERSION is bumped before the 0.7 release, TESTNET3_VERSION should be increased to match.
Hm. Doesn't this break tools just as much as changing the magic would?
Depends on the tool; tools that read blk*.dat will not break with this change, but do break changing the magic bytes.
Network-speaking tools will have to be up-to-date with PROTOCOL_VERSION.
PS: I don't want to spend a whole lot of time on this, because out-of-version testnet nodes is a problem that should eventually solve itself (people will eventually upgrade).
Frankly, I like changing the protocol magic more than adding a minimum-version.
Changing the protocol magic (a) guarantees only compatible test clients communicate, while (b) leaving open the possibility that testnet3 may appear in a private backport or luke-jr's public backports.
Setting a minimum protocol version is easy, but the issue we are trying to solve is -wholly unrelated to protocol versioning-. A version-3 client with the latest genesis block should be able to talk testnet3, for example.
okey dokey.
So.... we all have testnet3-with-existing-magic-bytes blk*.dat's on our hard disks. What's the migration plan if we change the magic bytes?
changing magic bytes it is.