path: root/94/5724f0da72c9b86339f3f77f1b955147704e6d

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 A9E22932
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Nov 2016 23:46:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com
	[209.85.216.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AEF1413B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Nov 2016 23:46:01 +0000 (UTC)
Received: by mail-qt0-f177.google.com with SMTP id w33so77050708qtc.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 25 Nov 2016 15:46:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=m9Emeqjvz05u029cfixPEiigAQYStZwZkahccjW3Po4=;
	b=ACSlnoSepFL2ITOllAFrm3Nbn3RBqa7UhvgDf7FaXZ+L4mDMSwZoz70hPVjDpoekm6
	AeszgyxShhvf/L/ELCvrM5tus/jG8QWTB1jyhF6iSFiXWPM/cYEVVTc7UwaS7fIp5P1J
	eBA7qsWaPEq//JbuzYciqhf4xFbeGILowBBH5QAGyfrk34tLQ9Tnbl5IM48g/P65B+LP
	ciin/C3bYtAbsNkrduAjfsag0BHyuXSfREJe5oZQSsj8I9y/UPnSBe+IyOoCZJ5ADxKT
	+7zAgozZ/ssP4kLQm7fVng3PuZ/P5vhH/8HzS0wtVl8FYlTkfyGmO9A5tWetIwZwayGC
	rr+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=m9Emeqjvz05u029cfixPEiigAQYStZwZkahccjW3Po4=;
	b=K3v6MAgF2/lDPTXBDdyJJVg4qwlWqBdFzx8SvRRFdq33Qoy+pn6JJRhOYCJJujgWEs
	rIPol7ChMCeFMsQeEEenuwJtsWCvH+kaxV84SHY+f6RjUDIiszUA5pcx9ULjxVduwX3X
	RUSgN9zp8x5OfX01Cwrj30pezs+snLIsTCk3gV3y6xncxDh2n9oHHvavPPA54Gfafu0U
	/LG1nFcWGk+wSDjJIxnU9zOCkk1ACuHHMbZaJ8xjo6kK3ez+R2gl53wZH34+nj5fDQ17
	eV4e4LwIDqCo+CfK+bvyZ8ab0Y/zyDmZ3ZwKWF6LJWNTUPecKfalyJ4mTZ43JYb7Uk21
	uATA==
X-Gm-Message-State: AKaTC01Jq+benG3cPGGJSzlBUUcX0POS8LG5bi+p61bIuQcQZR/ZooYEyjz60fB2CHWCaUYQidzuUQ6WjNvL8Q==
X-Received: by 10.200.49.106 with SMTP id h39mr9136314qtb.69.1480117560865;
	Fri, 25 Nov 2016 15:46:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.237.35.13 with HTTP; Fri, 25 Nov 2016 15:45:20 -0800 (PST)
In-Reply-To: <CAKzdR-rL9ndo9JZodLiSc0BEThiF1kQMs4yvkjJyc_8nzmp8DA@mail.gmail.com>
References: <C10BF9D1-435D-47C9-B98C-9B118B5922A1@gmx.com>
	<CAKzdR-r7or+DF64qxT=HLUvrtdkSQD0hpO43kUjfWS-397+yHA@mail.gmail.com>
	<61681436.SvSR6Fsd9n@strawberry>
	<CAKzdR-rL9ndo9JZodLiSc0BEThiF1kQMs4yvkjJyc_8nzmp8DA@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Fri, 25 Nov 2016 20:45:20 -0300
Message-ID: <CAKzdR-oE44Qcb1sfz3RmcVmtR9qzB+9J5ufTgGmdQ_Xctenh7A@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1142d35c70fb55054228b98d
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
X-Mailman-Approved-At: Sat, 26 Nov 2016 11:53:18 +0000
Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited
 Node Deals With Large Blocks
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, 25 Nov 2016 23:46:02 -0000

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

I now think my reasoning and conclusions are based on a false premise: that
BU block size policies for miners can be heterogeneous.

There can't be short forks because forks are not in the best interest of
the honest miner majority. All miners need to announce and follow the same
block size policy to prevent short forks.

The incentives are established so that all block size negotiations will be
carried between miners in a off-chain manner, not by modifying the policy
nor by announcing anything in the coinbase,

If block size negotiations are meant to be open and carried on on-chain,
then it's much better to let miners increase or decrease the block size
limit by 1% per block (such as what Ethereum does with the gas limit).





On Fri, Nov 25, 2016 at 7:31 PM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

>
>
> On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via
>> bitcoin-
>> dev wrote:
>> > Without a detailed analysis, unlimited block size seems a risky change
>> to
>> > Bitcoin, to me.
>>
>> What exactly do you think is a =E2=80=98change=E2=80=99 in bitcoin here?
>>
>> A change is anything that modifies with a HF the current state of the
> Bitcoin Core implementation of the consensus protocol. Sadly (or happily,
> for some) there is no "abstract" definition of Bitcoin.
>
>
>
>> The concept of proof-of-work is that the longer a chain, the higher
>> probability that that one will be extended for the simple reason that
>> another chain will have to show a higher amount of proof of work to =E2=
=80=98win=E2=80=99.
>>
>> We know what Bitcoin the protocol dictates, but if what the protocol
> dictates is not in the best interest of miners or full-nodes? then they
> will simply choose a rule that maximizes their revenue (or any other
> measure of performance, such as lower latency, or less transaction revers=
al
> probability).
>
>
> As far as I understand the document from Peter, there is no change there =
at
>> all. Only chains with more POW will win.
>>
>
> I haven't gone to the code to check, but the video Peter sent does not sa=
y
> that. It says that miners will mine on top of a block ONLY if the "gate"
> has been opened for that block (e.g. there is additional blocks to push a
> big block). So a miner having a preferring low block sizes will choose to
> mine on top of the A1,A2,A3 chain (3 units of work), while miners
> supporting bigger sizes will mine on top of the chain B1,S2,S3,S4 (4 unit=
s
> of work).
>
> Saying that the chain starting with B1 is not considered by a node X does
> not mean that the node X is blind to the information that can be extracte=
d
> from the fact that there is a chain of 4 blocks starting from B1.
> If there is more information, there may be a better local choice. If ther=
e
> are better local choices, there is probably a better global equilibrium (=
or
> not equilibrium at all).
>
>
>> Or, to answer your example, miners will prefer to extend the chain with
>> the
>> most POW.
>>
>
> Clearly this is not universal: some miners will, and some other miners
> won't, because some miners have postponed adding some blocks.
>
>
>
>>
>> The other fact stays the same as well, if you protect from reorgs by
>> expecting more confirmations. Nothing changes here either. The
>> common-sense 6
>> confirmations for things like exchange-deposits keep having the same
>> security.
>>
>
> Suppose that I provide a service that accepts payments with 2
> confirmations, and in certain time I have the information that the networ=
k
> is at the same time considering the forks B1 S2 and A1 A2. Then the best =
I
> can do is NOT to accept the 2-confirmation and wait for a resolution of t=
he
> fork. Choosing either fork may put me at the risk of immediate reversal.
>
> The existence of fork information changes equilibrium decision to choose
> the longest-chain.  This is the same that happens with the GHOST protocol=
:
> the information on the existence of uncles changes the local incentives t=
o
> choose the longest chain to some different strategy, and when all nodes
> change their strategy, then the supposedly last equilibrium state is that
> all follow the GHOST strategy for choosing the heaviest chain.
>
>
>>
>> The basic idea that we have a 3 or 4 deep fork is a huge problem in
>> Bitcoin.
>> It hasn=E2=80=99t happened for ages, and we like it that way. The miners=
 like it
>> that way too. Its disruptive.
>> The is a problem that is not created by the =E2=80=98excessive block=E2=
=80=99 concept. It
>> does, however, provide a possible solution to this very far-fetched
>> problem.
>>
>> You should also realize that the policy of a miner is stored in the
>> coinbase.
>>
>> This is important, but yet the full node does not use this information
> automatically. The amount of confirmations that a node accepts is not
> affected by the miner's policies or the size of the blocks mined, but it
> should.
>
>
>> That said, I=E2=80=99m sure there are improvements to be made to the pol=
icy that
>> BU
>> uses.
>
>
> Probably a simple wise addition would be to estimate the accepted block
> size for the majority of the miners (S), and only count block confirmatio=
ns
> for wallet transactions taking into account only blocks whose size is low=
er
> or equal than S. So for example, if Alice receives a transaction T in blo=
ck
> B1 and it is confirmed by block B2, but size(B1)>S and size(B2)>S, then t=
he
> wallet should tell Alice that transaction T has 0 confirmations. This loc=
al
> strategy reduces the chances that Alice accept T but is then easily
> reversed for the opposite fork growing one block ahead.
>
> Regards,
>  Sergio
>
>

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

<div dir=3D"ltr"><div>I now think my reasoning and conclusions are based on=
 a false premise: that  BU block size policies for miners can be heterogene=
ous.<br><br>There can&#39;t be short forks because forks are not in the bes=
t interest of the honest miner majority. All miners need to announce and fo=
llow the same block size policy to prevent short forks.<br><br>The incentiv=
es are established so that all block size negotiations will be carried betw=
een miners in a off-chain manner, not by modifying the policy nor by announ=
cing anything in the coinbase, <br><br></div>If block size negotiations are=
 meant to be open and carried on on-chain, then it&#39;s much better to let=
 miners increase or decrease the block size limit by 1% per block (such as =
what Ethereum does with the gas limit).<br><br><br><br><div><br></div></div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 25, =
2016 at 7:31 PM, Sergio Demian Lerner <span dir=3D"ltr">&lt;<a href=3D"mail=
to:sergio.d.lerner@gmail.com" target=3D"_blank">sergio.d.lerner@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D""=
>On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev <span dir=3D"=
ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">On Thursday, 24 Novembe=
r 2016 22:39:05 CET Sergio Demian Lerner via bitcoin-<br>
<span class=3D"m_-625454818467092677gmail-">dev wrote:<br>
&gt; Without a detailed analysis, unlimited block size seems a risky change=
 to<br>
&gt; Bitcoin, to me.<br>
<br>
</span>What exactly do you think is a =E2=80=98change=E2=80=99 in bitcoin h=
ere?<br>
<br></blockquote></span><div>A change is anything that modifies with a HF t=
he current state of the Bitcoin Core implementation of the consensus protoc=
ol. Sadly (or happily, for some) there is no &quot;abstract&quot; definitio=
n of Bitcoin.<br><br>=C2=A0<br></div><span class=3D""><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
The concept of proof-of-work is that the longer a chain, the higher<br>
probability that that one will be extended for the simple reason that<br>
another chain will have to show a higher amount of proof of work to =E2=80=
=98win=E2=80=99.<br>
<br></blockquote></span><div>We know what Bitcoin the protocol dictates, bu=
t if what the protocol dictates is not in the best interest of miners or fu=
ll-nodes? then they will simply choose a rule that maximizes their revenue =
(or any other measure of performance, such as lower latency, or less transa=
ction reversal probability).<br><br><br></div><span class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
As far as I understand the document from Peter, there is no change there at=
<br>
all. Only chains with more POW will win.<br></blockquote><div>=C2=A0</div><=
/span><div>I haven&#39;t gone to the code to check, but the video Peter sen=
t does not=20
say that. It says that miners will mine on top of a block ONLY if the &quot=
;gate&quot; has been opened for that block (e.g. there is additional blocks=
 to=20
push a big block). So a miner having a preferring low block sizes will choo=
se to mine on
 top of the A1,A2,A3  chain (3 units of work), while miners supporting=20
bigger sizes will mine on top of the chain B1,S2,S3,S4 (4 units of=20
work).<br><br></div><div>Saying that the chain starting with B1 is not cons=
idered by a node X does not mean that the node X is blind to the informatio=
n that can be extracted from the fact that there is a chain of 4 blocks sta=
rting from B1.<br></div><div>If there is more information, there may be a b=
etter local choice. If there are better local choices, there is probably a =
better global equilibrium (or not equilibrium at all).<br></div><span class=
=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Or, to answer your example, miners will prefer to extend the chain with the=
<br>
most POW.<br></blockquote><div><br></div></span><div>Clearly this is not un=
iversal: some miners will, and some other miners won&#39;t, because some mi=
ners have postponed adding some blocks.<br><br>=C2=A0 <br></div><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The other fact stays the same as well, if you protect from reorgs by<br>
expecting more confirmations. Nothing changes here either. The common-sense=
 6<br>
confirmations for things like exchange-deposits keep having the same<br>
security.<br></blockquote><div><br></div></span><div>Suppose that I provide=
 a service that accepts payments with 2 confirmations, and in certain time =
I have the information that the network is at the same time considering the=
 forks B1 S2 and A1 A2. Then the best I can do is NOT to accept the 2-confi=
rmation and wait for a resolution of the fork. Choosing either fork may put=
 me at the risk of immediate reversal. <br><br>The existence of fork inform=
ation changes equilibrium decision to choose the longest-chain.=C2=A0 This =
is the same that happens with the GHOST protocol: the information on the ex=
istence of uncles changes the local incentives to choose the longest chain =
to some different strategy, and when all nodes change their strategy, then =
the supposedly last equilibrium state is that all follow the GHOST strategy=
 for choosing the heaviest chain.<br>=C2=A0<br></div><span class=3D""><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
<br>
The basic idea that we have a 3 or 4 deep fork is a huge problem in Bitcoin=
.<br>
It hasn=E2=80=99t happened for ages, and we like it that way. The miners li=
ke it<br>
that way too. Its disruptive.<br>
The is a problem that is not created by the =E2=80=98excessive block=E2=80=
=99 concept. It<br>
does, however, provide a possible solution to this very far-fetched problem=
.<br>
<br>
You should also realize that the policy of a miner is stored in the<br>
coinbase.<br>
<br></blockquote></span><div>This is important, but yet the full node does =
not use this information automatically. The amount of confirmations that a =
node accepts is not affected by the miner&#39;s policies or the size of the=
 blocks mined, but it should.<br>=C2=A0<br></div><span class=3D""><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">
That said, I=E2=80=99m sure there are improvements to be made to the policy=
 that BU<br>
uses. </blockquote><div><br></div></span><div>Probably a simple wise additi=
on would be to estimate the accepted block size for the majority of the min=
ers (S), and only count block confirmations for wallet transactions taking =
into account only blocks whose size is lower or equal than S. So for exampl=
e, if Alice receives a transaction T in block B1 and it is confirmed by blo=
ck B2, but size(B1)&gt;S and size(B2)&gt;S, then the wallet should tell Ali=
ce that transaction T has 0 confirmations. This local strategy reduces the =
chances that Alice accept T but is then easily reversed for the opposite fo=
rk growing one block ahead.<br></div><div>=C2=A0<br></div><div>Regards,<br>=
</div><div>=C2=A0Sergio<br></div></div><br></div></div>
</blockquote></div><br></div>

--001a1142d35c70fb55054228b98d--