path: root/d6/a18ab2a0e5df2dbf07bbd01ac8b81f182a19fe

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--