Versioning sounds like version numbering to me, but anyway, if you were to go back and improve the ability of Bitcoin to be more backwards compatible with then future changes, then yeah, that sure would make it more flexible. Good choice!
I realize there are already version numbers. However, as things stand older clients will just reject anything with a new version number, which results in splitting the block list. There is no protocol in place to allow new clients and old clients to coexist (which would be rather impressive--the changeable parts would have to be moved to some Turing-complete language that could be downloaded at runtime) or, perhaps more practically, to allow older clients to detect when a new change is being introduced and insist on an upgrade rather than proceeding under the old rules.
What I had in mind was something like this:
- The client is distributed with the developers' public keys.
- When a breaking release is introduced, the developers first add a special transaction to the block list warning about the upgrade.
- The client validates the signature of this warning and, if valid, passes it on to the user.
- The new client is released with support for both the old rules and the new ones. (This is already necessary, as the old blocks must be validated.)
- The client's highest supported protocol version goes into each transaction.
- After a fixed number of block are produced after the warning with no client protocol versions less than the announced version, the upgrade is committed and the new rules take effect. (Blocks with older protocols are accepted, but do not count toward the goal.)
- At this point new transactions with obsolete protocol versions will be rejected, and older clients will cease to operate rather than attempting to start their own independent block chain. Obviously this can be worked around by modifying the code, but there is little benefit in doing so. Anyone who wants to continue using Bitcoin will be driven to upgrade instead.
This way, rather than starting and abandoning a bunch of mini-block-chains as different users upgrade at different times, there would be a window during which upgrades could take place while maintaining compatibility, after which all the upgraded clients would switch to the new rules at the same time. The critical changes are (a) the upgrade notice transaction and associated key distribution & validation; (b) a protocol version field in the transaction structure (already present?); and (c) kill-switch code in the current client to detect a committed upgrade based on the upgrade notice and subsequent blocks.