From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E6BC727 for ; 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 ; Wed, 16 Nov 2016 22:21:56 +0000 (UTC) Received: by mail-pf0-f172.google.com with SMTP id c4so32963294pfb.1 for ; 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 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: <33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org> <20161116210100.GC5639@savin.petertodd.org> To: Peter Todd , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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