path: root/6a/22359d5cb1909728cf496a1e95d970892bbe07

Return-Path: <marcel@jamin.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DFF0DF6A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Dec 2015 13:57:08 +0000 (UTC)
Received: by mail-yk0-f173.google.com with SMTP id x67so154199403ykd.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAAUq484dsvTSKTazj=J0zaqJxNQkSVyBS9H8pGZzDNyKhw_eVQ@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: Jonathan Toomim <j@toom.im>
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 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr">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.</div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-d=
ev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</spa=
n>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Instead of this:<br>
<br>
=C2=A0 =C2=A0 CTransaction GetTransaction(CBlock block, unsigned int index)=
 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return block-&gt;vtx[index];<br>
=C2=A0 =C2=A0 }<br>
<br>
We might have this:<br>
<br>
=C2=A0 =C2=A0 CTransaction GetTransaction(CBlock block, unsigned int index)=
 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!IsBIP102sBlock(block)) {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return block-&gt;vtx[index];<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } else {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (!IsOtherGeneralizedSoftforkBl=
ock(block)) {<br>
=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!<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return LookupBlock(=
GetGSHashFromCoinbase(block-&gt;vtx[0].vin[0].scriptSig))-&gt;vtx[index];<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} else {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0throw NotImplemented=
Error; // I&#39;m too lazy to write pseudocode this complicated just to arg=
ue a point<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 }<br>
<br>
It might be possible to make that a bit simpler with recursion, or by doing=
 subsequent generalized softforks in a way that doesn&#39;t have multi-leve=
ls-deep block-within-a-block-within-a-block stuff. Still: ugh.<br>
<br>
<br>
<br>
<br>
On Dec 29, 2015, at 9:46 PM, joe2015--- via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br>
<br>
&gt; Below is a proof-of-concept implementation of BIP102 as a softfork:<br=
>
&gt;<br>
&gt; <a href=3D"https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize" r=
el=3D"noreferrer" target=3D"_blank">https://github.com/ZoomT/bitcoin/tree/2=
015_2mb_blocksize</a><br>
&gt; <a href=3D"https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksi=
ze...ZoomT:2015_2mb_blocksize?diff=3Dsplit&amp;name=3D2015_2mb_blocksize" r=
el=3D"noreferrer" target=3D"_blank">https://github.com/jgarzik/bitcoin/comp=
are/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=3Dsplit&amp;name=3D2=
015_2mb_blocksize</a><br>
&gt;<br>
&gt; BIP102 is normally a hardfork.=C2=A0 The softfork version (unofficial<=
br>
&gt; codename BIP102s) uses the idea described here:<br>
&gt; <a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015=
-December/012073.html" rel=3D"noreferrer" target=3D"_blank">http://lists.li=
nuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html</a><br>
&gt;<br>
&gt; The basic idea is that post-fork blocks are constructed in such a way<=
br>
&gt; they can be mapped to valid blocks under the pre-fork rules.=C2=A0 BIP=
102s<br>
&gt; is a softfork in the sense that post-fork miners are still creating a<=
br>
&gt; valid chain under the old rules, albeit indirectly.<br>
&gt;<br>
&gt; From the POV of non-upgraded clients, BIP102s circumvents the<br>
&gt; block-size limit by moving transaction validation data &quot;outside&q=
uot; of<br>
&gt; the block.=C2=A0 This is a similar trick used by Segregated Witness an=
d<br>
&gt; Extension Blocks (both softfork proposals).<br>
&gt;<br>
&gt; From the POV of upgraded clients, the block layout is unchanged,<br>
&gt; except:<br>
&gt; - A larger 2MB block-size limit (=3DBIP102);<br>
&gt; - The header Merkle root has a new (backwards compatible)<br>
&gt;=C2=A0 interpretation;<br>
&gt; - The coinbase encodes the Merkle root of the remaining txs.<br>
&gt; Aside from this, blocks maintain their original format, i.e. a block<b=
r>
&gt; header followed by a vector of transactions.=C2=A0 This keeps the<br>
&gt; implementation simple, and is distinct from SW and EB.<br>
&gt;<br>
&gt; Since BIP102s is a softfork it means that:<br>
&gt; - A miner majority (e.g. 75%, 95%) force miner consensus (100%).=C2=A0=
 This<br>
&gt;=C2=A0 is not true for a hardfork.<br>
&gt; - Fraud risk is significantly reduced (6-conf unlikely depending on<br=
>
&gt;=C2=A0 activation threshold).<br>
&gt; This should address some of the concerns with deploying a block-size<b=
r>
&gt; increase using a hardfork.<br>
&gt;<br>
&gt; Notes:<br>
&gt;<br>
&gt; - The same basic idea could be adapted to any of the other proposals<b=
r>
&gt;=C2=A0 (BIP101, 2-4-8, BIP202, etc.).<br>
&gt; - I used Jeff Garzik&#39;s BIP102 implementation which is incomplete (=
?).<br>
&gt;=C2=A0 The activation logic is left unchanged.<br>
&gt; - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my<b=
r>
&gt;=C2=A0 code :-(<br>
&gt;<br>
&gt; --joe<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--94eb2c080440f8863405281de919--