Restrictive transaction versioning and how to reduce resulting workload on developers.

[LOLLOLOOLOL]

[A Master Protocol implementation] must treat addresses which broadcast messages using version numbers it does not recognize as "black holes". [...] This approach allows old versions of the Master Protocol to continue operating using the transactions they recognize without trying to parse messages of unknown meaning.

This creates a scenario in which any implementation that does not recognize version numbers may not properly consider certain addresses "black holes." It is possible for implementations to "hard fork" yet still be interoperable. This threat can be realized by the open nature of the project in implementations that lack due diligence, or are not properly overseen.

Maybe there's a way to keep a sort of "forward compatibility?" This could potentially be done by removing the requirement that revision numbers be recognized, and instead define "black hole" addresses by (whether intentionally or not) the requirement that a prior version cannot recognize a newer. In this manner, black hole addresses could be n revisions apart rather than the current requirement that they are 1 version apart. Or am I wrong to assume that an version increment is not necessarily a hard forkable event?

Looking for thoughts on this - what is the feasibility of having less strict update requirements for developers?

tl;dr: There are unnecessarily restrictive versioning definitions. Can cause scalability issues, and serious problems with negligent implementations. Looking to open discussion on how to reduce resulting workload for developers.

[LOLLOLOOLOL]

Quite a bit of discussion surrounding the topic of versioning. Found this particularly relevant regarding compatibility between versions. Note: "Forward compatible" and backward compatible are not necessarily the same.

re: "small update" that's a decent idea - make the version a major.minor thing like semantic software versioning. Minor shouldn't be backwards incompatible, but has changed. Similarly the OpenPGP spec, RFC 4880, has the concept of a 'critical bit' where if set and the client doesn't understand the packet, is meant to be interpreted as "whatever you didn't understand is important, so just quit now"

#111 (comment)

And this, concerning version enforcement.

Also note that each transaction already has a version number, and an address which sends a new/unrecognized version number should have all its balances invalidated. This is already in the spec, but we haven't done any enforcement that clients do this or any testing of it yet.

#111 (comment)

[ripper234]

Can you TL:DR what this issue is about, perhaps in a more comprehensive title / edit the first post?