path: root/b0/09f905fb9ccac55a2069e160d455a7057e0641

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 5AEF8A5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 20:59:38 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com
	[209.85.220.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 857642C6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Apr 2017 20:59:37 +0000 (UTC)
Received: by mail-qk0-f170.google.com with SMTP id p22so48293164qka.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Apr 2017 13:59:37 -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=Qb2ej5Z//XzBpBR+5nCpJQNSbyDfIjiaOMYxq5YKjNE=;
	b=JTG9ia/ZKDSy5rvrGN8jsr29IYuYxYMdMWlphVXJS1oHVQQnhUjvCJ2U/InNjvp6dN
	wmHRTv7gsIiYlc6AUbimUTQr+uM6Uu3wKeaH9eaEAYq125xuSde+NzgmSvXZusf3FEQ2
	7jJMgtRvhAf0I7nYZkkcXN/frTgNT6/+wTid++SZzhTuf+4al/dJuA478a7L5LUmYYVu
	WOzpdlawQIiwGaV5hAUrYv0jTRl1hUvEuBuKiwxorhZXmvrqK3puLezwq/b1UuJA6gcE
	FSvNMbyoL8KoqtUewR2GQqkpyBaMqy9gzFGxewPkxaZRFKFaAO5I+e6jhpZVkLOMGDnX
	K20A==
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=Qb2ej5Z//XzBpBR+5nCpJQNSbyDfIjiaOMYxq5YKjNE=;
	b=OFU9OB6xkW/s2wGhV3Yp29mfLtHVMTbtKdR9xwq6YT1b8z78kV3vVrCYXR6teOFHg7
	ZCXjUdEP6SPiHzSfmt6X6PZrU9xehlQNm+Nu18ZsDOWQWRiRzDWBvgiXUSWdTH16msi+
	ra79v7Tj/yUj+PLE0CLDd8wBffGA0cb0dSIkGDYMWcEwvZM8YcEygx1NOhh0m2roXw0m
	aqHb/lux3OLsxuajRMLMiHaHqhfoP5LJLMmVssqCfWz47ghlT4o+uN1Uj7g9IK/2EbVB
	r7PxHs/3b3AdOsBOmUi49ryUe5POdJjpFxTiX9svMgJxMj72eWdccJlXqj2LvEVlQzNP
	DUEw==
X-Gm-Message-State: AFeK/H0MqZBIocDivPtIuFp0KvoCGGQ//G2HPPkzYFL046kzHy2//0PWtYRPN5si7hhgA0cPpfrsr/TCoZ4FcQ==
X-Received: by 10.55.148.71 with SMTP id w68mr36899412qkd.268.1491512376760;
	Thu, 06 Apr 2017 13:59:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.170.220 with HTTP; Thu, 6 Apr 2017 13:58:56 -0700 (PDT)
In-Reply-To: <CAJowKgLUrMR9XN2Sb9ZuXCZx3K8Jy65pOOYGVhYeisszPoWLdA@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
	<CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com>
	<CAJowKgLUrMR9XN2Sb9ZuXCZx3K8Jy65pOOYGVhYeisszPoWLdA@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 6 Apr 2017 17:58:56 -0300
Message-ID: <CAKzdR-qa3=3MioY7fSQ+EiQyfPWUgB9sLSrLpCK-WEnx8YxUBA@mail.gmail.com>
To: erik@q32.com
Content-Type: multipart/alternative; boundary=94eb2c085880652551054c85c9ec
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 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
	Comments
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: Thu, 06 Apr 2017 20:59:38 -0000

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

Responding between lines...

On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty <earonesty@gmail.com> wrote:

> I personally appreciate the minimal changes, and often encourage
> development to be done this way - when it needs to be released quickly.
> But does this need to be released quickly?
>
>
Segwit2mb is a last resort option. It does not need to be released quickly.
Not at all. It just needs to be there in case no other option is chosen. I
put tentative dates. We can move them.


> - maybe the proposal should be renamed segwit 8mb and be discussed solely
> in terms of block weights.
>

The name does not matter much. The name means joining segwit with a 2Mb
hard-fork. It's a grammatical name.

I also disagree with the idea that segwit2mb is a 8mb increase. As stated
by in the Bitcon.org website [1] and backed up by scientific research, =E2=
=80=9Ca
block filled with standard single-signature P2PKH transactions would be
about 1.6MB and a block filled with 2-of-2 multisignature transactions
would be about 2.0MB.=E2=80=9D. As standard blocks are a combination betwee=
n P2PKH,
and 2-of-3 multisignatures, the actual average segwit block size will be
close to 2.0MB.

Because Segwit2Mb doubles the maximum size of a block, the average block
size for a block filed with average transactions is 4.0Mb.

[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-size

I can explain in a following e-mail why creating 8Mb blocks on purpose is
generally is an irrational choice. And in the case where it could provide
an economic benefit, adding parallel block validation to Core nullifies any
adversary advantage.



> a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.

You and me may never know the reasons why these operators (or many many of
other users) prefer to increase the block-size. I suppose it has to do high
the high current transaction fees as compared to less than a year ago.
Anyway consensus can only be achieved if one understands the others may
have reasons that do not match ours.

Last, if this proposal is rejected by any side, then we'll definitively
learn that side is not looking for any consensual resolution of the
conflict.


> - miners who currently object to segwit while pretending to like larger
> blocks will find some excuse to object to this too.
>
>
If they do, we'll get a lot of public, verifiable information from that
fact. The cost to include this patch is low compared with the benefit it
can bring and the information we can gather in case one of the sides
rejects it.

However, I've received positive feedback from them until now.


> - Given the challenges miners seem to have in flipping bits, I expect any
> fork that requires 95pct hash power to be vaporware.
>

Then we'll learn a lot about hard-forks, the limits of miner "voting" and
the quorums we can expect.

Regards,
Sergio.


>
> On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> The hard-fork is conditional to 95% of the hashing power has approved
>>> the segwit2mb soft-fork and the segwit soft-fork has been activated (wh=
ich
>>> should occur 2016 blocks after its lock-in time)
>>>
>>
>> Miners signalling they have upgraded by flipping a bit in the nVersion
>> field has little relevance in a hard fork. If 100% of the hash power
>> indicates they are running this proposal, but the nodes don't upgrade, w=
hat
>> will happen?
>>
>> For the record, I actually talk a lot about hard forks with various
>> developers and am very interested in the research that Johnson in
>> particular is pioneering. However, I have failed to understand your poin=
t
>> about 95% miner signalling in relation to a hard fork, so I am eagerly
>> awaiting your explanation.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

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

<div dir=3D"ltr">Responding between lines...<br><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Wed, Apr 5, 2017 at 11:27 PM, Erik Arones=
ty <span dir=3D"ltr">&lt;<a href=3D"mailto:earonesty@gmail.com" target=3D"_=
blank">earonesty@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto">I personally=
 appreciate the minimal changes, and often encourage development to be done=
 this way - when it needs to be released quickly.=C2=A0 But does this need =
to be released quickly?<br></div><div dir=3D"auto"><br></div></div></blockq=
uote><div><br></div><div>Segwit2mb is a last resort option. It does not nee=
d to be released quickly. Not at all. It just needs to be there in case no =
other option is chosen. I put tentative dates. We can move them.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"a=
uto"><div dir=3D"auto"></div><div dir=3D"auto">- maybe the proposal should =
be renamed segwit 8mb and be discussed solely in terms of block weights.</d=
iv></div></blockquote><div><br></div><div>The name does not matter much. Th=
e name means joining segwit with a 2Mb hard-fork. It&#39;s a grammatical na=
me.</div><div><br></div><div>I also disagree with the idea that segwit2mb i=
s a 8mb increase.=C2=A0As stated by in the Bitcon.org website [1] and backe=
d up by scientific research, =E2=80=9Ca block filled with standard single-s=
ignature P2PKH transactions would be about 1.6MB and a block filled with 2-=
of-2 multisignature transactions would be about 2.0MB.=E2=80=9D. As standar=
d blocks are a combination between P2PKH, and 2-of-3 multisignatures, the a=
ctual average segwit block size will be close to 2.0MB.<br><br>Because Segw=
it2Mb doubles the maximum size of a block, the average block size for a blo=
ck filed with average transactions is 4.0Mb.</div><div><br></div><div>[1] <=
a href=3D"https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit=
-size">https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-si=
ze</a><br></div><div><br></div><div>I can explain in a following e-mail why=
 creating 8Mb blocks on purpose is generally is an irrational choice. And i=
n the case where it could provide an economic benefit, adding parallel bloc=
k validation to Core nullifies any adversary advantage.</div><div><br></div=
><div><br></div><div><br></div><div>&gt; a high consensus hard fork is prob=
ably preferable to a low consensus soft fork, however there is nothing to i=
ndicate that segwit as it stands isnt already very high consensus except fo=
r a handful of pool operators protecting fee income. =C2=A0</div><div>=C2=
=A0</div><div>You and me may never know the reasons why these operators (or=
 many many of other users) prefer to increase the block-size. I suppose it =
has to do high the high current transaction fees as compared to less than a=
 year ago.</div><div>Anyway consensus can only be achieved if one understan=
ds the others may have reasons that do not match ours.=C2=A0</div><div><br>=
</div><div>Last, if this proposal is rejected by any side, then we&#39;ll d=
efinitively learn that side is not looking for any consensual resolution of=
 the conflict.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"auto"><span sty=
le=3D"font-family:sans-serif">- miners who currently object to segwit while=
 pretending to like larger blocks will find some excuse to object to this t=
oo.</span><br></div><div dir=3D"auto"><span style=3D"font-family:sans-serif=
"><br></span></div></div></div></blockquote><div><br></div><div>If they do,=
 we&#39;ll get a lot of public, verifiable information from that fact. The =
cost to include this patch is low compared with the benefit it can bring an=
d the information we can gather in case one of the sides rejects it.</div><=
div><br></div><div>However, I&#39;ve received positive feedback from them u=
ntil now.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"auto"><div dir=3D"auto"><div dir=3D"auto"><span style=3D=
"font-family:sans-serif"></span></div><div dir=3D"auto"><span style=3D"font=
-family:sans-serif">-=C2=A0</span><span style=3D"font-family:sans-serif">Gi=
ven the challenges miners seem to have in flipping bits, I expect any fork =
that requires 95pct hash power to be vaporware.</span></div></div></div></b=
lockquote><div><br></div><div>Then we&#39;ll learn a lot about hard-forks, =
the limits of miner &quot;voting&quot; and the quorums we can expect.</div>=
<div><br></div><div>Regards,=C2=A0</div><div>Sergio.</div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote"><div><div class=3D"gmail-h5">On Apr 3, 201=
7 11:02 AM, &quot;Btc Drak via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr=
>linuxfoundation.org</a>&gt; wrote:<br type=3D"attribution"></div></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div><div class=3D"gmail-h5"=
><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On =
Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div>The hard-fork is conditional to 95% of the hashing power has approved =
the segwit2mb soft-fork and the segwit soft-fork has been activated (which =
should occur 2016 blocks after its lock-in time)</div></div></blockquote><d=
iv><br></div><div>Miners signalling they have upgraded by flipping a bit in=
 the nVersion field has little relevance in a hard fork. If 100% of the has=
h power indicates they are running this proposal, but the nodes don&#39;t u=
pgrade, what will happen?<br></div><div><br></div><div>For the record, I ac=
tually talk a lot about hard forks with various developers and am very inte=
rested in the research that Johnson in particular is pioneering. However, I=
 have failed to understand your point about 95% miner signalling in relatio=
n to a hard fork, so I am eagerly awaiting your explanation.</div></div></d=
iv></div>
<br></div></div><span class=3D"gmail-">______________________________<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></div>
</blockquote></div><br></div></div>

--94eb2c085880652551054c85c9ec--