From: Justus Ranvier <justus@openbitcoinprivacyproject•org>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Compatibility requirements for hard or soft forks
Date: Mon, 2 Nov 2015 00:12:16 -0600 [thread overview]
Message-ID: <5636FEC0.2010802@openbitcoinprivacyproject.org> (raw)
In-Reply-To: <CAE-z3OVDT-0cYq4Hh_OozWEp-UEj6yxbyon6YhOretgKPRLfFg@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2015-11-02 6:12 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-28 14:06 Gavin Andresen
2015-10-31 3:43 ` Rusty Russell
2015-11-01 14:36 ` Justus Ranvier
2015-11-01 17:28 ` jl2012
2015-11-01 23:46 ` Tier Nolan
2015-11-02 0:23 ` Justus Ranvier
2015-11-02 0:33 ` Luke Dashjr
2015-11-02 1:30 ` Tier Nolan
2015-11-02 4:15 ` Justus Ranvier
2015-11-02 6:12 ` Justus Ranvier [this message]
2015-11-02 20:33 ` Gavin Andresen
2015-11-02 22:12 ` Justus Ranvier
2015-11-03 5:32 ` jl2012
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5636FEC0.2010802@openbitcoinprivacyproject.org \
--to=justus@openbitcoinprivacyproject$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox