From: Tom Zander <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Wed, 16 Nov 2016 15:38:21 +0100
Message-ID: <1797370.j3ssDbnHdc@strawberry>
In-Reply-To: <CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Precedence: list

Here is my thinking.

The BIP process is about changes to a living project which is the bitcoin=20
prptocol.
This specific BIP got accepted and we know in the blockchain that
this event (the acceptance) is recorded.
Before a certain block the rules were one way, after they were changed.

I have no problem with changing the *code* to be less complex because it=20
already knows the past. A checkpoint is the same, it is the registeration o=
f=20
a past event.
This makes software less complex and still capable of checking the entire=20
blockchain from genesis.

I don=E2=80=99t see any harm in this change. I see prudent software enginee=
ring=20
practices.


On Monday, 14 November 2016 10:47:35 CET Eric Voskuil via bitcoin-dev wrote:
> NACK
>=20
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material
> performance optimization (the checks are avoidable once activated until a
> sufficiently deep reorg deactivates them).


=2D-=20
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel