path: root/0a/9885522ecee92689c139e15583f9fe82fbd1ed

Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E424B8E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 21:57:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
	[209.85.220.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9827E13D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 21:57:53 +0000 (UTC)
Received: by mail-qk0-f169.google.com with SMTP id y201so69616933qka.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 02 Jun 2017 14:57:53 -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=68EpzLGjCWBJ7B6eBcrCLNDXBjpHXyUebi7J4+C++9E=;
	b=Wzk4Gx9aoghULKNH7MJB2s/9jIbJzMxmszhDPpRnKgcFjzps2jgSNXZH53jvUTwAnF
	H4zlqStRGSsphsf+5oo02UYOR0vryAvpznlCw7huDN9ELw58VXXbqcBMSzBeZlMPkFK4
	Hl8mbSFpfO2ZPmrjfAq8rMT572HFBQ4plwtQ07Fs+8WpmkOMlZua/UXpt/8gVy/2FZrM
	F/B9jPCqbDj2VwhIwKYTcbV5Yud2shP6u+hiK/VL2lVmQH8V2OVG4sY1jm3fJhBja3K5
	Hvr2/qZU1TbObLhnKve+OMZ7Dgb+R1Y9jvb+xz51Yru6tAlt4W/O0aopsLvy6qaoOXkd
	4AQA==
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=68EpzLGjCWBJ7B6eBcrCLNDXBjpHXyUebi7J4+C++9E=;
	b=fXwgDm9tTwR+TRKewRfSROPwPfT9DyCAo7JXWuokpzzZcXopsFLVhXp8taR/yNYCkM
	07eYvk8nnUIwsAWI9MokvKg6kUJQPommAAQI/fNBq7R/QY0m1VNcQBciv+I5TH8ceEjK
	ex5PtpPLm+/fvQjF6YxJtGkbQYQSrN2yMJPrDcSEyN09tdSfalrYw2zPpDaJCiZ3oAmI
	YduG8R4y56O0LxkbsTp5aXBtnhvjWyo0JNJTRLxDP9lQK8GktW6nurDnESAF5o8sp4FL
	d09xgseDNJku5H4pNWGkcKXvoltTm7lxUp4DCCI6Up+LNiB/xugcuup5C2W+BQZuHBRy
	4+GQ==
X-Gm-Message-State: AODbwcA51eKhnxbKujL+x7JvIAYMGZTx+v0o9ff8rfxjaOMuBYg69zmk
	cQlUe0kJUrTz7rCZY9HCGQ8366R4Rsom
X-Received: by 10.55.186.132 with SMTP id k126mr11456891qkf.243.1496440672786; 
	Fri, 02 Jun 2017 14:57:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.150.249 with HTTP; Fri, 2 Jun 2017 14:57:12 -0700 (PDT)
In-Reply-To: <CAD1TkXtHmcZHGcOR3RiLhh8orB0L7Tn=yEwPLhrAZyS+qr-GZw@mail.gmail.com>
References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
	<CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com>
	<-r9BgtNAp6_SNVwmPiOER08eMpERnuWioUbNVIQJhyIas29hC5VpWmWP5z4hcC8xtWcAPcFqyxNl9I0Ile6mpY8-ZuHr8jxERXKXKo8WYQE=@protonmail.com>
	<CAD1TkXtHmcZHGcOR3RiLhh8orB0L7Tn=yEwPLhrAZyS+qr-GZw@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 2 Jun 2017 17:57:12 -0400
Message-ID: <CAKzdR-om+A1wrPSPTNT6AqtZjEw3hqjWKjgDoAQwggDYF3PH+A@mail.gmail.com>
To: Jared Lee Richardson <jaredr26@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c043626ba9e4c0551013eee"
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	CalvinRechner <calvinrechner@protonmail.com>
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 21:57:55 -0000

--94eb2c043626ba9e4c0551013eee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I don't see LukeJr 2MB limit to be compatible with the NY agreement. For
the rest, seems fine for me.



On Fri, Jun 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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 u=
p,
> but that is trivially handled with a hard 1mb transaction limit and on th=
e
> 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 deploymen=
t=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 delay=
s in the network
> upgrade process, addressing a common criticism of the Scaling Agreement a=
nd
> 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 fo=
r
> 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 bi=
t1
> 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+bit=
1
> signaled afterwards until 95%), but without the chance that the WG signer=
s
> 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 th=
e
> 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 Augu=
st
> 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 specifi=
c
>> consensus details of the hard fork. One common suggestion has been to ph=
ase
>> 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-rebalanc=
ing
>> was to satisfy the conditions of the Scaling Agreement while ensuring
>> maximum safety, minimum code discrepancies, and minimum controversy amon=
g
>> 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 templat=
e
>> 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
>> of 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 both the letter and the spirit of the Scaling Agreement, to the
>> complete satisfaction of all involved, while preventing chain-split risk=
s
>> 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 avo=
id
>> any chain-split potential for as long as possible. Under the Omnibus
>> Proposal, once SegWit is activated, the terms of the hard fork are locke=
d
>> in automatically, set to activate 6 months later. The proposal guarantee=
s
>> that a successful SegWit activation is followed by a hard fork. Beyond
>> enforcing the hard fork rules beginning at block height HardForkHeight, =
the
>> 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 th=
is
>> 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 =
of
>> 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 t=
he
>> 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 exist=
ing
>> 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 th=
e
>> other wonderful, intelligent collaborators on this project step forward =
and
>> 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 Omnib=
us
>> Proposal, designed in exact accordance with a powerful industry agreemen=
t
>> and incorporating the feedback and suggestions provided from within both
>> the developer community and the community-at-large, stands the best chan=
ce
>> 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... Legac=
y
>> Bitcoin transactions are given the witness discount, and a block size li=
mit
>> of 2 MB is imposed.<<
>>
>>
>> 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" soluti=
on.
>>
>> 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 byte=
s.
>> 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 behi=
nd
>> 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
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c043626ba9e4c0551013eee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I don&#39;t see LukeJr 2MB limit to be compatible with the=
 NY agreement. For the rest, seems fine for me.<div><br><div><br></div></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, J=
un 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">&gt; The above =
decision may quickly become very controversial. 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+SegWit, testing has shown us that n=
ormal 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 T=
otal Weight is increased to 8000000 bytes. With normal usage, the expected =
results would then be ~4 or 4.2MB blocks.<br><br></span>I think Calvin is c=
orrect here, the secondary limit is not what people anticipated with the se=
gwit + 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 limita=
tion?=C2=A0 Is there hard data to back this?=C2=A0 The quadratic hashing pr=
oblem is frequently brought up, but that is trivially handled with a hard 1=
mb transaction limit and on the other thread there&#39;s talk/suggestions o=
f an even lower limit.=C2=A0 Are there any other reasons for this limitatio=
n, and is there data to justify those concerns?=C2=A0 If not, this should b=
e left out in favor of a transaction size limit.=C2=A0 If so, hard data wou=
ld go a long way to dealing with the conversy this will create.<span class=
=3D""><br><br><br>&gt; Shaolin Fry=E2=80=99s =E2=80=9CMandatory activation =
of segwit deployment=E2=80=9D[3] is included to:<br>&gt; &gt; cause the exi=
sting &quot;segwit&quot; deployment to activate without needing to release =
a new deployment.<br>&gt; 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, addre=
ssing a common criticism of the Scaling Agreement and providing an opportun=
ity for cooperation and unity instead.<br><br></span>This is likely to caus=
e more controversy and unfortunately has the tightest timelines.=C2=A0 Unli=
ke the SW2mb working group&#39;s timelines, a hard-coded timeline couldn&#3=
9;t be changed with mutual agreement from the signers.<br><br>Given the cha=
nce of bit1 accidental activation without clear signaling for the required =
bit4 2mb hard fork, I don&#39;t think the fair or acceptable tradeoff is fo=
r flag day to require bit1 signaling only. =C2=A0<u><b>Flag day should be m=
odified to accept either bit1 signaling, OR to accept bit4 signaling IF the=
 80% threshold hasn&#39;t been met</b>.</u> =C2=A0In this way the anti-segw=
it working group members are not in danger of an activated bit1 segwit with=
out 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 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 afte=
rwards 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 BIP=
148.=C2=A0 Thoughts on this change to flag day / BIP148?</b><br><br></div><=
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 back.=
=C2=A0 I would think some day in September is achievable, but I&#39;m not s=
ure 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"><div=
><div class=3D"h5">On Tue, May 30, 2017 at 3:20 PM, CalvinRechner via bitco=
in-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>=
&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><di=
v class=3D"h5"><div>In principle, there is complete flexibility when it com=
es to the specific consensus details of the hard fork. One common suggestio=
n 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 would certainly =
be a welcome inclusion in the Omnibus Proposal, provided that is what we wa=
nt. The reasoning behind incorporating Luke-Jr&#39;s 2MB limit and discount=
-rebalancing was to satisfy the conditions of the Scaling Agreement while e=
nsuring maximum safety, minimum code discrepancies, and minimum controversy=
 among the community; these priorities seem imperative, considering the ext=
reme timeline constraints we are working under and the goals of the proposa=
l. To put it more simply, the intent of the proposal was to serve as a temp=
late for the minimum viable fork that can achieve true consensus. A gradual=
 increase to a larger size cap, especially if it were reasonably conservati=
ve, would be wholly in accordance with the Omnibus Proposal if that is what=
 it takes to achieve the cooperation between community, industry, and devel=
opers in this critical moment of Bitcoin&#39;s history.<br></div><div><br><=
/div><div><br></div><div>The purpose of the Omnibus Proposal is singlefold:=
 to achieve the goals of the Consensus 2017 Scaling Agreement in the most m=
aximally-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 both the letter and the spirit of the Scaling Agreement=
, to the complete satisfaction of all involved, while preventing chain-spli=
t risks in the meantime.<br></div><div><br></div><div><br></div><div>There =
is no justification for incompatibility with existing deployment approaches=
, when there is the possibility to work together towards our mutual goals i=
nstead. The most rational option is to join forces and avoid any chain-spli=
t potential for as long as possible. Under the Omnibus Proposal, once SegWi=
t is activated, the terms of the hard fork are locked in automatically, set=
 to activate 6 months later. The proposal guarantees that a successful SegW=
it activation is followed by a hard fork. Beyond enforcing the hard fork ru=
les beginning at block height HardForkHeight, the Omnibus Proposal simply r=
epresents compatibility with the existing SegWit-activation deployment appr=
oaches.<br></div><div><br></div><div><br></div><div>By committing to this p=
roposal, we can ensure unity, at least for now. There do not appear to be a=
ny arguments to the contrary. Why squander this opportunity for consensus a=
nd harmony? We can leverage the momentum of several disparate movements, an=
d 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 Segwit2x Team has=
 begun work on an implementation of the Consensus Scaling Agreement, their =
operational timeline including the publication of 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 gui=
ding approach to your development effort. Almost every component of the cod=
e exists, in some form or fashion, in the various constituent proposals&#39=
; reference implementations, most of which have already undergone a signifi=
cant degree of peer review.<br></div><div><br></div><div><br></div><div>We =
cannot afford to delay, nor to reimplement; the launch timeline is aggressi=
vely 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 pr=
oposals for the job. We can solve our problems properly, cooperatively.<br>=
</div><div><br></div><div><br></div><div>I humbly ask that Jeff Garzik, Bar=
ry Silbert, Mike Belshe, and all of the other wonderful, intelligent collab=
orators on this project step forward and support the cooperative, compatibi=
lity-oriented approach of the Omnibus Proposal.<br></div><div><br></div><di=
v><br></div><div>This is the best way to maximize value for everyone. We ha=
ve a real opportunity to collaborate and work together on the same team. Th=
e Omnibus Proposal, designed in exact accordance with a powerful industry a=
greement and incorporating the feedback and suggestions provided from withi=
n both the developer community and the community-at-large, stands the best =
chance of uniting everyone under a common front.<br></div><div><br></div><d=
iv><br></div><div>Please, for the love of Bitcoin, let us do our best to co=
operate.<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://imgur.com/a/a2=
oPs</a><br></div><div><br></div><div class=3D"m_-6014941095577769266m_-8623=
242554324460992protonmail_signature_block"><div class=3D"m_-601494109557776=
9266m_-8623242554324460992protonmail_signature_block-user m_-60149410955777=
69266m_-8623242554324460992protonmail_signature_block-empty"><br></div><div=
 class=3D"m_-6014941095577769266m_-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"m_-601494109557=
7769266HOEnZb"><div class=3D"m_-6014941095577769266h5"><div><br></div><bloc=
kquote class=3D"m_-6014941095577769266m_-8623242554324460992protonmail_quot=
e" type=3D"cite"><div>-------- Original Message --------<br></div><div>Subj=
ect: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal<br></div><di=
v>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" target=3D"=
_blank">opetruzel@gmail.com</a><br></div><div>To: CalvinRechner &lt;<a href=
=3D"mailto:calvinrechner@protonmail.com" target=3D"_blank">calvinrechner@pr=
otonmail.com</a>&gt;<br></div><div>Bitcoin Dev &lt;<a href=3D"mailto:bitcoi=
n-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxf=
ounda<wbr>tion.org</a>&gt;<br></div><div><br></div><div dir=3D"auto"><div d=
ir=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px"><span class=
=3D"m_-6014941095577769266m_-8623242554324460992size" style=3D"font-size:18=
.048px">&gt;&gt;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 limit of 2 MB is imposed.&lt;&lt;</span><br></div><div dir=3D"auto" s=
tyle=3D"font-family:sans-serif;font-size:18.048px"><span class=3D"m_-601494=
1095577769266m_-8623242554324460992size" style=3D"font-size:18.048px"></spa=
n><br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:18.=
048px"><span class=3D"m_-6014941095577769266m_-8623242554324460992size" sty=
le=3D"font-size:18.048px"></span><br></div><div dir=3D"auto" 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_-6014941095577769266=
m_-8623242554324460992size" style=3D"font-size:18.048px">=C2=A0it&#39;s wha=
t most users had/have in mind when they discuss a &quot;2MB+SegWit&quot; so=
lution.=C2=A0</span><br></div><div dir=3D"auto" style=3D"font-family:sans-s=
erif;font-size:18.048px"><span class=3D"m_-6014941095577769266m_-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">With the current 1M=
B+SegWit, testing has shown us that normal usage results in ~2 or 2.1MB blo=
cks.<br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:1=
8.048px"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-s=
ize:18.048px">I think most users will expect a linear increase when Base Si=
ze is increased to 2000000 bytes and Total Weight is increased to 8000000 b=
ytes. With normal usage, the expected results would then be ~4 or 4.2MB blo=
cks.<br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:1=
8.048px"><br></div><div dir=3D"auto" style=3D"font-family:sans-serif;font-s=
ize:18.048px">Am I missing something here, or does Luke&#39;s suggested 2MB=
 cap completely nullify that expected linear increase? If so, why? What&#39=
;s the logic behind this decision?<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.048px">I&#39;d love to be armed with a=
 good answer should my colleagues ask me the same obvious question, so than=
k you ahead of time!<br></div><div dir=3D"auto" style=3D"font-family:sans-s=
erif;font-size:18.048px"><br></div><div dir=3D"auto" style=3D"font-family:s=
ans-serif;font-size:18.048px">Respectfully,<br></div><div dir=3D"auto" styl=
e=3D"font-family:sans-serif;font-size:18.048px">Oliver Petruzel<br></div><d=
iv dir=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px"><br></d=
iv><div dir=3D"auto" style=3D"font-family:sans-serif;font-size:18.048px"><b=
r></div></div></blockquote><div><br></div></div></div><br></div></div><span=
 class=3D"">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></span></blockquote></div><br></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>

--94eb2c043626ba9e4c0551013eee--