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 29F5CB56 for ; Wed, 16 Nov 2016 14:38:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D715232E for ; Wed, 16 Nov 2016 14:38:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx05.mykolab.com (mx05.mykolab.com [10.20.7.161]) by mx-out02.mykolab.com (Postfix) with ESMTPS id E20FF617CD for ; Wed, 16 Nov 2016 15:38:22 +0100 (CET) From: Tom Zander To: bitcoin-dev@lists.linuxfoundation.org Date: Wed, 16 Nov 2016 15:38:21 +0100 Message-ID: <1797370.j3ssDbnHdc@strawberry> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 16 Nov 2016 14:42:04 +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 14:38:27 -0000 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