diff options
| author | Peter Todd <pete@petertodd.org> | 2016-11-16 16:01:00 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-11-16 21:01:10 +0000 |
| commit | 23c1f40d3bdca1f5aa281b97519c850d33558cda (patch) | |
| tree | dfea5cb7c4b44a97b697ff94c16810c0e4ac4f2c /52 | |
| parent | 16c8a0cc1775694af70b8ab894a6e75fa920fabf (diff) | |
| download | pi-bitcoindev-23c1f40d3bdca1f5aa281b97519c850d33558cda.tar.gz pi-bitcoindev-23c1f40d3bdca1f5aa281b97519c850d33558cda.zip | |
Re: [bitcoin-dev] [BIP Proposal] Buried Deployments
Diffstat (limited to '52')
| -rw-r--r-- | 52/e8f304f4a139ac23232d2e548a18c5f13faf6e | 136 |
1 files changed, 136 insertions, 0 deletions
diff --git a/52/e8f304f4a139ac23232d2e548a18c5f13faf6e b/52/e8f304f4a139ac23232d2e548a18c5f13faf6e new file mode 100644 index 000000000..0b9b02eb8 --- /dev/null +++ b/52/e8f304f4a139ac23232d2e548a18c5f13faf6e @@ -0,0 +1,136 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 62641955 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Nov 2016 21:01:10 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from outmail149081.authsmtp.net (outmail149081.authsmtp.net + [62.13.149.81]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0525AA7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 16 Nov 2016 21:01:05 +0000 (UTC) +Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) + by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id uAGL13bL011977; + Wed, 16 Nov 2016 21:01:03 GMT +Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com + [52.5.185.120]) (authenticated bits=0) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id uAGL114K034399 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); + Wed, 16 Nov 2016 21:01:02 GMT +Received: from [127.0.0.1] (localhost [127.0.0.1]) + by petertodd.org (Postfix) with ESMTPSA id BAD7F400F7; + Wed, 16 Nov 2016 20:56:20 +0000 (UTC) +Received: by localhost (Postfix, from userid 1000) + id 316B52047A; Wed, 16 Nov 2016 16:01:00 -0500 (EST) +Date: Wed, 16 Nov 2016 16:01:00 -0500 +From: Peter Todd <pete@petertodd.org> +To: Alex Morcos <morcos@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20161116210100.GC5639@savin.petertodd.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> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="O3RTKUHj+75w1tg5" +Content-Disposition: inline +In-Reply-To: <CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com> +User-Agent: Mutt/1.5.23 (2014-03-12) +X-Server-Quench: c89c23dd-ac3f-11e6-829e-00151795d556 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aQdMdwQUFloCAgsB AmAbWVVeUFx7WWE7 bghPaBtcak9QXgdq + T0pMXVMcUXQffR0A AmUeUR1xfgwIeX92 bUMsDXhSD0Z5IRJg + Ex1XQ3AHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk + FAgyOXU9MCtqYBd/ YzlFFUgVWUEQFzoJ DzofBzQiEQUpSj03 KA0jJ1gABy4A +X-Authentic-SMTP: 61633532353630.1037:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 52.5.185.120/25 +X-AuthVirus-Status: No virus detected - but ensure you scan with your own + anti-virus system. +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +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 21:01:10 -0000 + + +--O3RTKUHj+75w1tg5 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote: +> 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 introduced +> 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 or +> 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 new +> 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. + +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_ follow +BIP65, up until that blockhash, and any blockchain without that blockhash m= +ust +respect BIP65 for all blocks in the chain. + +This is a softfork: we've only added rules that made otherwise valid chains +invalid, and at the same time we are still accepting large reorgs (albeit u= +nder +stricter rules than before). + +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 +https://petertodd.org 'peter'[:-1]@petertodd.org + +--O3RTKUHj+75w1tg5 +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- + +iQEcBAEBCgAGBQJYLMkJAAoJECSBQD2l8JH7Q3oH/Roi+0I8kT8S2GITOgS+XQRv +Ro8ghB3KrHE76Q4SLM+GT4CZvYevBdcsqM8epeGsOaeLYxpPPhhd0XJJ9+O4/qJo +6+OIbgkWV98IK9ss+uqxYwYam6Z3EJL6WE+Y/sgyfnQkNkHrOObg1e2JeAl4Q31/ +/Ty128nR8doRIVU9fh/pnqaP//CrDtogf6mnfVAcRUZZRSXhAGDW8cmXV/xGtXFN +KVszxqkV+8bNxP9zt+oS7Y7hp6m7KpjY8DPQSNCfGop0lVvik9JzmkJGlAKM84+w +zi/oGTO/JiwoaoIbKdVobqMmedKKrP5pIcI6fE03lL0qTKSfdzxk2U32PbNF+aQ= +=ocKT +-----END PGP SIGNATURE----- + +--O3RTKUHj+75w1tg5-- + |