Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DFF0DF6A for ; Wed, 30 Dec 2015 13:57:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D087F89 for ; Wed, 30 Dec 2015 13:57:08 +0000 (UTC) Received: by mail-yk0-f173.google.com with SMTP id x67so154199403ykd.2 for ; Wed, 30 Dec 2015 05:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamin-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JdA9ap4fYGz5KLurcith+0fQAqWp1b8uxkOWqu1kCc0=; b=eU6gC9zO4vomuzqyj61z/UC1is+PrLDLcMy/uAZ1NcLNAgr+4kGNtLrJRFxGPn5D1K z/pzla5jDSDTdnVeVbCl0UkOZ11wVZljasVNnSgHfzbNLnVDjwPVWRAgB8pO95Phd3JQ 75Pf+XBK5rz41vo1FMMc9s1ZIgY9y+y56BsbsGX+RcTNnvct4wbdBLYldUdP6tfOoRdJ 9DDhTkTRPLvmjNvvMf6SnlsB9nvMHKLJKJUVBhxhM0+ED91wWEwd1X1w3AusTskE6eop wyOTaRC9m9E8L4/QGv7zTT/BBxkZnKOwuS69l2Wt+n1R9kWYbUE1KfCeDZgvtgNIPSwR QIGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JdA9ap4fYGz5KLurcith+0fQAqWp1b8uxkOWqu1kCc0=; b=KsxawMeV8R/c1X1AROoAudF0VGZ4a2A8cSck248xEBjwh2sXr/KRDUwoTcG+jv7kuR GnIEdgF/WxMgjcXJ8dqZNEADfabgVYwIrHkQLDs/UZo+eMA8U8K4BQndv/8Z5PFO75oX he1g3HcgVBQM1lJn/FekBMMU7jC4ZmTIdQDG0TL8JDoIXtf+szWVrUCWR2+pUIqvHGv1 q9HlQ939jfyJWAV8bx6DW6uzsSjqMi7KZZFus9LRrfR1M99I9wkBd3lp3+g6Zc0GBSWm ny2q3ip6BM1IfrxOO3IGmXCMVRV7k0N9rRmOmlqtjG7gRl2FJi7ZewY9+iMI2EBjCxsc mUbw== X-Gm-Message-State: ALoCoQlaPH5cWH1YY1VVgkIh3reDN+axVPMtadRBa8mtYUeuDxiPUsFieeK9aw9PNRkYtb0s5uKPLfCsMNrUdnPuC9wRhSOlIw== MIME-Version: 1.0 X-Received: by 10.129.138.195 with SMTP id a186mr47155201ywg.325.1451483828080; Wed, 30 Dec 2015 05:57:08 -0800 (PST) Received: by 10.13.248.6 with HTTP; Wed, 30 Dec 2015 05:57:08 -0800 (PST) In-Reply-To: <8E12B367-1A55-435F-9244-101C09094BDA@toom.im> References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org> <8E12B367-1A55-435F-9244-101C09094BDA@toom.im> Date: Wed, 30 Dec 2015 14:57:08 +0100 Message-ID: From: Marcel Jamin To: Jonathan Toomim Content-Type: multipart/alternative; boundary=94eb2c080440f8863405281de919 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,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 X-Mailman-Approved-At: Wed, 30 Dec 2015 16:48:24 +0000 Cc: bitcoin-dev 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:57:10 -0000 --94eb2c080440f8863405281de919 Content-Type: text/plain; charset=UTF-8 I guess the same could be said about the softfork flavoured SW implementation. In any case, the strategy pattern helps with code structure in situations like this. 2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > 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[index]; > } 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 < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Below is a proof-of-concept implementation of BIP102 as a softfork: > > > > https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize > > > https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize > > > > 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/012073.html > > > > 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. > > > > From 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). > > > > From the POV of upgraded clients, the block layout is unchanged, > > except: > > - A larger 2MB block-size limit (=BIP102); > > - 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. > > > > 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. > > > > Notes: > > > > - 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 :-( > > > > --joe > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c080440f8863405281de919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess the same could be said about the softfork flavoure= d SW implementation. In any case, the strategy pattern helps with code stru= cture in situations like this.

2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org>:
As a first impression, I think this p= roposal is intellectually interesting, but crufty and hackish and should ne= ver 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:

=C2=A0 =C2=A0 CTransaction GetTransaction(CBlock block, unsigned int index)= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return block->vtx[index];
=C2=A0 =C2=A0 }

We might have this:

=C2=A0 =C2=A0 CTransaction GetTransaction(CBlock block, unsigned int index)= {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!IsBIP102sBlock(block)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return block->vtx[index];
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!IsOtherGeneralizedSoftforkBl= ock(block)) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // hooray! only one= generalized softfork level to deal with!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return LookupBlock(= GetGSHashFromCoinbase(block->vtx[0].vin[0].scriptSig))->vtx[index]; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throw NotImplemented= Error; // I'm too lazy to write pseudocode this complicated just to arg= ue a point
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }

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-leve= ls-deep block-within-a-block-within-a-block stuff. Still: ugh.




On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:

> Below is a proof-of-concept implementation of BIP102 as a softfork: >
> https://github.com/ZoomT/bitcoin/tree/2= 015_2mb_blocksize
> https://github.com/jgarzik/bitcoin/comp= are/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=3Dsplit&name=3D2= 015_2mb_blocksize
>
> BIP102 is normally a hardfork.=C2=A0 The softfork version (unofficial<= br> > codename BIP102s) uses the idea described here:
> http://lists.li= nuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html
>
> The basic idea is that post-fork blocks are constructed in such a way<= br> > they can be mapped to valid blocks under the pre-fork rules.=C2=A0 BIP= 102s
> is a softfork in the sense that post-fork miners are still creating a<= br> > valid chain under the old rules, albeit indirectly.
>
> From the POV of non-upgraded clients, BIP102s circumvents the
> block-size limit by moving transaction validation data "outside&q= uot; of
> the block.=C2=A0 This is a similar trick used by Segregated Witness an= d
> Extension Blocks (both softfork proposals).
>
> From 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)
>=C2=A0 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.=C2=A0 This keeps the
> implementation simple, and is distinct from SW and EB.
>
> Since BIP102s is a softfork it means that:
> - A miner majority (e.g. 75%, 95%) force miner consensus (100%).=C2=A0= This
>=C2=A0 is not true for a hardfork.
> - Fraud risk is significantly reduced (6-conf unlikely depending on >=C2=A0 activation threshold).
> This should address some of the concerns with deploying a block-size > increase using a hardfork.
>
> Notes:
>
> - The same basic idea could be adapted to any of the other proposals >=C2=A0 (BIP101, 2-4-8, BIP202, etc.).
> - I used Jeff Garzik's BIP102 implementation which is incomplete (= ?).
>=C2=A0 The activation logic is left unchanged.
> - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my >=C2=A0 code :-(
>
> --joe
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--94eb2c080440f8863405281de919--