From mboxrd@z Thu Jan 1 00:00:00 1970
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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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->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->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->vtx[0].vin[0].scriptSig))->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'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'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 <<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>> wrote:<br>
<br>
> Below is a proof-of-concept implementation of BIP102 as a softfork:<br=
>
><br>
> <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>
> <a href=3D"https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksi=
ze...ZoomT:2015_2mb_blocksize?diff=3Dsplit&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&name=3D2=
015_2mb_blocksize</a><br>
><br>
> BIP102 is normally a hardfork.=C2=A0 The softfork version (unofficial<=
br>
> codename BIP102s) uses the idea described here:<br>
> <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>
><br>
> 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<br>
> is a softfork in the sense that post-fork miners are still creating a<=
br>
> valid chain under the old rules, albeit indirectly.<br>
><br>
> From the POV of non-upgraded clients, BIP102s circumvents the<br>
> block-size limit by moving transaction validation data "outside&q=
uot; of<br>
> the block.=C2=A0 This is a similar trick used by Segregated Witness an=
d<br>
> Extension Blocks (both softfork proposals).<br>
><br>
> From the POV of upgraded clients, the block layout is unchanged,<br>
> except:<br>
> - A larger 2MB block-size limit (=3DBIP102);<br>
> - The header Merkle root has a new (backwards compatible)<br>
>=C2=A0 interpretation;<br>
> - The coinbase encodes the Merkle root of the remaining txs.<br>
> Aside from this, blocks maintain their original format, i.e. a block<b=
r>
> header followed by a vector of transactions.=C2=A0 This keeps the<br>
> implementation simple, and is distinct from SW and EB.<br>
><br>
> Since BIP102s is a softfork it means that:<br>
> - A miner majority (e.g. 75%, 95%) force miner consensus (100%).=C2=A0=
This<br>
>=C2=A0 is not true for a hardfork.<br>
> - Fraud risk is significantly reduced (6-conf unlikely depending on<br=
>
>=C2=A0 activation threshold).<br>
> This should address some of the concerns with deploying a block-size<b=
r>
> increase using a hardfork.<br>
><br>
> Notes:<br>
><br>
> - The same basic idea could be adapted to any of the other proposals<b=
r>
>=C2=A0 (BIP101, 2-4-8, BIP202, etc.).<br>
> - I used Jeff Garzik's BIP102 implementation which is incomplete (=
?).<br>
>=C2=A0 The activation logic is left unchanged.<br>
> - I am not a Bitcoin dev so hopefully no embarrassing mistakes in my<b=
r>
>=C2=A0 code :-(<br>
><br>
> --joe<br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.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=
/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--