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
|
Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1AFF7596
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 19:55:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com
[209.85.217.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3F1301A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 19:55:36 +0000 (UTC)
Received: by mail-ua0-f182.google.com with SMTP id 12so64502314uas.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 11:55:36 -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=65zS5Tvehc8EzoNJg36Rccui+gShaUE9BZXOFb13uRA=;
b=kP0nUqB0tCHQO+bBDXEr5Kj1Xr2hpMNai8oMJpjyIOqjUIYDrnDok6J6SzX5k+4Kt3
nir+bjFcn49r7f/lwFw2sbL1vmVzOa0/nCOry6V66lXP16XONE/bbI0oAvJuLm9+dqDt
TssRDQFYi4kFPs0rq84rHeUdZsJ5KY1tziN9959Xv/2m0J2OHICZuGYHop4sX4fDfb6l
aFQLZK6UD2oMmwT0GNkG32+0ftL2kdbN9qER4vsSwRxbSrVF+UQci2cetnhYESdHRvgB
4JcvxAECrhi9WGh8ACe7Uhfgw4lj/LwzLkt2qhiC3vHzSnk4hA4NaaGbjd53hxU101Lm
KEvA==
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=65zS5Tvehc8EzoNJg36Rccui+gShaUE9BZXOFb13uRA=;
b=JNcc65VN+nYveAzaCSxH7l6kUwTbPg0Cy90GiJ+1WA0Ql9zJvpf8i6KOQJDT4zeuqX
70rI3n3IWTHRa1mHmfPj531AR1y7U9XtP5ZYrQqIxyQGAIvTqPiTONFA6Lynj1Ca29nO
SYFiYOCOYITv5znKhu5HSVruiRFIR2Yod5RPyAKL5b6+e+DnkomgRyJC+midWy62S4rG
pFg9HfnVlt1Y05ExzmCM7kfQgsM9VyU6yOJ5vV/j66XIE5MZs6oVzEmz7uTjR/4OhIkb
eh2rxbK5+Pyqgj88MNJGkU14ItloyRJHvyOz2M5ZHIsFIizQtfyzYxrYs2hwTV+5ZT2+
5jng==
X-Gm-Message-State: AKaTC03itHZgyk59TWcw/05LaL8yQg4FVUMlhQ+dFhObVHvdXnglrTnyuJyTA90Mk9+2bwp8xDO2WnGSVSoIkA==
X-Received: by 10.176.86.23 with SMTP id y23mr55546673uaa.88.1481486135361;
Sun, 11 Dec 2016 11:55:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Sun, 11 Dec 2016 11:55:34 -0800 (PST)
In-Reply-To: <d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
References: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
<c318f76d-0904-2e1b-453b-60179f8209bb@sky-ip.org>
<CAGCNRJrLM2ZR9qCvuNfyr2mUk50szzHnG-crmpv_3cH=xGxYOg@mail.gmail.com>
<d691b6f8-0c15-d293-0027-dcce145fbe8e@sky-ip.org>
From: "t. khan" <teekhan42@gmail.com>
Date: Sun, 11 Dec 2016 14:55:34 -0500
Message-ID: <CAGCNRJo_VE9nBhP=oY7hV0UJ-OSuTBxu+Tf28_utJW8qi7rzxg@mail.gmail.com>
To: s7r@sky-ip.org,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f403045daa66d685880543675e46
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE, URIBL_BLACK 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: Sun, 11 Dec 2016 20:18:21 +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 19:55:39 -0000
--f403045daa66d685880543675e46
Content-Type: text/plain; charset=UTF-8
On Sun, Dec 11, 2016 at 12:11 PM, s7r <s7r@sky-ip.org> wrote:
>
> This is an incentive, if few miners agree to create a large conglomerate
> that will ultimately control the network.
>
> You miss something obvious that makes this attack actually free of cost.
> Nothing will "cost them more in transaction fees". A miner can create
> thousands of transactions paying to himself, and not broadcast them to
> the network, but hold them and include them in the blocks he mines. The
> fees are collected by him because transactions are included in a block
> that he mined and the left amount is in another wallet of the same
> person. Repeat this continuously to fill blocks.
>
No, that wasn't overlooked. Miners could indeed stuff their own blocks for
free, but they can't stuff blocks mined by others for free.
In the hypothetical scenario where there is a single mining pool which
mines most (if not all) of the blocks, we would have much larger problems
than their ability to raise the max block size gradually. Even if they were
able to fill 100% of the blocks for an entire year, the max block size for
that 2016 block period would be 7.25MB (not accounting for SegWit). After
the whole year they would have made no extra profit vs doing nothing. And
as soon as they stopped this scheme, block size would spring back to it's
natural level.
The good news is, this scenario has never happened and even when we've come
remotely close (when ASICs first shipped), the situation was temporary. The
odds of this happening in the future and persisting long enough to have any
major effect with Block75 are very close to zero.
> Topology and bandwidth speed / hash rate of the network cannot be
> controlled - if we make assumptions about these it might have terrible
> consequences.
>
> Even if we take in consideration that bandwidth will only grow and disk
> space will only cost less (which is not something we can safely assume,
> by the way) the hard limit max. block size cannot grow to unlimited
> value (even if the growth happens over time). There is also a validation
> cost in time for each block, for the health of the network any node
> should be able to download _and_ validate a block, before next block
> gets mined.
>
> You said in another post that a permanent solution is preferred, rather
> than kicking the can down the road. I fully agree, as well as many
> others reading this list, but the permanent solution doesn't necessarily
> have to be increasing the max block size dynamically.
>
Increasing *and* decreasing max block size dynamically. Block75 is
self-correcting, whereas any solution with hardcoded limits can't correct
without human intervention and would rely on our ability to predict the
future (which as you pointed out, we can't do). Therefore, any solution
that's not dynamic cannot be permanent.
Additionally, the frequent and gradual changes in max block size would
allow us to see any consequences well in advance (years probably).
> If you think about it the other way around, dynamically growing the max
> block size is also kicking the can down the road ... just without having
> to touch it and get dust on the boot ;)
Not having to touch it again = permanent solution. ;)
It would be helpful if some others would run the numbers on how Block75
would adjust the block size over time:
new max block size = 1000kb + (average block size over last 2016 blocks -
750kb)
-t.k.
--f403045daa66d685880543675e46
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Dec 11, 2016 at 12:11 PM, s7r <span dir=3D"ltr"><<a href=3D"mail=
to:s7r@sky-ip.org" target=3D"_blank">s7r@sky-ip.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex"><span class=3D"gmail-"><br>
</span>This is an incentive, if few miners agree to create a large conglome=
rate<br>
that will ultimately control the network.<br>
<br>
You miss something obvious that makes this attack actually free of cost.<br=
>
Nothing will "cost them more in transaction fees". A miner can cr=
eate<br>
thousands of transactions paying to himself, and not broadcast them to<br>
the network, but hold them and include them in the blocks he mines. The<br>
fees are collected by him because transactions are included in a block<br>
that he mined and the left amount is in another wallet of the same<br>
person. Repeat this continuously to fill blocks.<br>
<span class=3D"gmail-"></span></blockquote><div><br></div><div>No, that was=
n't overlooked. Miners could indeed stuff their own blocks for free, bu=
t they can't stuff blocks mined by others for free.</div><div><br></div=
><div>In the hypothetical scenario where there is a single mining pool whic=
h mines most (if not all) of the blocks, we would have much larger problems=
than their ability to raise the max block size gradually. Even if they wer=
e able to fill 100% of the blocks for an entire year, the max block size fo=
r that 2016 block period would be 7.25MB (not accounting for SegWit). After=
the whole year they would have made no extra profit vs doing nothing. And =
as soon as they stopped this scheme, block size would spring back to it'=
;s natural level.</div><div><br></div><div>The good news is, this scenario =
has never happened and even when we've come remotely close (when ASICs =
first shipped), the situation was temporary. The odds of this happening in =
the future and persisting long enough to have any major effect with Block75=
are very close to zero.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Topology an=
d bandwidth speed / hash rate of the network cannot be<br>
controlled - if we make assumptions about these it might have terrible<br>
consequences.<br>
<br>
Even if we take in consideration that bandwidth will only grow and disk<br>
space will only cost less (which is not something we can safely assume,<br>
by the way) the hard limit max. block size cannot grow to unlimited<br>
value (even if the growth happens over time). There is also a validation<br=
>
cost in time for each block, for the health of the network any node<br>
should be able to download _and_ validate a block, before next block<br>
gets mined.<br>
<br>
You said in another post that a permanent solution is preferred, rather<br>
than kicking the can down the road. I fully agree, as well as many<br>
others reading this list, but the permanent solution doesn't necessaril=
y<br>
have to be increasing the max block size dynamically.<br></blockquote><div>=
<br></div><div>Increasing *and* decreasing max block size dynamically. Bloc=
k75 is self-correcting, whereas any solution with hardcoded limits can'=
t correct without human intervention and would rely on our ability to predi=
ct the future (which as you pointed out, we can't do). Therefore, any s=
olution that's not dynamic cannot be permanent.</div><div><br></div><di=
v>Additionally, the frequent and gradual changes in max block size would al=
low us to see any consequences well in advance (years probably).</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">If you think about it the other way around, dy=
namically growing the max<br>
block size is also kicking the can down the road ... just without having<br=
>
to touch it and get dust on the boot ;)</blockquote><div><br></div><div>Not=
having to touch it again =3D permanent solution. ;)</div><div><br></div><d=
iv>It would be helpful if some others would run the numbers on how Block75 =
would adjust the block size over time:</div><div><br></div><div>new max blo=
ck size =3D 1000kb + (average block size over last 2016 blocks - 750kb)</di=
v><div><br></div><div>-t.k.</div></div><br></div></div>
--f403045daa66d685880543675e46--
|