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 D4823F54 for ; Thu, 27 Aug 2015 23:19:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149055.authsmtp.co.uk (outmail149055.authsmtp.co.uk [62.13.149.55]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3CB041A5 for ; Thu, 27 Aug 2015 23:19:24 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7RNJJ9V031684; Fri, 28 Aug 2015 00:19:19 +0100 (BST) Received: from muck (us1x.mullvad.net [199.241.145.219]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7RNJDUT051965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 28 Aug 2015 00:19:17 +0100 (BST) Date: Thu, 27 Aug 2015 16:19:13 -0700 From: Peter Todd To: Btc Drak Message-ID: <20150827231913.GC4125@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qcHopEYAB45HaUaB" Content-Disposition: inline In-Reply-To: X-Server-Quench: 0ad80395-4d12-11e5-b398-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdAoUGUATAgsB AmMbW1ReUVR7WGo7 agNYcwdZY1RPWwB0 UklAXVdaExppT1gG ZGBkJnwWdwBHcXh1 K0dmX3BbEkQrIU59 QUdRCGlSZGV9aWFK VV0KdApcbQNKfBpM agF+USdcZitlM3Bw LAUyIzs2PDMaJClL d0knDGpACXsQHzgz DzUPETQmGwUZRiA+ agQvMUJUFV1ZP0M+ KVwgX05QPRgIaEVa GEpOHC5cKhEKTi4g EAdTQU8ZFiY1 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 199.241.145.219/587 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 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for locktime calculations X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 23:19:25 -0000 --qcHopEYAB45HaUaB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote: > This BIP was assigned number 113. >=20 > I have updated the text accordingly and added credits to Gregory Maxwell. >=20 > Please see the changes in the pull request: > https://github.com/bitcoin/bips/pull/182 On Thu, Aug 27, 2015 at 11:11:10PM +0100, Btc Drak via bitcoin-dev wrote: > I have changed BIPS 112 and 113 to reflect this amended deployment > strategy. I'm beginning to think the issues created by Bitcoin XT are > so serious it probably deserves converting OPs text into an > informational BIP. I thought we had decided that the masking thing doesn't work as intended? To recap, XT nodes are producing blocks with nVersion=3D0b001...111 You're suggesting that we apply a mask of ~0b001...111 then trigger the soft-fork on nVersion >=3D 0b0...100 =3D=3D 4, with miners producing blocks= with nVersion=3D0b0...1000 That will work, but it still uses up a version bit. The reason why is blocks with nVersion=3D0b001...000 - the intended deployment of the nVersion bits proposal - will be rejected by the nVersion >=3D 4 rule, hard-forking them off the network. In short, we have in fact "burnt" a version bit unnecessarily. If you're going to accept hard-forking some people off the network, why not just go with my stateless nVersion bits w/ time-expiration proposal instead? The only case where it leads to a hard-fork is if a soft-fork has been rejected by the time the upgrade deadline is reached. It's easy to set this multiple years into the future, so I think in practice it won't be a major issue for non-controversial soft-forks. Equally, spending the time to implement the original stateful nVersion bits proposal is possible as well, though higher risk due to the extra complexity of tracking soft-fork state. --=20 'peter'[:-1]@petertodd.org 000000000000000008ba8215b2b644e33a98a762fd40710bc5e8c7f1b0e78375 --qcHopEYAB45HaUaB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJV35ruXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwOGJhODIxNWIyYjY0NGUzM2E5OGE3NjJmZDQwNzEwYmM1 ZThjN2YxYjBlNzgzNzUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udylVQf7BkMS0W0KFSKvTFViZYxxA9c5 OK2nzQqsUDd1f06QgV/wcEE35dVeNfqZhydFf51dmIqWjvHEUsTvgCmKxFcLpUsa w9dXK10y/diywNyLXEm3e1C5TaMz5GF99GiYgcAMd7SUDvpIFqQHhzQ3sfQTwKW+ LEZr9OKmOCm7VsWPrxadpQCaAkNoiPk+OgJFUM9tOxWd876ZzvNoXjE24cXTBQzV UTXUONMV+DNGD5lkYp14XjS7zg3uAsMB5sKaejJYp33r9YRmbstDjlbOJY6o8Of+ Dh5wSsoUtsrcm53mUbrd3MsIhSKo3ly33gENNuep2LklgzPgXGXJ+I9wBt8Gtw== =uzwL -----END PGP SIGNATURE----- --qcHopEYAB45HaUaB--