From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YxYN5-0000DG-2A for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:15:35 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.81 as permitted sender) client-ip=62.13.149.81; envelope-from=pete@petertodd.org; helo=outmail149081.authsmtp.net; Received: from outmail149081.authsmtp.net ([62.13.149.81]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YxYN3-0002R8-4W for bitcoin-development@lists.sourceforge.net; Wed, 27 May 2015 10:15:35 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4RAFOuc005616; Wed, 27 May 2015 11:15:24 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4RAFGJX047330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 11:15:19 +0100 (BST) Date: Wed, 27 May 2015 06:15:16 -0400 From: Peter Todd To: Tier Nolan Message-ID: <20150527101516.GB25814@savin.petertodd.org> References: <201505270346.17014.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 474e907f-0459-11e5-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAUUFVQNAgsB AmMbWlVeUVh7WGo7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRhj d2hpKHFycwJFe34+ bENhWT5fW0AvfEZ6 FFNUEWgPeGZhPWUC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA41EyQn RhcEVT8uAVZNXz80 Nxs9I1p0 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YxYN3-0002R8-4W Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Version bits proposal X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 10:15:35 -0000 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote: > I think it would be better to have the deadlines set as block counts. Th= at > eliminates the need to use the median time mechanism. The median time mechanism is basically a way for hashing power to show what time they think it is. Equally, the nVersion soft-fork mechanism is a way for hashing power to show what features they want to support. Block counts are inconvenient for planning, as there's no guarantee they'll actually happen in any particular time frame, forward and back. There's no particular incentive problems here - the median time clearly shows support by a majority of hashing power - so I don't see any reason to make planning more difficult. > The deadline could be matched to a "start-line". The definition would th= en > be something like >=20 > BIP 105 > Start block: 325000 > End block: 350000 > Activation: 750 of 1000 > Implication: 950 of 1000 > Bit: 9 >=20 > This would allow creation of a simple table of known BIPs. It also keeps > multiple users of the bit as strictly separate. If you assume no large reorganizations, your table of known BIPs can just as easily be a list of block heights even if the median time mechanism is used. If you do assume there may be large reorganizations you can't have a "simple table" --=20 'peter'[:-1]@petertodd.org 000000000000000001643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6 --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVZZkwXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMTY0M2Y3NzA2ZjNkY2JjM2EzODZlNGMxYmZiYTg1MmZm NjI4ZDgwMjRmODc1YjYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsL0Af+NMKw3M9MOuUEQPgZUDkgNGsz rSZUx3zif08M4GGRe9YKmNYiEZontblO1G9aM5GJnkxt1sz23ikAgTbNVgFa8j39 Qmc3PN+sLwLhaor4pGrSLU/nwEQb4K96kEuVOhjF9cBYJB02067DmFVCr3bTB+Kk v46j37tVe3uTer7KEBr0m+RGqVjMxAmRa6OKRRkBL2VDsrwo4D49DFrssdtduWpK dxGAlcZP52Ls0CTyPpbnCnrzojgEyfNfU68ld3xwoCu2wmCzw1YbnYQuTTfXm3ZR AozbigXNIdR3au36y7QdVxWPa9IWSbEYmimCtjlkaGHs3alDSFnRbZIfOb/cpA== =T3wN -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq--