summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJared Lee Richardson <jaredr26@gmail.com>2017-06-02 13:13:58 -0700
committerbitcoindev <bitcoindev@gnusha.org>2017-06-02 20:14:01 +0000
commit13b5907844d6526321760f3127e0746f24e6ee1b (patch)
treea28efb0dc265a7260e150b7407102a93380fd008
parent26f8412bf8d1d9b7ef6bff94f4accde5b76a05f6 (diff)
downloadpi-bitcoindev-13b5907844d6526321760f3127e0746f24e6ee1b.tar.gz
pi-bitcoindev-13b5907844d6526321760f3127e0746f24e6ee1b.zip
Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
-rw-r--r--d6/a18ab2a0e5df2dbf07bbd01ac8b81f182a19fe476
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">&gt; The above decision may quickly become very controvers=
+ial. I don&#39;t think it&#39;s what most users had/have in mind when they =
+discuss a &quot;2MB+SegWit&quot; solution.<br>&gt; With the current 1MB+Seg=
+Wit, testing has shown us that normal usage results in ~2 or 2.1MB blocks.<=
+br>&gt; 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=
+&#39;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>&gt; Shaolin Fry=E2=80=99s =E2=80=9CMandatory ac=
+tivation of segwit deployment=E2=80=9D[3] is included to:<br>&gt; &gt; caus=
+e the existing &quot;segwit&quot; deployment to activate without needing to=
+ release a new deployment.<br>&gt; 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&#39;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&#39;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&#39;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&#39;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&#39;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">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
+"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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&#39;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&#39;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&#39;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&#39; 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>&gt;<br></div><div>Bitcoin Dev &lt;<a href=3D"mail=
+to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
+ts.<wbr>linuxfoundation.org</a>&gt;<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;&=
+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.&lt;&lt;</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&#39;t think<span class=3D"m_-8=
+623242554324460992size" style=3D"font-size:18.048px">=C2=A0it&#39;s what mo=
+st users had/have in mind when they discuss a &quot;2MB+SegWit&quot; 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&#39;s suggested 2MB cap completely nullify th=
+at expected linear increase? If so, why? What&#39;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&#39;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--
+