Re: [bitcoin-dev] Compatibility requirements for hard or soft forks

[Justus Ranvier <justus@openbitcoinprivacyproject.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1539 bytes --]

On 11/01/2015 07:30 PM, Tier Nolan via bitcoin-dev wrote:
> If at least one year's notice was given, then people aren't going to
> lose their money, since they have notice.

So after realizing that I misread substantial portions of this thread
due to a lack of attention to detail I'd like to point out this:

Bitcoin nodes have the capability to validate blocks going back to the
genesis block, including blocks which would not be valid if mined today
under current rules.

Therefore it must be the case that all the old consensus rules are
preserved somewhere in the current code bases of the various
implementations.

Given that, there shouldn't be any technical barrier to validating input
scripts according to the consensus rules that were in effect at the time
the input being spent was added to the blockchain.

Maybe dealing with output is more difficult.

Had every consensus rule change (deliberate and accidental) been
accompanied by a version number bump, it would have been possible to
phase out old versions without invaliding signed-but-unbroadcast
transactions by saying "as of block height x, transactions with version
y or lower are invalid unless their inputs are exclusively sourced from
blocks with heights < x"

If there already have been rule changes which have retroactively
invalided unbroadcast transactions which were valid at the time they
were signed, those rules could be relaxed to not apply to transactions
which exclusively spend inputs that existed before the rule change.

[-- Attachment #1.2: 0xEAD9E623.asc --]
[-- Type: application/pgp-keys, Size: 23699 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]