Content-Type: multipart/alternative;
	boundary=Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <CAEgR2PEuZBZqUJ-qehBpk8dL8U-F5z9mZAn-UuRwUXiUSOcXRQ@mail.gmail.com>
Date: Sat, 10 Dec 2016 21:29:08 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <2C3BEC33-BAD0-4CFB-8FE1-BBB18020E3D8@voskuil.org>
References: <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
	<CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
	<CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
	<CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
	<CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
	<CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
	<CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
	<CAEgR2PEvpEwv=a0syn43negEnvGcoQ8LBxKRp4-JpnxCNORJSg@mail.gmail.com>
	<CAPg+sBiZmRdLOgG9iN2hOWVr_eCLTwDrbuETd_w9-bUJOfTjgw@mail.gmail.com>
	<CAEgR2PEuZBZqUJ-qehBpk8dL8U-F5z9mZAn-UuRwUXiUSOcXRQ@mail.gmail.com>
To: Daniele Pinna <daniele.pinna@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
	(aka Block75)
Precedence: list


--Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

The presumption of the mining aspect of the Bitcoin security model is that t=
he mining majority is a broadly distributed set of independent people, not o=
ne person who controls a majority of the hash power.=20

You seem to have overlooked a qualifier in your Satoshi quote: "...by nodes t=
hat are not cooperating to attack the network". A single miner with majority=
 hash power is of course cooperating with himself. At that point the questio=
n of whether he is attacking the network is moot, it's his network.

I believe that Pieter's point is that a system optimized for orphan rate may=
 in effect be optimized for a single entity providing all double spend prote=
ction. That works directly against the central principle of Bitcoin security=
. The security of the money is a function of the number of independent miner=
s and sellers.

e

> On Dec 10, 2016, at 7:17 PM, Daniele Pinna via bitcoin-dev <bitcoin-dev@li=
sts.linuxfoundation.org> wrote:
>=20
> How is the adverse scenario you describe different from a plain old 51% at=
tack? Each proposed protocol change  where 51% or more  of the network can p=
otentially game the rules and break the system should be considered just as a=
cceptable/unacceptable as another.=20
>=20
> There comes a point where some form of basic honesty must be assumed on be=
half of participants benefiting from the system working properly and reliabl=
y.=20
>=20
> Afterall, what magic line of code prohibits all miners from simultaneously=
 turning all their equipment off...  just because?=20
>=20
> Maybe this 'one':
>=20
> "As long as a majority of CPU power is controlled by nodes that are not co=
operating to attack the network, they'll generate the longest chain and outp=
ace attackers. The network itself requires minimal structure."
>=20
> Is there such a thing as an unrecognizable 51% attack?  One where the rema=
ining 49% get dragged in against their will?=20
>=20
> Daniele=20
>=20
>> On Dec 10, 2016 6:39 PM, "Pieter Wuille" <pieter.wuille@gmail.com> wrote:=

>>> On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
>>> We have models for estimating the probability that a block is orphaned g=
iven average network bandwidth and block size.=20
>>>=20
>>> The question is, do we have objective measures of these two quantities? C=
ouldn't we target an orphan_rate < max_rate?=20
>>=20
>> Models can predict orphan rate given block size and network/hashrate topo=
logy, but you can't control the topology (and things like FIBRE hide the eff=
ect of block size on this as well). The result is that if you're purely opti=
mizing for minimal orphan rate, you can end up with a single (conglomerate o=
f) pools producing all the blocks. Such a setup has no propagation delay at a=
ll, and as a result can always achieve 0 orphans.
>>=20
>> Cheers,
>>=20
>> --=20
>> Pieter
>>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div></div><div>The presumption of the mini=
ng aspect of the Bitcoin security model is that the mining majority is a bro=
adly distributed set of independent people, not one person who controls a ma=
jority of the hash power.&nbsp;</div><div><br></div><div>You seem to have ov=
erlooked a qualifier in your Satoshi quote: "...<span style=3D"background-co=
lor: rgba(255, 255, 255, 0);">by nodes that are not cooperating to attack th=
e network". A single miner with majority hash power is of course cooperating=
 with himself. At that point the question of whether he is attacking the net=
work is moot, it's his network.</span></div><div><br></div><div>I believe th=
at Pieter's point is that a system optimized for orphan rate may in effect b=
e optimized for a single entity providing all double spend protection. That w=
orks directly against the central principle of Bitcoin security. <span style=
=3D"background-color: rgba(255, 255, 255, 0);">The security of the money is a=
 function of the number of independent miners and sellers.</span></div><div>=
<br></div><div>e</div><div><br>On Dec 10, 2016, at 7:17 PM, Daniele Pinna vi=
a bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><blockquote=
 type=3D"cite"><div><div dir=3D"auto">How is the adverse scenario you descri=
be different from a plain old 51% attack? Each proposed protocol change &nbs=
p;where 51% or more &nbsp;of the network can potentially game the rules and b=
reak the system should be considered just as acceptable/unacceptable as anot=
her.&nbsp;<div dir=3D"auto"><br></div><div dir=3D"auto">There comes a point w=
here some form of basic honesty must be assumed on behalf of participants be=
nefiting from the system working properly and reliably.&nbsp;</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Afterall, what magic line of code prohibi=
ts all miners from simultaneously turning all their equipment off... &nbsp;j=
ust because?&nbsp;</div><div dir=3D"auto"><br></div><div dir=3D"auto">Maybe t=
his 'one':</div><div dir=3D"auto"><br></div><div dir=3D"auto">"As long as a m=
ajority of CPU power is controlled by nodes that are not cooperating to atta=
ck the network, they'll generate the longest chain and outpace attackers. Th=
e network itself requires minimal structure."</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Is there such a thing as an unrecognizable 51% attack?&=
nbsp; One where the remaining 49% get dragged in against their will?&nbsp;</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Daniele&nbsp;</div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Dec 10, 2016 6:3=
9 PM, "Pieter Wuille" &lt;<a href=3D"mailto:pieter.wuille@gmail.com">pieter.=
wuille@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna vi=
a bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.or=
g</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><span=
 style=3D"font-size:13.696px;font-family:sans-serif">We have models for esti=
mating the probability that a block is orphaned given average network bandwi=
dth and block size.&nbsp;</span><br></div><div dir=3D"auto"><span style=3D"f=
ont-size:13.696px;font-family:sans-serif"><br></span></div><div dir=3D"auto"=
><span style=3D"font-family:sans-serif;font-size:13.696px">The question is, d=
o we have objective measures of these two quantities? Couldn't we target an o=
rphan_rate &lt; max_rate?&nbsp;</span><span style=3D"font-size:13.696px;font=
-family:sans-serif"><br></span></div></div></blockquote><div><br></div><div>=
Models can predict orphan rate given block size and network/hashrate topolog=
y, but you can't control the topology (and things like FIBRE hide the effect=
 of block size on this as well). The result is that if you're purely optimiz=
ing for minimal orphan rate, you can end up with a single (conglomerate of) p=
ools producing all the blocks. Such a setup has no propagation delay at all,=
 and as a result can always achieve 0 orphans.<br><br></div><div>Cheers,<br>=
<br>-- <br></div><div>Pieter<br><br></div></div></div></div>
</blockquote></div></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></body></=
html>=

--Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C--