From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <jacob.eliosoff@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C099C59 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 30 May 2017 20:10:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lf0-f42.google.com (mail-lf0-f42.google.com [209.85.215.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE37213B for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 30 May 2017 20:10:06 +0000 (UTC) Received: by mail-lf0-f42.google.com with SMTP id m18so55066785lfj.0 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 30 May 2017 13:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4/IBBex3kr6mncY09RIwBXPwA3VuSxmY1Fd+Xs0Qpb0=; b=S9KEustOljuZUoxqrtWh41N9zRJ4BhKizTDo9sf5tH24O5QIJXWJHmhyZHLXaWisaL iXY96gv66//Yv9/MdYwZ8WIDC0uVMJQcJbVLfHUcvpdSO+7JXWdaRlC5TZF6eFny6vgV oh3F/X1aEfKwakrcN9YOgs5fFX1mPALl3kehN56zml5UHN+GHImxb/We7DkOwIJNS8VV IB+ITpeeScINTXR76S67VkvJ0IHq2CwCQBWZw42msjO1IBy+WNXz7Ae7mJINGyHmHmRP o1TBjKkW1rUv/bzYkVGxEbRE1xBPf4Ae1fKcHZU/qMEstDps+25OVhkj9qbvJjEyIRNL KLuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4/IBBex3kr6mncY09RIwBXPwA3VuSxmY1Fd+Xs0Qpb0=; b=trfIpGsnZaavic1F0artMY4U4dtw4kcymLPXNUvnIpwG7rpE+VNBXfy71NnGvbMHDU fme9WHbKqqNO51Xkihvm0rsDHCe0tcCAYyRsLUMZzI3TAoNkwN4HJMgBqXBl7ilK4vmb ipPPicg4E3yJU4g1IiOaItjtYIFUggClwLObkc+RDsz2CrMWm3f1hLUiW97DVJddSbp3 1MASzwSDKo52yX9wOBQpiebjP3aGUUplRrzTtSAstIYvk7OIsjNHkwOChIue8tdNw7ez 9ZCraqet6a5sf0Ffu3qcche7JbrLfriamJ3MT672nLM8dwIDvcPU9Kp+v9cjJuq+eYRw kmkw== X-Gm-Message-State: AODbwcDx40so8Pvla/cdNGKUM5C820Q1seoZF2ti685gi4ysoW+oP3DZ x5Hs2haOyyIMe3mZnoRyMG9wlkrwbg== X-Received: by 10.46.8.18 with SMTP id 18mr6686619lji.90.1496175005350; Tue, 30 May 2017 13:10:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.80.4 with HTTP; Tue, 30 May 2017 13:10:04 -0700 (PDT) Received: by 10.25.80.4 with HTTP; Tue, 30 May 2017 13:10:04 -0700 (PDT) In-Reply-To: <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com> References: <201705232023.40588.luke@dashjr.org> <CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com> <CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com> From: Jacob Eliosoff <jacob.eliosoff@gmail.com> Date: Tue, 30 May 2017 16:10:04 -0400 Message-ID: <CAAUaCyj2Syv-YHiAQGWoeOqvP7_wG_FFQg0630X9Ut0Y_qE3dw@mail.gmail.com> To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> Content-Type: multipart/alternative; boundary="f403045ec282b741fa0550c36352" X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Tue, 30 May 2017 20:23:05 +0000 Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol 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: Tue, 30 May 2017 20:10:08 -0000 --f403045ec282b741fa0550c36352 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd like to know this too. Is it just that a 4MB blockmaxweight would theoretically allow ~4MB blocks (if ~all witness data), which is too big? Or is there a more subtle reason we still need blockmaxsize after a HF? On May 30, 2017 9:28 AM, "Jorge Tim=C3=B3n via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: Why not simply remove the (redundant after sw activation) 1 mb size limit check and increasing the weight limit without changing the discount or having 2 limits? On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Personally, I would prefer if a 2MB lock-in that uses BIP103 for the timing. > > I think up to 20% per year can be absorbed by averages in bandwidth/CPU/RAM > growth, of which bandwidth seems the most constraining. > > - Erik > > > On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> In light of some recent discussions, I wrote up this BIP for a real 2 MB >> block >> size hardfork following Segwit BIP148 activation. This is not part of an= y >> agreement I am party to, nor anything of that sort. Just something to >> throw >> out there as a possible (and realistic) option. >> >> Note that I cannot recommend this to be adopted, since frankly 1 MB blocks >> really are still too large, and this blunt-style hardfork quite risky even >> with consensus. But if the community wishes to adopt (by unanimous >> consensus) >> a 2 MB block size hardfork, this is probably the best way to do it right >> now. >> The only possible way to improve on this IMO would be to integrate it into >> MMHF/"spoonnet" style hardfork (and/or add other unrelated-to-block-size >> HF >> improvements). >> >> I have left Author blank, as I do not intend to personally champion this= . >> Before it may be assigned a BIP number, someone else will need to step u= p >> to >> take on that role. Motivation and Rationale are blank because I do not >> personally think there is any legitimate rationale for such a hardfork a= t >> this >> time; if someone adopts this BIP, they should complete these sections. (= I >> can >> push a git branch with the BIP text if someone wants to fork it.) >> >> <pre> >> BIP: ? >> Layer: Consensus (hard fork) >> Title: Post-segwit 2 MB block size hardfork >> Author: FIXME >> Comments-Summary: No comments yet. >> Comments-URI: ? >> Status: Draft >> Type: Standards Track >> Created: 2017-05-22 >> License: BSD-2-Clause >> </pre> >> >> =3D=3DAbstract=3D=3D >> >> Legacy Bitcoin transactions are given the witness discount, and a block >> size >> limit of 2 MB is imposed. >> >> =3D=3DCopyright=3D=3D >> >> This BIP is licensed under the BSD 2-clause license. >> >> =3D=3DSpecification=3D=3D >> >> Upon activation, a block size limit of 2000000 bytes is enforced. >> The block weight limit remains at 4000000 WU. >> >> The calculation of block weight is modified: >> all witness data, including both scriptSig (used by pre-segwit inputs) and >> segwit witness data, is measured as 1 weight-unit (WU), while all other >> data >> in the block is measured as 4 WU. >> >> The witness commitment in the generation transaction is no longer >> required, >> and instead the txid merkle root in the block header is replaced with a >> hash >> of: >> >> 1. The witness reserved value. >> 2. The witness merkle root hash. >> 3. The transaction ID merkle root hash. >> >> The maximum size of a transaction stripped of witness data is limited to 1 >> MB. >> >> =3D=3D=3DDeployment=3D=3D=3D >> >> This BIP is deployed by flag day, in the block where the median-past tim= e >> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC). >> >> It is assumed that when this flag day has been reached, Segwit has been >> activated via BIP141 and/or BIP148. >> >> =3D=3DMotivation=3D=3D >> >> FIXME >> >> =3D=3DRationale=3D=3D >> >> FIXME >> >> =3D=3DBackwards compatibility=3D=3D >> >> This is a hardfork, and as such not backward compatible. >> It should not be deployed without consent of the entire Bitcoin community. >> Activation is scheduled for 18 months from the creation date of this BIP= , >> intended to give 6 months to establish consensus, and 12 months for >> deployment. >> >> =3D=3DReference implementation=3D=3D >> >> FIXME >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --f403045ec282b741fa0550c36352 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>I'd like to know this too.=C2=A0 Is it just that= a 4MB blockmaxweight would theoretically allow ~4MB blocks (if ~all witnes= s data), which is too big?=C2=A0 Or is there a more subtle reason we still = need blockmaxsize after a HF?</div><div dir=3D"auto"><br><div class=3D"gmai= l_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On May 30, 2017 9:28 A= M, "Jorge Tim=C3=B3n via bitcoin-dev" <<a href=3D"mailto:bitco= in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>= > wrote:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why not simply= remove the (redundant after sw activation) 1 mb size<br> limit check and increasing the weight limit without changing the<br> discount or having 2 limits?<br> <br> <br> On Wed, May 24, 2017 at 1:07 AM, Erik Aronesty via bitcoin-dev<br> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li= sts.<wbr>linuxfoundation.org</a>> wrote:<br> > Personally, I would prefer if a 2MB lock-in that uses BIP103 for the t= iming.<br> ><br> > I think up to 20% per year can be absorbed by averages in bandwidth/CP= U/RAM<br> > growth, of which bandwidth seems the most constraining.<br> ><br> > - Erik<br> ><br> ><br> > On Tue, May 23, 2017 at 4:23 PM, Luke Dashjr via bitcoin-dev<br> > <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= ev@lists.<wbr>linuxfoundation.org</a>> wrote:<br> >><br> >> In light of some recent discussions, I wrote up this BIP for a rea= l 2 MB<br> >> block<br> >> size hardfork following Segwit BIP148 activation. This is not part= of any<br> >> agreement I am party to, nor anything of that sort. Just something= to<br> >> throw<br> >> out there as a possible (and realistic) option.<br> >><br> >> Note that I cannot recommend this to be adopted, since frankly 1 M= B blocks<br> >> really are still too large, and this blunt-style hardfork quite ri= sky even<br> >> with consensus. But if the community wishes to adopt (by unanimous= <br> >> consensus)<br> >> a 2 MB block size hardfork, this is probably the best way to do it= right<br> >> now.<br> >> The only possible way to improve on this IMO would be to integrate= it into<br> >> MMHF/"spoonnet" style hardfork (and/or add other unrelat= ed-to-block-size<br> >> HF<br> >> improvements).<br> >><br> >> I have left Author blank, as I do not intend to personally champio= n this.<br> >> Before it may be assigned a BIP number, someone else will need to = step up<br> >> to<br> >> take on that role. Motivation and Rationale are blank because I do= not<br> >> personally think there is any legitimate rationale for such a hard= fork at<br> >> this<br> >> time; if someone adopts this BIP, they should complete these secti= ons. (I<br> >> can<br> >> push a git branch with the BIP text if someone wants to fork it.)<= br> >><br> >> <pre><br> >> BIP: ?<br> >> Layer: Consensus (hard fork)<br> >> Title: Post-segwit 2 MB block size hardfork<br> >> Author: FIXME<br> >> Comments-Summary: No comments yet.<br> >> Comments-URI: ?<br> >> Status: Draft<br> >> Type: Standards Track<br> >> Created: 2017-05-22<br> >> License: BSD-2-Clause<br> >> </pre><br> >><br> >> =3D=3DAbstract=3D=3D<br> >><br> >> Legacy Bitcoin transactions are given the witness discount, and a = block<br> >> size<br> >> limit of 2 MB is imposed.<br> >><br> >> =3D=3DCopyright=3D=3D<br> >><br> >> This BIP is licensed under the BSD 2-clause license.<br> >><br> >> =3D=3DSpecification=3D=3D<br> >><br> >> Upon activation, a block size limit of 2000000 bytes is enforced.<= br> >> The block weight limit remains at 4000000 WU.<br> >><br> >> The calculation of block weight is modified:<br> >> all witness data, including both scriptSig (used by pre-segwit inp= uts) and<br> >> segwit witness data, is measured as 1 weight-unit (WU), while all = other<br> >> data<br> >> in the block is measured as 4 WU.<br> >><br> >> The witness commitment in the generation transaction is no longer<= br> >> required,<br> >> and instead the txid merkle root in the block header is replaced w= ith a<br> >> hash<br> >> of:<br> >><br> >> 1. The witness reserved value.<br> >> 2. The witness merkle root hash.<br> >> 3. The transaction ID merkle root hash.<br> >><br> >> The maximum size of a transaction stripped of witness data is limi= ted to 1<br> >> MB.<br> >><br> >> =3D=3D=3DDeployment=3D=3D=3D<br> >><br> >> This BIP is deployed by flag day, in the block where the median-pa= st time<br> >> surpasses 1543503872 (2018 Nov 29 at 15:04:32 UTC).<br> >><br> >> It is assumed that when this flag day has been reached, Segwit has= been<br> >> activated via BIP141 and/or BIP148.<br> >><br> >> =3D=3DMotivation=3D=3D<br> >><br> >> FIXME<br> >><br> >> =3D=3DRationale=3D=3D<br> >><br> >> FIXME<br> >><br> >> =3D=3DBackwards compatibility=3D=3D<br> >><br> >> This is a hardfork, and as such not backward compatible.<br> >> It should not be deployed without consent of the entire Bitcoin co= mmunity.<br> >> Activation is scheduled for 18 months from the creation date of th= is BIP,<br> >> intended to give 6 months to establish consensus, and 12 months fo= r<br> >> deployment.<br> >><br> >> =3D=3DReference implementation=3D=3D<br> >><br> >> FIXME<br> >><br> >><br> >><br> >> ______________________________<wbr>_________________<br> >> bitcoin-dev mailing list<br> >> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d= ev@lists.<wbr>linuxfoundation.org</a><br> >> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc= oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation= .<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> ><br> ><br> ><br> > ______________________________<wbr>_________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l= ists.<wbr>linuxfoundation.org</a><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> ><br> ______________________________<wbr>_________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= <wbr>linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= /mailman/listinfo/bitcoin-<wbr>dev</a><br> </blockquote></div><br></div></div></div> --f403045ec282b741fa0550c36352--