What changes would call for a protocol version update?

[david2278]

We are working on a fork of Dogecoin. We initially activated AuxPow at block 100,000, but have since decided to do a hard fork and activate it around block 40,000.

My question is, would incrementing the protocol version be appropriate for this small change? It is essentially a single integer in the chainparams.ccp file, but it will result in a hardfork.

More generally, what types of changes call for protocol version updates?

Thanks

[patricklodder]

Which exact property are you asking this about? (p2p) protocol versions are maintained in version.h but do not cause forks per se.

[david2278]

I'm referring to PROTOCOL_VERSION in version.h. I'm wondering, in what circumstances it's appropriate to increment this version number.

In our fork, in chainparams.ccp we had set auxpowConsensus.nHeightEffective to 100000. We have since decided to activate it earlier and will be setting this to 40000 instead. This change in chainparams.ccp will cause a hardfork and I'm wondering if this is a circumstance which calls for incrementing the PROTOCOL_VERSION in version.h.

To generalize my question, I'm wondering what circumstances it would be appropriate to increment the PROTOCOL_VERSION in version.h. What factors do you consider when deciding to increment it?

I suppose a good follow-up question would be what do you increment it by? The last few commits it was incremented by 1, but at one point it looks like it was changed from 70002 to 70011.

[patricklodder]

It's smart to update protocol version. Upping PROTOCOL_VERSION does not cause a hard fork. What does have influence is to update MIN_PEER_PROTO_VERSION, which is something you may want to do in a release AFTER you've activated your fork.

Since now you have 2 clients, with different activation heights, you'll want to mark the earlier one with a higher version (and document what the version is for) and then, make that MIN_PEER_PROTO_VERSION after a successful hard fork.

In general, whenever the p2p protocol changes, you update it. For Dogecoin it was updated a couple of versions in a row because we ported a bunch from Bitcoin in at once for the 1.14.0 release.

[chromatic]

For my own understanding (@david2278 asked me and I suggested asking in public for the learning opportunity), should we consider changing nHeightEffective a p2p protocol change? I think that makes sense, but I'm trying to make something fuzzy in my head into something more concrete.

[patricklodder]

imho, yes. If you do this you can uniquely identify p2p clients that have a specific behavior (will not accept blocks of [version] after [height]) and this will help you, post-fork, to:

1. If the fork is successful, reduce the amount of blocks you get from clients that are not following the fork, by disconnecting all peers with a lower version (these can never be on your chaintip), or
2. If the fork is unsuccessful, identify and temporarily filter out those with the version number used. For this case, it may be cleaner to set a specific higher bit in the protocol version, because that protects from not being able to increase the version number, wanting to increase the sequence.

Basically, doing this now can help you in a subsequent release after the fork activated. It's a tool for the future - no matter what the outcome of the fork is.