1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6902D40D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 05:29:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADA9E130
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 05:29:10 +0000 (UTC)
Received: by mail-pg0-f45.google.com with SMTP id 3so23050865pgd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 10 Dec 2016 21:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ePyfoSwbZznEtpdVlyGz6LX4ki+UHlg07z2mzAu9OZI=;
b=jxG1VAtpoa8aPxQbjIMR3gM0HjVDaWUCxls8iFAoYWZE/L4PURH3kWpK+IegfMKc70
lwY0Ugj+c3SrZF6fzbUwASIg1c4D0LDKQ/wyuaZE09vv/a70DK/zzA/Su0Nar18EKcN2
yJjBgbeP7QKN608Ukq7z1i6uis6Qdex1Bv4LwY8DgaQHoyKG/rSsyys/oBUYb9EqzS7w
08bzBT+o77Zo3/WfbCrQWJXQjzy3lF06lz3EP2GXgY2gEN/NmjxWxwIycpiFyH1gS1lT
c0aLpwTANVfPWSE58fD/bJTDZUv/+frQT1qQ+tlDUL9uZ9XGTguUujYLR1VKPvBvNrMe
OmJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ePyfoSwbZznEtpdVlyGz6LX4ki+UHlg07z2mzAu9OZI=;
b=j7agyMERpt3ESrE1NjfjxzuIOHXzi2O1eHj2+vEMk44Ex0gasVXYyuGVxcWtc0VMPB
fgZ/RGHUaikx0EtWvwPYhjznpWHcJjL8LNL5WrSLu1LKesgbWCtpr6VIQ0OqDvSgvyla
qr0r/hhRsi4ZavHQ9vBKxioYjEZQo1BhpXUArT2gL5E9xzv4qPIkq5ZhDPP7wbzc3Qa9
fOZMAdmRgcaYnLot27N6jVPMc9W16Kfh7YI2oWmrYl3/3dosKbmea9yXetBrDqRtxShM
b+og0LjP1mXhJnqlur5kl66KdDF3ZZ/GeSAYKBTnUiFaoqeAxEWtWM51lfyKK7aWCmKe
522w==
X-Gm-Message-State: AKaTC01oHKu9eKsNiicfXn71xatnDbjfFCgONmCOm8SYT1BqtCXqEMRW8YWmW3jv+JhgQw==
X-Received: by 10.84.176.100 with SMTP id u91mr170980227plb.7.1481434150267;
Sat, 10 Dec 2016 21:29:10 -0800 (PST)
Received: from ?IPv6:2601:600:9000:d69e:401e:9c01:84f9:85ce?
([2601:600:9000:d69e:401e:9c01:84f9:85ce])
by smtp.gmail.com with ESMTPSA id
d197sm67590895pfd.38.2016.12.10.21.29.09
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 10 Dec 2016 21:29:09 -0800 (PST)
Content-Type: multipart/alternative;
boundary=Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14B100)
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>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 11 Dec 2016 07:04:11 +0000
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty
(aka Block75)
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: Sun, 11 Dec 2016 05:29:11 -0000
--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. </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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">b=
itcoin-dev@lists.linuxfoundation.org</a>> 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 of the network can potentially game the rules and b=
reak the system should be considered just as acceptable/unacceptable as anot=
her. <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. </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... j=
ust because? </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? </=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Daniele </div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Dec 10, 2016 6:3=
9 PM, "Pieter Wuille" <<a href=3D"mailto:pieter.wuille@gmail.com">pieter.=
wuille@gmail.com</a>> 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"><<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.or=
g</a>></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. </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 < max_rate? </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--
|
