Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CDA2D10AC for ; Wed, 30 Dec 2015 14:20:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149112.authsmtp.co.uk (outmail149112.authsmtp.co.uk [62.13.149.112]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9114B128 for ; Wed, 30 Dec 2015 14:20:40 +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 tBUEKd0p065199; Wed, 30 Dec 2015 14:20:39 GMT Received: from muck ([24.114.27.145]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBUEKQNV086240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Dec 2015 14:20:36 GMT Date: Wed, 30 Dec 2015 06:19:55 -0800 From: Peter Todd To: Jonathan Toomim Message-ID: <20151230141955.GA15588@muck> References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org> <8E12B367-1A55-435F-9244-101C09094BDA@toom.im> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2" Content-Disposition: inline In-Reply-To: <8E12B367-1A55-435F-9244-101C09094BDA@toom.im> X-Server-Quench: 7ff20de2-af00-11e5-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdQIUHFAXAgsB AmMbWlBeUl17Wms7 aQ5PbARZfEhJQQRu VVdMSlVNFUssc3l0 fX9gNBl6cQdCeDBx ZEJgWj5cChJ4dRIo QFMFQ20GeGZhPWUC WEJRIh5UcAJPfxhM bwR6UXVDAzANdhEy HhM4ODE3eDlSNhEd awdFLFcKRUsOEzgg TgwDGjNnGkNNbQQL dkR8YlcHVE9ZKUI8 LVUmQ1FeWwA8 X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.27.145/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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork. 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: Wed, 30 Dec 2015 14:20:41 -0000 --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev w= rote: > As a first impression, I think this proposal is intellectually interestin= g, but crufty and hackish and should never actually be deployed. Writing co= de for Bitcoin in a future in which we have deployed a few generalized soft= forks this way sounds terrifying. > It might be possible to make that a bit simpler with recursion, or by doi= ng subsequent generalized softforks in a way that doesn't have multi-levels= -deep block-within-a-block-within-a-block stuff. Still: ugh. Your fear is misplaced: it's trivial to avoid recursion with a bit of planning. For instance, if Bitcoin was redesigned to incorporate the forced fork concept, instead of block headers committing to just a merkle root, they could instead commit to H(version + digest) For version =3D=3D 0, digest would be a merkle root of all transactions. If the version was > 0, any digest would be allowed and the block would be interpreted as a NOP with no effect on the UTXO set. In the event of a major change - e.g. what would otherwise be a hard-forking change to the way the merkle root was calculated - a soft-fork would change the block validity rules to make version =3D=3D 0 invalid, and verison =3D=3D 1 blocks would interpret the digest according to the new merkle root rules. Again, version > 1 blocks would be treated as NOPs. A good exercise is to apply the above to the existing Bitcoin ecosystem as a soft-fork - it certainely can be done, and done right is technically very simple. Regardless of how it's done - existing Bitcoin compatible or clean sheet redesign - you get the significant safety advantages soft-forks have over hard-forks in nearly all situations where you'd have to do a hard-fork. OTOH, it's kinda scary how this institutionalizes what could be seen as 51% attacks, possibly giving miners significantly more control over the system politically. I'm not sure I agree with that viewpoint - miners can do this anyway - but that has made people shy away from promoting this idea in the past. (previously it's been often referred to as an "evil" soft-fork) --=20 'peter'[:-1]@petertodd.org 00000000000000000831fc2554d9370aeba2701fff09980123d24a615eee7416 --UlVJffcvxoiEqYs2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJWg+gIXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwODMxZmMyNTU0ZDkzNzBhZWJhMjcwMWZmZjA5OTgwMTIz ZDI0YTYxNWVlZTc0MTYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzccAf+Mnf/8IG+PuRMc1h1xwnqSBec iingwOmih/ruy1qVUfK2kyh9fSVRHw5FvO/uUvnYY0GcLYdmX1OKRpCiBiIUEiMM eCADPd54tddPP0IquqjCyI+SwlyZV0bhVHHXF3H7fwMn2eNtJsgt49NG40wTBulv ycd0LILVnym1Shz3ckmi0qaO9b/90prtkimUEinZzG3+4WinvhiMTXZIujfuxKwS wbYBUMNLsYuEllWxxh6qxLWmUz1p9rLKs0a1LzeH+TjRCCjLgQm7+oXPHY1gQnc5 BKeUfuyZOZyyj5/Ly2t4KgJrSGtcpe1Z9LjQftJQ8bpUJckuU1mgJXPrcM1qyg== =y2u3 -----END PGP SIGNATURE----- --UlVJffcvxoiEqYs2--