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 51EC312A1 for ; Wed, 30 Dec 2015 13:28:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B81CC10F for ; Wed, 30 Dec 2015 13:28:07 +0000 (UTC) Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197] (may be forged)) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBUDS3WJ030430 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Dec 2015 05:28:05 -0800 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Jonathan Toomim In-Reply-To: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org> Date: Wed, 30 Dec 2015 05:29:05 -0800 Message-Id: <8E12B367-1A55-435F-9244-101C09094BDA@toom.im> References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org> To: joe2015@openmailbox.org X-Mailer: Apple Mail (2.1878.6) X-Sonic-CAuth: UmFuZG9tSVavtly3mPwDMDizXaXjRYhsZWpkuaUJqla11ZE0AFxobfdXsBCKHyUZgGngCU4H4OL5vUAwbmeFrBByvtcOR7ot X-Sonic-ID: C;ouKgJ/mu5RGKicgxU3XIUw== M;xlFEKPmu5RGKicgxU3XIUw== X-Sonic-Spam-Details: 3.8/5.0 by cerberusd 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 13:28:08 -0000 --Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As a first impression, I think this proposal is intellectually = interesting, but crufty and hackish and should never actually be = deployed. Writing code for Bitcoin in a future in which we have deployed = a few generalized softforks this way sounds terrifying. Instead of this: CTransaction GetTransaction(CBlock block, unsigned int index) { return block->vtx[index]; } We might have this: CTransaction GetTransaction(CBlock block, unsigned int index) { if (!IsBIP102sBlock(block)) { return block->vtx[index]; } else { if (!IsOtherGeneralizedSoftforkBlock(block)) { // hooray! only one generalized softfork level to deal = with! return = LookupBlock(GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[in= dex]; } else { throw NotImplementedError; // I'm too lazy to write = pseudocode this complicated just to argue a point } } It might be possible to make that a bit simpler with recursion, or by = doing subsequent generalized softforks in a way that doesn't have = multi-levels-deep block-within-a-block-within-a-block stuff. Still: ugh. On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev = wrote: > Below is a proof-of-concept implementation of BIP102 as a softfork: >=20 > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize > = https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015= _2mb_blocksize?diff=3Dsplit&name=3D2015_2mb_blocksize >=20 > BIP102 is normally a hardfork. The softfork version (unofficial > codename BIP102s) uses the idea described here: > = http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/01207= 3.html >=20 > The basic idea is that post-fork blocks are constructed in such a way > they can be mapped to valid blocks under the pre-fork rules. BIP102s > is a softfork in the sense that post-fork miners are still creating a > valid chain under the old rules, albeit indirectly. >=20 > =46rom the POV of non-upgraded clients, BIP102s circumvents the > block-size limit by moving transaction validation data "outside" of > the block. This is a similar trick used by Segregated Witness and > Extension Blocks (both softfork proposals). >=20 > =46rom the POV of upgraded clients, the block layout is unchanged, > except: > - A larger 2MB block-size limit (=3DBIP102); > - The header Merkle root has a new (backwards compatible) > interpretation; > - The coinbase encodes the Merkle root of the remaining txs. > Aside from this, blocks maintain their original format, i.e. a block > header followed by a vector of transactions. This keeps the > implementation simple, and is distinct from SW and EB. >=20 > Since BIP102s is a softfork it means that: > - A miner majority (e.g. 75%, 95%) force miner consensus (100%). This > is not true for a hardfork. > - Fraud risk is significantly reduced (6-conf unlikely depending on > activation threshold). > This should address some of the concerns with deploying a block-size > increase using a hardfork. >=20 > Notes: >=20 > - The same basic idea could be adapted to any of the other proposals > (BIP101, 2-4-8, BIP202, etc.). > - I used Jeff Garzik's BIP102 implementation which is incomplete (?). > The activation logic is left unchanged. > - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my > code :-( >=20 > --joe >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJWg9whAAoJEIEuMk4MG0P1iW8H/ie47pnBcQXkB36LKP9UEceh fTGBsrImiNnDEUt07vu+7qHe8ia3s4+sX/6j6x+baJ0TRUU+elG4j5dsU+SwScBr oaWsYFIS/kNS9NeoQ+l/vXz5VUHPCbajCbNVR/nubrgHujx1tf1I1pNoIRd5e824 IlPw++MQkka5c6k1ufYarynuvdrft2izTqe2oOGlrHQ12P63mu1XwsWXcdIkFa7O cuuCo2X05VMk6PADJ1+KqG4iKImOKtukaB/aGoHoFrkf5k1o8ajjMqBSptrmaf3T LflnMjcAqGKiNPp1kB63+Bl4JgTGvhMqIsdO/EQwzfqS8KxXwm0qwVql52oJmyk= =pEPv -----END PGP SIGNATURE----- --Apple-Mail=_E8EC9A5F-95A4-4FFC-8068-E514E8CA7DC7--