Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <20161116210100.GC5639@savin.petertodd.org>
Date: Wed, 16 Nov 2016 14:21:53 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DD0AEAC-ACC9-4F09-B922-8235D528BBC5@voskuil.org>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
	<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
	<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
	<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
	<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
	<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
	<CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
	<CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
	<20161116210100.GC5639@savin.petertodd.org>
To: Peter Todd <pete@petertodd.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Precedence: list

I would suggest that, before discussing how best to fork the chain to meet t=
his objective, we consider the objective.

The implementers have acknowledged that this does not represent a performanc=
e improvement. Especially given that this was apparently not initially under=
stood, that alone is good reason for them to reconsider.

The remaining stated objective is reduction of code complexity. Let us be ve=
ry clear, a proposal to change the protocol must be considered independently=
 of any particular implementation of the protocol. While the implementation o=
f BIP34 style activation may be hugely complex in the satoshi code, it is de=
finitely not complex as a matter of necessity.

Activation constitutes maybe a dozen lines of additional code in libbitcoin.=
 The need to hit the chain (or cache) to obtain historical header info will r=
emain for proof of work, so this change doesn't even accomplish some sort of=
 beneficial isolation from blockchain history.

So, at best, we are talking about various ways to introduce a consensus fork=
 so that a well designed implementation  can remove a tiny amount of already=
-written code and associated tests. In my opinion this is embarrassingly poo=
r reasoning. It would be much more productive to reduce satoshi code complex=
ity in ways that do not impact the protocol. There are a *huge* number of su=
ch opportunities, and in fact activation is one of them. Once that is done, w=
e can talk about forking to reduce source code complexity.

These fork suggestions actually increase *necessary* complexity for any impl=
antation that takes a rational approach to forks. By rational I mean *additi=
ve*. Deleting rules from Bitcoin code is simply bad design. Rules are never r=
emoved, they are added. A new rule to modify an old rule is simply a new rul=
e. This is new and additional code. So please don't assume in this "proposal=
" that this makes development simpler for other implementations, that is not=
 a necessary conclusion.

e

> On Nov 16, 2016, at 1:01 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>=20
>> On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wro=
te:
>> I think we are misunderstanding the effect of this change.
>> It's still "OK" for a 50k re-org to happen.
>> We're just saying that if it does, we will now have potentially introduce=
d
>> a hard fork between new client and old clients if the reorg contains
>> earlier signaling for the most recent ISM soft fork and then blocks which=

>> do not conform to that soft fork before the block height encoded activati=
on.
>>=20
>> I think the argument is this doesn't substantially add to the confusion o=
r
>> usability of the system as its likely that old software won't even handle=

>> 50k block reorgs cleanly anyway and there will clearly have to be human
>> coordination at the time of the event.  In the unlikely event that the ne=
w
>> chain does cause such a hard fork, that coordination can result in everyo=
ne
>> upgrading to software that supports the new rules anyway.
>>=20
>> So no, I don't think we should add a checkpoint.  I think we should all
>> just agree to a hard fork that only has a very very slim chance of any
>> practical effect.
>=20
> So, conceptually, another way to deal with this is to hardcode a blockhash=

> where we allow blocks in a chain ending with that blockhash to _not_ follo=
w
> BIP65, up until that blockhash, and any blockchain without that blockhash m=
ust
> respect BIP65 for all blocks in the chain.
>=20
> This is a softfork: we've only added rules that made otherwise valid chain=
s
> invalid, and at the same time we are still accepting large reorgs (albeit u=
nder
> stricter rules than before).
>=20
> I'd suggest we call this a exemption hash - we've exempted a particular
> blockchains from a soft-forked rule that we would otherwise enforce.
>=20
> --=20
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev