Remember, I am attending my first Komodo hardfork, so excuse my naivete. Should the protocol requirement be implemented at installation, or at hardfork time? Taking a brief look at the code, changing the MIN_PEER_PROTO_VERSION would prevent this node from connecting to any peers unless they also upgraded. While that is required after hardfork time due to the protocol change, it seems IMO harsh at upgrade time.

I realize that moving it to after the hardfork height/time means already connected but upraded/non-upgraded nodes could start rejecting blocks, forking, etc. I am just foreseeing doing it at installation time would cause a mad rush for every node to upgrade because everyone has to do it at the same time.

Am I mistaken?

John is absolutely right. The minimum must be 170010.

John is absolutely right. The minimum must be 170010.

Why we need to allow nodes with 170010 proto and only S5 pubkeys exists in mainnet? What's the purpose of this? They anyway will not able to accept blocks produced by S6 notaries. So, they will be useless anyway.

Non-upgraded nodes (without S6 pubkeys) are useless for network, so, it would be reasonable to cut them off (reject at connection establishment stage) at the protocol level.

Why we need to allow nodes with 170010 proto and only S5 pubkeys exists in mainnet? What's the purpose of this? They anyway will not able to accept blocks produced by S6 notaries. So, they will be useless anyway.

Non-upgraded nodes (without S6 pubkeys) are useless for network, so, it would be reasonable to cut them off (reject at connection establishment stage) at the protocol level.

The problem is not the protocol version, but the timing.

It would be hard to have everyone upgrade at once. IMO we should enforce the new protocol version, but only after the HF height/time. This is a pain to code, but allows a "buffer" time for nodes to upgrade before being kicked off the network.

Think of it this way: You are the first to upgrade. Who will be your peers? No one.

Update: ZCash has a mechanism that we could append to. See NetworkUpgrade and NetworkUpgradeInfo structs.

Untested, but an example of how it could work (requires the s6 hardfork height in PR #540): DeckerSU/komodo@patch-s6-version...jmjatlanta:jmj_hf22

Q: how would this work for hardfork-date-based asset chains? Researching...

@jmjatlanta Ok ... let's imagine we don't enforce min. proto version upgrade. In other words we allow non-updated nodes exist in mainnet and connect to other nodes. What's the benefit of this? First block after nS6HardforkHeight will be notary mined block, second also ... and ~62 next expected too. Non-updated nodes will not accept these blocks and will stay on the lower height than real mainnet. Probably some non-updated pools will mine few blocks in oldnet ... but anyway, chain formed by notaries will be longest. But non-updated nodes will not accept that chain anyway (that's why it called "hardfork") ... What's the purpose to keep them online, waste connection sockets, CPU resources, etc. if they are totally useless?

Think of it this way: You are the first to upgrade. Who will be your peers? No one.

64 notaries at least, and other nodes which already will be exist in DNS seeders, bcz they will update before nS6HardforkHeight.

@jmjatlanta @Alrighttt 98f7b87 - added, indeed to make "transition period" (time from now till nS6HardforkHeight) more smooth, need to allow existing nodes to connect. What about internal transition mechanism, yes, i agreed with @jmjatlanta - it's preferable, but as it's untested, we will not use it this time.

p.s. My delusion was in i somehow assumed that nodes will start to upgrade only closer to HF date or after. Of course, with restriction to connect only with 170011 nodes which will upgrade now, will stay without peers and will not follow mainnet. So, thank you for comments and mention that case.

The reversion of MIN_PEER_PROTO_VERSION looks good. Thanks.

As for the change in CLIENT_VERSION: It makes me queasy, as this gets pushed and pulled in the majority of the I/O streams. But I see it was done recently, and apparently my queasiness is simply not knowing all the side effects yet. If others agree that it is harmless, I'll go along. Otherwise, I'll need some time to walk through it.

As a side note, Bitcoin de-duped the client version number stuff. See https://github.com/bitcoin/bitcoin/pull/10155/files
I am certainly not suggesting we do this now, but just a note for the future.

For activating the required min peer version at the hardfork moment I vote for the existing params.vUpgrades[] framework which already has the nProtocolVersion field and there is already code to disconnect not upgraded nodes. It suits only for the KMD chain though
For assets chains I have a similar framework (it is currently in the tokel repo) which takes into account chain name and allows time-activation