diff options
author | Jared Lee Richardson <jaredr26@gmail.com> | 2017-06-02 13:13:58 -0700 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-06-02 20:14:01 +0000 |
commit | 13b5907844d6526321760f3127e0746f24e6ee1b (patch) | |
tree | a28efb0dc265a7260e150b7407102a93380fd008 | |
parent | 26f8412bf8d1d9b7ef6bff94f4accde5b76a05f6 (diff) | |
download | pi-bitcoindev-13b5907844d6526321760f3127e0746f24e6ee1b.tar.gz pi-bitcoindev-13b5907844d6526321760f3127e0746f24e6ee1b.zip |
Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
-rw-r--r-- | d6/a18ab2a0e5df2dbf07bbd01ac8b81f182a19fe | 476 |
1 files changed, 476 insertions, 0 deletions
diff --git a/d6/a18ab2a0e5df2dbf07bbd01ac8b81f182a19fe b/d6/a18ab2a0e5df2dbf07bbd01ac8b81f182a19fe new file mode 100644 index 000000000..bced99908 --- /dev/null +++ b/d6/a18ab2a0e5df2dbf07bbd01ac8b81f182a19fe @@ -0,0 +1,476 @@ +Return-Path: <jaredr26@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 96B2FB9F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Jun 2017 20:14:01 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com + [209.85.217.174]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 422CA18F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 2 Jun 2017 20:14:00 +0000 (UTC) +Received: by mail-ua0-f174.google.com with SMTP id y4so50826893uay.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 02 Jun 2017 13:14:00 -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=3JxS3zhH1MjpRARJyvEcNJoagI8srxTTpkfJtmuEKUA=; + b=MQP7bf948FHRpNC7bHt7h0e+6i3HGuWur+JK8p7EgeVANM9ujDR+jP321D/oHS2ZBe + rK99/FooB5b9bOPuqweVptx9lIIBuGA/gL/98yFZbvk190WG1hx0iHoTKRVCwnM43d6F + LhEiIUIAMbqruPdsFo9s2d4oplQxgUPmw8KLQyemRvMVvLz4u2NaYutj7+MOJAvv5+hP + FFmd0D8NIHYzHTg1BUFBm2ZP/1DhseVH6CWBbqgnFzETbqxMUe4mbxaklJ1qammSk7B/ + HKo/5a4UB2HCgj81njb6I1XEidl62ukmrbkpgZegBVbLUbQ4hq/h3maRDjWtdvx0ncWk + nQ1w== +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=3JxS3zhH1MjpRARJyvEcNJoagI8srxTTpkfJtmuEKUA=; + b=YqISIiXEXDjvAlR2s2jlZcm1jKJ5vF9+syqGF0fB5FVwW8cfy4HdMPfZgBz1Zr5+lJ + cO+/RXNMKjf2W1jp0XQw3uwJxzdqnLdE8hl3mMbLvZB/a9uoIuXWmS+0NYennxMcrDY1 + ngzxl9IoUP1TwPdsDVHSNp3cgjCAIS/R+lYdxlvu8YXR65efLF3762GrjyF0HSEAqyzJ + 0penX3EkKRqqS/Xj1FJSN2K093qp8wyIb/kDUy/HS20caWmtT47zbke8qrNU27xpVf+1 + 4qOArVi9A9IEXks6mkG7W/qXqBfIkycLwG7KYR2L4sOHjPAGj6UpcrRjiHdWtOT6dv78 + 8NaA== +X-Gm-Message-State: AODbwcAvcYLjEqi0wRN/fC4m69xGSiOEcdPHvT4xHd05O369Py1KHyzK + bdxyA/oBei+cXpJVc3Z3+SaLnBrQWw== +X-Received: by 10.159.34.145 with SMTP id 17mr4845216uan.42.1496434439258; + Fri, 02 Jun 2017 13:13:59 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.31.157.215 with HTTP; Fri, 2 Jun 2017 13:13:58 -0700 (PDT) +In-Reply-To: <-r9BgtNAp6_SNVwmPiOER08eMpERnuWioUbNVIQJhyIas29hC5VpWmWP5z4hcC8xtWcAPcFqyxNl9I0Ile6mpY8-ZuHr8jxERXKXKo8WYQE=@protonmail.com> +References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com> + <CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com> + <-r9BgtNAp6_SNVwmPiOER08eMpERnuWioUbNVIQJhyIas29hC5VpWmWP5z4hcC8xtWcAPcFqyxNl9I0Ile6mpY8-ZuHr8jxERXKXKo8WYQE=@protonmail.com> +From: Jared Lee Richardson <jaredr26@gmail.com> +Date: Fri, 2 Jun 2017 13:13:58 -0700 +Message-ID: <CAD1TkXtHmcZHGcOR3RiLhh8orB0L7Tn=yEwPLhrAZyS+qr-GZw@mail.gmail.com> +To: CalvinRechner <calvinrechner@protonmail.com> +Content-Type: multipart/alternative; boundary="94eb2c04c9882e8a590550ffcb86" +X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, + HTML_MESSAGE,RCVD_IN_DNSWL_NONE 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: Fri, 02 Jun 2017 21:26:58 +0000 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal +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: Fri, 02 Jun 2017 20:14:01 -0000 + +--94eb2c04c9882e8a590550ffcb86 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +> The above decision may quickly become very controversial. I don't think +it's what most users had/have in mind when they discuss a "2MB+SegWit" +solution. +> With the current 1MB+SegWit, testing has shown us that normal usage +results in ~2 or 2.1MB blocks. +> I think most users will expect a linear increase when Base Size is +increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. +With normal usage, the expected results would then be ~4 or 4.2MB blocks. + +I think Calvin is correct here, the secondary limit is not what people +anticipated with the segwit + 2mb agreement. It would not kill the +agreement for me, but it might for others. + +What is the justification for the secondary limitation? Is there hard data +to back this? The quadratic hashing problem is frequently brought up, but +that is trivially handled with a hard 1mb transaction limit and on the +other thread there's talk/suggestions of an even lower limit. Are there +any other reasons for this limitation, and is there data to justify those +concerns? If not, this should be left out in favor of a transaction size +limit. If so, hard data would go a long way to dealing with the conversy +this will create. + + +> Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation of segwit deployment= +=E2=80=9D[3] is included +to: +> > cause the existing "segwit" deployment to activate without needing to +release a new deployment. +> Both of the aforementioned activation options (=E2=80=9Cfast-activation= +=E2=80=9D and +=E2=80=9Cflag-day activation=E2=80=9D) serve to prevent unnecessary delays = +in the network +upgrade process, addressing a common criticism of the Scaling Agreement and +providing an opportunity for cooperation and unity instead. + +This is likely to cause more controversy and unfortunately has the tightest +timelines. Unlike the SW2mb working group's timelines, a hard-coded +timeline couldn't be changed with mutual agreement from the signers. + +Given the chance of bit1 accidental activation without clear signaling for +the required bit4 2mb hard fork, I don't think the fair or acceptable +tradeoff is for flag day to require bit1 signaling only. *Flag day should +be modified to accept either bit1 signaling, OR to accept bit4 signaling IF +the 80% threshold hasn't been met.* In this way the anti-segwit working +group members are not in danger of an activated bit1 segwit without also +getting their portion of the compromise, the bit4 signaled HF. If flag day +accepts bit4 OR bit1, AND bit4 requires both bit1 and bit4 once 80% is +reached, flag day is nearly guaranteed to get its stated desire within 1750 +blocks (bit4 accepted until block 800; bit4+bit1 signaled afterwards until +95%), but without the chance that the WG signers won't get what they agreed +to. + +*That seems like a minor compromise for BIP148. Thoughts on this change to +flag day / BIP148?* + +In addition, the aggressiveness of the timelines and the complexity of the +merged COOP proposal may require the BIP148 flag day to be pushed back. I +would think some day in September is achievable, but I'm not sure if August +1st will be. + +Jared + + +On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> In principle, there is complete flexibility when it comes to the specific +> consensus details of the hard fork. One common suggestion has been to pha= +se +> in a gradual blocksize increase beyond the initial 2MB cap included in +> Luke-Jr's proposal (a la BIP103); this would certainly be a welcome +> inclusion in the Omnibus Proposal, provided that is what we want. The +> reasoning behind incorporating Luke-Jr's 2MB limit and discount-rebalanci= +ng +> was to satisfy the conditions of the Scaling Agreement while ensuring +> maximum safety, minimum code discrepancies, and minimum controversy among +> the community; these priorities seem imperative, considering the extreme +> timeline constraints we are working under and the goals of the proposal. = +To +> put it more simply, the intent of the proposal was to serve as a template +> for the minimum viable fork that can achieve true consensus. A gradual +> increase to a larger size cap, especially if it were reasonably +> conservative, would be wholly in accordance with the Omnibus Proposal if +> that is what it takes to achieve the cooperation between community, +> industry, and developers in this critical moment of Bitcoin's history. +> +> +> The purpose of the Omnibus Proposal is singlefold: to achieve the goals o= +f +> the Consensus 2017 Scaling Agreement in the most maximally-compatible way= +. +> We can minimize disruption and loss potential all around by solving these +> problems in a compatibility-oriented manner. It is possible to fulfill bo= +th +> the letter and the spirit of the Scaling Agreement, to the complete +> satisfaction of all involved, while preventing chain-split risks in the +> meantime. +> +> +> There is no justification for incompatibility with existing deployment +> approaches, when there is the possibility to work together towards our +> mutual goals instead. The most rational option is to join forces and avoi= +d +> any chain-split potential for as long as possible. Under the Omnibus +> Proposal, once SegWit is activated, the terms of the hard fork are locked +> in automatically, set to activate 6 months later. The proposal guarantees +> that a successful SegWit activation is followed by a hard fork. Beyond +> enforcing the hard fork rules beginning at block height HardForkHeight, t= +he +> Omnibus Proposal simply represents compatibility with the existing +> SegWit-activation deployment approaches. +> +> +> By committing to this proposal, we can ensure unity, at least for now. +> There do not appear to be any arguments to the contrary. Why squander thi= +s +> opportunity for consensus and harmony? We can leverage the momentum of +> several disparate movements, and perhaps enjoy some much-needed social +> solidarity. In a way, everyone can get what they want, and through +> cooperation, we avoid the risk of a costly fracture. +> +> +> The Segwit2x Team has begun work on an implementation of the Consensus +> Scaling Agreement, their operational timeline including the publication o= +f +> a BIP on June 16, 2017.[1] I call upon the developers and maintainers of +> this initiative to consider and honor the Omnibus Proposal, extended or +> modified as needed, as the guiding approach to your development effort. +> Almost every component of the code exists, in some form or fashion, in th= +e +> various constituent proposals' reference implementations, most of which +> have already undergone a significant degree of peer review. +> +> +> We cannot afford to delay, nor to reimplement; the launch timeline is +> aggressively optimistic as it is. The quickest and safest approach to +> achieving the goals set forth at Consensus 2017 is to leverage the existi= +ng +> tools and proposals for the job. We can solve our problems properly, +> cooperatively. +> +> +> I humbly ask that Jeff Garzik, Barry Silbert, Mike Belshe, and all of the +> other wonderful, intelligent collaborators on this project step forward a= +nd +> support the cooperative, compatibility-oriented approach of the Omnibus +> Proposal. +> +> +> This is the best way to maximize value for everyone. We have a real +> opportunity to collaborate and work together on the same team. The Omnibu= +s +> Proposal, designed in exact accordance with a powerful industry agreement +> and incorporating the feedback and suggestions provided from within both +> the developer community and the community-at-large, stands the best chanc= +e +> of uniting everyone under a common front. +> +> +> Please, for the love of Bitcoin, let us do our best to cooperate. +> +> +> +> [1] https://imgur.com/a/a2oPs +> +> +> Sent with ProtonMail <https://protonmail.com> Secure Email. +> +> -------- Original Message -------- +> Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal +> Local Time: May 29, 2017 6:49 PM +> UTC Time: May 29, 2017 11:49 PM +> From: opetruzel@gmail.com +> To: CalvinRechner <calvinrechner@protonmail.com> +> Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +> +> >>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... Legacy +> Bitcoin transactions are given the witness discount, and a block size lim= +it +> of 2 MB is imposed.<< +> +> +> The above decision may quickly become very controversial. I don't think i= +t's +> what most users had/have in mind when they discuss a "2MB+SegWit" solutio= +n. +> +> With the current 1MB+SegWit, testing has shown us that normal usage +> results in ~2 or 2.1MB blocks. +> +> I think most users will expect a linear increase when Base Size is +> increased to 2000000 bytes and Total Weight is increased to 8000000 bytes= +. +> With normal usage, the expected results would then be ~4 or 4.2MB blocks. +> +> Am I missing something here, or does Luke's suggested 2MB cap completely +> nullify that expected linear increase? If so, why? What's the logic behin= +d +> this decision? +> +> I'd love to be armed with a good answer should my colleagues ask me the +> same obvious question, so thank you ahead of time! +> +> Respectfully, +> Oliver Petruzel +> +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--94eb2c04c9882e8a590550ffcb86 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">> The above decision may quickly become very controvers= +ial. I don't think it's what most users had/have in mind when they = +discuss a "2MB+SegWit" solution.<br>> With the current 1MB+Seg= +Wit, testing has shown us that normal usage results in ~2 or 2.1MB blocks.<= +br>> I think most users will expect a linear increase when Base Size is = +increased to 2000000 bytes and Total Weight is increased to 8000000 bytes. = +With normal usage, the expected results would then be ~4 or 4.2MB blocks.<b= +r><br>I think Calvin is correct here, the secondary limit is not what peopl= +e anticipated with the segwit + 2mb agreement.=C2=A0 It would not kill the = +agreement for me, but it might for others.<br><br>What is the justification= + for the secondary limitation?=C2=A0 Is there hard data to back this?=C2=A0= + The quadratic hashing problem is frequently brought up, but that is trivia= +lly handled with a hard 1mb transaction limit and on the other thread there= +'s talk/suggestions of an even lower limit.=C2=A0 Are there any other r= +easons for this limitation, and is there data to justify those concerns?=C2= +=A0 If not, this should be left out in favor of a transaction size limit.= +=C2=A0 If so, hard data would go a long way to dealing with the conversy th= +is will create.<br><br><br>> Shaolin Fry=E2=80=99s =E2=80=9CMandatory ac= +tivation of segwit deployment=E2=80=9D[3] is included to:<br>> > caus= +e the existing "segwit" deployment to activate without needing to= + release a new deployment.<br>> Both of the aforementioned activation op= +tions (=E2=80=9Cfast-activation=E2=80=9D and =E2=80=9Cflag-day activation= +=E2=80=9D) serve to prevent unnecessary delays in the network upgrade proce= +ss, addressing a common criticism of the Scaling Agreement and providing an= + opportunity for cooperation and unity instead.<br><br>This is likely to ca= +use more controversy and unfortunately has the tightest timelines.=C2=A0 Un= +like the SW2mb working group's timelines, a hard-coded timeline couldn&= +#39;t be changed with mutual agreement from the signers.<br><br>Given the c= +hance of bit1 accidental activation without clear signaling for the require= +d bit4 2mb hard fork, I don't think the fair or acceptable tradeoff is = +for flag day to require bit1 signaling only. =C2=A0<u><b>Flag day should be= + modified to accept either bit1 signaling, OR to accept bit4 signaling IF t= +he 80% threshold hasn't been met</b>.</u> =C2=A0In this way the anti-se= +gwit working group members are not in danger of an activated bit1 segwit wi= +thout also getting their portion of the compromise, the bit4 signaled HF.= +=C2=A0 If flag day accepts bit4 OR bit1, AND bit4 requires both bit1 and bi= +t4 once 80% is reached, flag day is nearly guaranteed to get its stated des= +ire within 1750 blocks (bit4 accepted until block 800; bit4+bit1 signaled a= +fterwards until 95%), but without the chance that the WG signers won't = +get what they agreed to.<div><br><b>That seems like a minor compromise for = +BIP148.=C2=A0 Thoughts on this change to flag day / BIP148?</b><br><br></di= +v><div>In addition, the aggressiveness of the timelines and the complexity = +of the merged COOP proposal may require the BIP148 flag day to be pushed ba= +ck.=C2=A0 I would think some day in September is achievable, but I'm no= +t sure if August 1st will be.</div><div><br></div><div><div>Jared<br><br></= +div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O= +n Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitcoin-dev <span dir=3D"= +ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= +"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><bl= +ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= +ccc solid;padding-left:1ex"><div>In principle, there is complete flexibilit= +y when it comes to the specific consensus details of the hard fork. One com= +mon suggestion has been to phase in a gradual blocksize increase beyond the= + initial 2MB cap included in Luke-Jr's proposal (a la BIP103); this wou= +ld certainly be a welcome inclusion in the Omnibus Proposal, provided that = +is what we want. The reasoning behind incorporating Luke-Jr's 2MB limit= + and discount-rebalancing was to satisfy the conditions of the Scaling Agre= +ement while ensuring maximum safety, minimum code discrepancies, and minimu= +m controversy among the community; these priorities seem imperative, consid= +ering the extreme timeline constraints we are working under and the goals o= +f the proposal. To put it more simply, the intent of the proposal was to se= +rve as a template for the minimum viable fork that can achieve true consens= +us. A gradual increase to a larger size cap, especially if it were reasonab= +ly conservative, would be wholly in accordance with the Omnibus Proposal if= + that is what it takes to achieve the cooperation between community, indust= +ry, and developers in this critical moment of Bitcoin's history.<br></d= +iv><div><br></div><div><br></div><div>The purpose of the Omnibus Proposal i= +s singlefold: to achieve the goals of the Consensus 2017 Scaling Agreement = +in the most maximally-compatible way. We can minimize disruption and loss p= +otential all around by solving these problems in a compatibility-oriented m= +anner. It is possible to fulfill both the letter and the spirit of the Scal= +ing Agreement, to the complete satisfaction of all involved, while preventi= +ng chain-split risks in the meantime.<br></div><div><br></div><div><br></di= +v><div>There is no justification for incompatibility with existing deployme= +nt approaches, when there is the possibility to work together towards our m= +utual goals instead. The most rational option is to join forces and avoid a= +ny chain-split potential for as long as possible. Under the Omnibus Proposa= +l, once SegWit is activated, the terms of the hard fork are locked in autom= +atically, set to activate 6 months later. The proposal guarantees that a su= +ccessful SegWit activation is followed by a hard fork. Beyond enforcing the= + hard fork rules beginning at block height HardForkHeight, the Omnibus Prop= +osal simply represents compatibility with the existing SegWit-activation de= +ployment approaches.<br></div><div><br></div><div><br></div><div>By committ= +ing to this proposal, we can ensure unity, at least for now. There do not a= +ppear to be any arguments to the contrary. Why squander this opportunity fo= +r consensus and harmony? We can leverage the momentum of several disparate = +movements, and perhaps enjoy some much-needed social solidarity. In a way, = +everyone can get what they want, and through cooperation, we avoid the risk= + of a costly fracture.<br></div><div><br></div><div><br></div><div>The Segw= +it2x Team has begun work on an implementation of the Consensus Scaling Agre= +ement, their operational timeline including the publication of a BIP on Jun= +e 16, 2017.[1] I call upon the developers and maintainers of this initiativ= +e to consider and honor the Omnibus Proposal, extended or modified as neede= +d, as the guiding approach to your development effort. Almost every compone= +nt of the code exists, in some form or fashion, in the various constituent = +proposals' reference implementations, most of which have already underg= +one a significant degree of peer review.<br></div><div><br></div><div><br><= +/div><div>We cannot afford to delay, nor to reimplement; the launch timelin= +e is aggressively optimistic as it is. The quickest and safest approach to = +achieving the goals set forth at Consensus 2017 is to leverage the existing= + tools and proposals for the job. We can solve our problems properly, coope= +ratively.<br></div><div><br></div><div><br></div><div>I humbly ask that Jef= +f Garzik, Barry Silbert, Mike Belshe, and all of the other wonderful, intel= +ligent collaborators on this project step forward and support the cooperati= +ve, compatibility-oriented approach of the Omnibus Proposal.<br></div><div>= +<br></div><div><br></div><div>This is the best way to maximize value for ev= +eryone. We have a real opportunity to collaborate and work together on the = +same team. The Omnibus Proposal, designed in exact accordance with a powerf= +ul industry agreement and incorporating the feedback and suggestions provid= +ed from within both the developer community and the community-at-large, sta= +nds the best chance of uniting everyone under a common front.<br></div><div= +><br></div><div><br></div><div>Please, for the love of Bitcoin, let us do o= +ur best to cooperate.<br></div><div><br></div><div><br></div><div><br></div= +><div>[1] <a href=3D"https://imgur.com/a/a2oPs" target=3D"_blank">https://i= +mgur.com/a/a2oPs</a><br></div><div><br></div><div class=3D"m_-8623242554324= +460992protonmail_signature_block"><div class=3D"m_-8623242554324460992proto= +nmail_signature_block-user m_-8623242554324460992protonmail_signature_block= +-empty"><br></div><div class=3D"m_-8623242554324460992protonmail_signature_= +block-proton">Sent with <a href=3D"https://protonmail.com" target=3D"_blank= +">ProtonMail</a> Secure Email.<br></div></div><div class=3D"HOEnZb"><div cl= +ass=3D"h5"><div><br></div><blockquote class=3D"m_-8623242554324460992proton= +mail_quote" type=3D"cite"><div>-------- Original Message --------<br></div>= +<div>Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal<br>= +</div><div>Local Time: May 29, 2017 6:49 PM<br></div><div>UTC Time: May 29,= + 2017 11:49 PM<br></div><div>From: <a href=3D"mailto:opetruzel@gmail.com" t= +arget=3D"_blank">opetruzel@gmail.com</a><br></div><div>To: CalvinRechner &l= +t;<a href=3D"mailto:calvinrechner@protonmail.com" target=3D"_blank">calvinr= +echner@protonmail.com</a>><br></div><div>Bitcoin Dev <<a href=3D"mail= +to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis= +ts.<wbr>linuxfoundation.org</a>><br></div><div><br></div><div dir=3D"aut= +o"><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px"><s= +pan class=3D"m_-8623242554324460992size" style=3D"font-size:18.048px">>&= +gt;if the community wishes to adopt (by unanimous consensus) a 2 MB block s= +ize hardfork, this is probably the best way to do it right now... Legacy Bi= +tcoin transactions are given the witness discount, and a block size limit o= +f 2 MB is imposed.<<</span><br></div><div dir=3D"auto" style=3D"font-= +family:sans-serif;font-size:18.048px"><span class=3D"m_-8623242554324460992= +size" style=3D"font-size:18.048px"></span><br></div><div dir=3D"auto" style= +=3D"font-family:sans-serif;font-size:18.048px"><span class=3D"m_-8623242554= +324460992size" style=3D"font-size:18.048px"></span><br></div><div dir=3D"au= +to" style=3D"font-family:sans-serif;font-size:18.048px">The above decision = +may quickly become very controversial. I don't think<span class=3D"m_-8= +623242554324460992size" style=3D"font-size:18.048px">=C2=A0it's what mo= +st users had/have in mind when they discuss a "2MB+SegWit" soluti= +on.=C2=A0</span><br></div><div dir=3D"auto" style=3D"font-family:sans-serif= +;font-size:18.048px"><span class=3D"m_-8623242554324460992size" style=3D"fo= +nt-size:18.048px"></span><br></div><div dir=3D"auto" style=3D"font-family:s= +ans-serif;font-size:18.048px">With the current 1MB+SegWit, testing has show= +n us that normal usage results in ~2 or 2.1MB blocks.<br></div><div dir=3D"= +auto" style=3D"font-family:sans-serif;font-size:18.048px"><br></div><div di= +r=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px">I think most= + users will expect a linear increase when Base Size is increased to 2000000= + bytes and Total Weight is increased to 8000000 bytes. With normal usage, t= +he expected results would then be ~4 or 4.2MB blocks.<br></div><div dir=3D"= +auto" style=3D"font-family:sans-serif;font-size:18.048px"><br></div><div di= +r=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px">Am I missing= + something here, or does Luke's suggested 2MB cap completely nullify th= +at expected linear increase? If so, why? What's the logic behind this d= +ecision?<br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-si= +ze:18.048px"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif;fo= +nt-size:18.048px">I'd love to be armed with a good answer should my col= +leagues ask me the same obvious question, so thank you ahead of time!<br></= +div><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px"><= +br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:18.048= +px">Respectfully,<br></div><div dir=3D"auto" style=3D"font-family:sans-seri= +f;font-size:18.048px">Oliver Petruzel<br></div><div dir=3D"auto" style=3D"f= +ont-family:sans-serif;font-size:18.048px"><br></div><div dir=3D"auto" style= +=3D"font-family:sans-serif;font-size:18.048px"><br></div></div></blockquote= +><div><br></div></div></div><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> +<br></blockquote></div><br></div> + +--94eb2c04c9882e8a590550ffcb86-- + |