From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E6BC727
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 22:21:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com
	[209.85.192.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3695B196
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 22:21:56 +0000 (UTC)
Received: by mail-pf0-f172.google.com with SMTP id c4so32963294pfb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 16 Nov 2016 14:21:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=IXn+eq0KQ26TZGWsp5zTA1TFNnQ/azR3It8pLWePBXw=;
	b=XnQn8gEfCqg6uOGhkiOxgCY41rwKXuOE6qSMpYccyA+Eq9BiZBn1v7fBLg299PUDaQ
	gTUq/pnCHYz3fbwCf2kmAciQcQuYhfF86jTqekDDuDFdNcIbNOjKy9vIVzo+los9OExE
	LXGb8E8wAmQaWUhOTxXiRgTCObml6OhN5qZB2S6sCzeEElJ1flKJBA3Hrvy/vqvL7opx
	kXu2HCH+DiRjV4ee/aE+l+Os+P18UcvGvbEP83nYnotf8msdS7LtcEZjB2i1U/LRQXzX
	YPCUBFKm/y2fum1nlPDJMMT7KOPLnPq7YO0Fvpy/3CmF9AlL2E+nXhyvoagQZRyFprpT
	cC0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=IXn+eq0KQ26TZGWsp5zTA1TFNnQ/azR3It8pLWePBXw=;
	b=RgWW+wrVL7jbZpPTCmX9LC+ghfx0HHMawbFu404mT06kdpa/d3I9zHnYGqeWluqz3r
	ut0g0aKtq/8pXbgwIGtB5DxcCdA0vsrLuO7/17vZAlGnqdCc90/I0fzO5OPM6E1/a9AF
	LTBIWd9xsRuL9wBHGleQpLbGZ1P66Wk+A0OhGRX9evlvOu5Gq3iEARH/nSwEdy2wdH5f
	x7B/M9eouaxJCsn2VpPeCK9fVZ2fGjv3gCaIShFJiegpf0q/WE9Wir8KxoXv9QVoVSRO
	ML7tvJzi+hzVYpCjypN7KvAmMA2ksXYWSwvlTbfMN2rHTDEXCxKBPrqJu5LZJlDvzYwH
	Spww==
X-Gm-Message-State: ABUngveyecNM+omDE7R+G1sUfvLukYagerpwuk2bSRNXGDjKwsNzpH7T13/WrcrUwIMkmQ==
X-Received: by 10.99.230.83 with SMTP id p19mr7784644pgj.121.1479334915838;
	Wed, 16 Nov 2016 14:21:55 -0800 (PST)
Received: from [10.55.212.10] (mobile-166-176-184-208.mycingular.net.
	[166.176.184.208]) by smtp.gmail.com with ESMTPSA id
	131sm56971216pfx.92.2016.11.16.14.21.55
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 16 Nov 2016 14:21:55 -0800 (PST)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14B100)
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>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Wed, 16 Nov 2016 22:24:34 +0000
Subject: Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 22:21:57 -0000

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