Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 75A2D1076 for ; Tue, 23 Jan 2018 21:57:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 30921EC for ; Tue, 23 Jan 2018 21:57:13 +0000 (UTC) Received: by mail-lf0-f50.google.com with SMTP id o89so2532765lfg.10 for ; Tue, 23 Jan 2018 13:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chaincode-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=zy9qONpMKQR0b4jpKDsHfmxa5HTBMhU4zDIvqXVDGfs=; b=zId7CoouPaMES9Ykwe2wBcfrIA2axo0keWddPYpMDhLwxvyPicknYXmCOLs10MfqzQ t+s9h7DA4KDV/g5amS86F0aXpjakvIqTu8r2u6wZLHDNfdQM+pBwdkEWMiiLdmW7l1OK p6+OAyPZGeW+EGaxMR5VchtgC0W2d8E3rYzi+NJY2f9x5gw5ZCRHvSSiL68igiZzNmIL diBHpvig2ZeXVbvqh6jhyZ6NXmUvJWwXTGPH/OzBqrZsGKYJcyUbcPXT1+ToKmdI3dQ7 aEThNwNQNCqZaJzZxIry+ravqMxJ81T3yJjXgi3Hwnm/LopYWDdOwyMmlfr97d2fpeRJ BgfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zy9qONpMKQR0b4jpKDsHfmxa5HTBMhU4zDIvqXVDGfs=; b=n3sFMma4qpkYkTtgSfdz7RZzclNbtZFSysamJyx8YFHlUj5G7qSLDI8d28GnQmVipA EF3rX0e5ovqTs/rITKGDmb8tLl+w7IPJYJg2yjs9DkY0QqRbOoA7v9pnP2qQDRrdl1NT PIEZgR4b+mV4WYo8iYHdDqMOYMDQmheBjwcyO2DRosV09UDfzORav5oev+QRY9QIFl5u BBIRie6g3P68Wjj262rHXVyX/BAwyiIDda9z7PH6Y96+hbcCjE3p55spujR8URuAvJxz ziM/tC4d0OgvlkMv6+xY3/htxVUpmzzIBVn2znEEGyz7PlSO/VqJj7HvQNMQ6N5h4Ft2 Ak6A== X-Gm-Message-State: AKwxytcLk5FbJRKmn8ndSc7jDLzsHVEvxmbBULHnW3TetW3M+djasXA7 9/P2Ulh033yXDFoaVH45jf9L6653nTYbJpreBXNwmTQ1/Wg= X-Google-Smtp-Source: AH8x224G1Hr75Moxiy6dxmseTx3qQkLJMRzR04BILdGfmQAPbL5QKssYKTZLdmaH9Mo/eOAapXNGEccs5L36+gfP4Vw= X-Received: by 10.46.5.15 with SMTP id 15mr2049436ljf.98.1516744631209; Tue, 23 Jan 2018 13:57:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.80.72 with HTTP; Tue, 23 Jan 2018 13:56:50 -0800 (PST) From: John Newbery Date: Tue, 23 Jan 2018 16:56:50 -0500 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="001a114a7e12f5671f056378a083" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, 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: Tue, 23 Jan 2018 21:57:53 +0000 Subject: [bitcoin-dev] BIP16 enforcement change in V0.16 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: Tue, 23 Jan 2018 21:57:14 -0000 --001a114a7e12f5671f056378a083 Content-Type: text/plain; charset="UTF-8" The upcoming v0.16 release contains a slight change to the way that BIP16 is enforced, by basing activation on block height instead of block time. This brings BIP 16 enforcement in line with BIP 34, BIP 66 and BIP 65. This has no impact on consensus since BIP 16 was activated before the last checkpoint and is buried under >300,000 blocks. I've written up the changes in the BIP style below, although I don't think this necessarily requires a full BIP. BIP 16 enforcement will likely change again with https://github.com/bitcoin/bitcoin/pull/11739 in the next bitcoin core release, so a formal proposal for this as a BIP will quickly be superseded.
  BIP: ??
  Layer: Consensus
  Title: Buried Deployments (P2SH)
  Author: John Newbery 
  Comments-Summary: No comments yet
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
  Status: Draft
  Type: Informational
  Created: 2018-01-22
  License: CC-0
==Abstract== Enforce BIP 16 consensus rules based on block height rather than block time. ==Background== BIP 16 was deployed via a hardcoded flag day consensus rule change. Prior to the date of the consensus rule change being fixed, the miners signaled readiness for the change by placing the string "/P2SH/" in the scriptSig of the coinbase transaction txIn. The rule change was originally intended to come into effect on 15 Feb 2012, but due to lack of miner signaling, the activation date was pushed back to April 1st 2012. See [ https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki The BIP 16 specification] for full details on the deployment method. The final activation method was via a hardcoded block time of 1333238400 (April 1st 2012). Now that the chain has long since passed the block at which the P2SH consensus rule was activated, we can (as a simplification) replace the trigger mechanism by caching the block height at which those consensus rules became enforced. ==Motivation== Activating the BIP 16 consensus change based on block time has several disadvantages: * The consensus change can be activated and later deactivated in the same chain (since block time is not necessarily monotonically increasing). * It is less flexible for constructing test chains for testing P2SH and other soft fork activation The flag day activation mechanism for code deployments was deprecated in favor of [https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki IsSuperMajority] deployments, and later by [ https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki version bits] deployments. BIP 34, BIP 65, and BIP 66 deployments were later 'buried' by [ https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki BIP 90] with simple height checks. This simplification of the consensus rules reduced the technical debt associated with deployment of those consensus changes. This BIP changes the BIP 16 activation method to also be a 'buried' deployment, activating at the block height that BIP 16 actually activated. For the mainnet chain, this is block height 173805. ==Considerations== Just as for the buried BIP 34, BIP 65 and BIP 66 deployments, it is technically possible for this to be a non-backwards compatible change. For example, if an alternate chain were created in which block height 173805 was reached after April 1st 2012, and a block with height <173805 but block time after April 1st 2012 included an invalid P2SH spend, older software would see that chain as invalid, but newer software implementing this change would not. See [https://github.com/bitcoin/bips/blob/master/bip-0090.mediawiki BIP 90] for justification of why this class of change is acceptable. As of January 2018, BIP 16 is buried by over 300,000 blocks. BIP 16 activation is also protected by checkpoints (the most recent of which is at height 295000). ==Specification== The BIP 16 activation height is set to 173805. To determine whether to enforce BIP 16 on a given block, we just compare the height of the block being validated with the stored activation height: // Start enforcing P2SH (BIP16) if (pindex->nHeight >= consensusparams.BIP16Height) { flags |= SCRIPT_VERIFY_P2SH; } See the implementation for additional details. ==Implementation== https://github.com/bitcoin/bitcoin/commit/18e071841e83044b47aa45c3e98c0796a407d445 ==Acknowledgements== Thanks to Russ Yanofsky, Marco Falke and Suhas Daftuar for suggestions and feedback. ==Copyright== This document is placed in the public domain. --001a114a7e12f5671f056378a083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The upcoming v0.16 release contains a slight change t= o the way that BIP16 is enforced, by basing activation on block height inst= ead of block time. This brings BIP 16 enforcement in line with BIP 34, BIP = 66 and BIP 65.

This has no impact on consensus sin= ce BIP 16 was activated before the last checkpoint and is buried under >= 300,000 blocks.

I've written up the changes in= the BIP style below, although I don't think this necessarily requires = a full BIP. BIP 16 enforcement will likely change again with https://github.com/bitcoin/bitc= oin/pull/11739 in the next bitcoin core release, so a formal proposal f= or this as a BIP will quickly be superseded.=C2=A0

<pre>
=C2=A0 BIP: ??
=C2=A0 Layer: Consensus
=C2=A0 Title: Buried Deployments (P2SH)
=C2=A0 Author: Joh= n Newbery <john@chaincode.com&= gt;
=C2=A0 Comments-Summary: No comments yet
=C2= =A0 Status: Draft
=C2=A0 Type: Informational
=C2=A0 Cre= ated: 2018-01-22
=C2=A0 License: CC-0
</pre>


=3D=3DAbstract=3D=3D

Enforce BIP 16 consensus rules based on block height rather than blo= ck time.

=3D=3DBackground=3D=3D

BIP 16 was deployed via a hardcoded flag day consensus rule change. = Prior to the date of the consensus rule change being fixed, the miners sign= aled readiness for the change by placing the string "/P2SH/" in t= he scriptSig of the coinbase transaction txIn. The rule change was original= ly intended to come into effect on 15 Feb 2012, but due to lack of miner si= gnaling, the activation date was pushed back to April 1st 2012. See [https:= //github.com/bitcoin/bips/blob/master/bip-0034.mediawiki The BIP 16 spe= cification] for full details on the deployment method. The final activation= method was via a hardcoded block time of 1333238400 (April 1st 2012).

Now that the chain has long since passed the block at = which the P2SH consensus rule was activated, we can (as a simplification) r= eplace the trigger mechanism by caching the block height at which those con= sensus rules became enforced.

=3D=3DMotivation=3D= =3D

Activating the BIP 16 consensus change based o= n block time has several disadvantages:

* The cons= ensus change can be activated and later deactivated in the same chain (sinc= e block time is not necessarily monotonically increasing).
* It i= s less flexible for constructing test chains for testing P2SH and other sof= t fork activation

The flag day activation mechanis= m for code deployments was deprecated in favor of [https://github.com/bitco= in/bips/blob/master/bip-0034.mediawiki IsSuperMajority] deployments, an= d later by [https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki<= /a> version bits] deployments.

BIP 34, BIP 65, and= BIP 66 deployments were later 'buried' by [https://github.com/bitc= oin/bips/blob/master/bip-0090.mediawiki BIP 90] with simple height chec= ks. This simplification of the consensus rules reduced the technical debt a= ssociated with deployment of those consensus changes.

<= div>This BIP changes the BIP 16 activation method to also be a 'buried&= #39; deployment, activating at the block height that BIP 16 actually activa= ted. For the mainnet chain, this is block height 173805.

=3D=3DConsiderations=3D=3D

Just as for the = buried BIP 34, BIP 65 and BIP 66 deployments, it is technically possible fo= r this to be a non-backwards compatible change. For example, if an alternat= e chain were created in which block height 173805 was reached after April 1= st 2012, and a block with height <173805 but block time after April 1st = 2012 included an invalid P2SH spend, older software would see that chain as= invalid, but newer software implementing this change would not.
=
See [https://github.com/bitcoin/bips/blob/master/bip-0090.me= diawiki BIP 90] for justification of why this class of change is accept= able. As of January 2018, BIP 16 is buried by over 300,000 blocks. BIP 16 a= ctivation is also protected by checkpoints (the most recent of which is at = height 295000).

=3D=3DSpecification=3D=3D

The BIP 16 activation height is set to 173805.
<= br>
To determine whether to enforce BIP 16 on a given block, we j= ust compare the height of the block being validated with the stored activat= ion height:

=C2=A0 =C2=A0 // Start enforcing P2SH = (BIP16)
=C2=A0 =C2=A0 if (pindex->nHeight >=3D consensuspar= ams.BIP16Height) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 flags |=3D SCRIPT_= VERIFY_P2SH;
=C2=A0 =C2=A0 }

See the imp= lementation for additional details.

=3D=3DImplemen= tation=3D=3D

=

=3D=3DAcknowledgements=3D=3D

T= hanks to Russ Yanofsky, Marco Falke and Suhas Daftuar for suggestions and f= eedback.

=3D=3DCopyright=3D=3D

This document is placed in the public domain.
--001a114a7e12f5671f056378a083--