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
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
|
Return-Path: <andrew.johnson83@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2AFF18F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 20:38:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com
[209.85.217.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 424CA15B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 20:38:29 +0000 (UTC)
Received: by mail-ua0-f170.google.com with SMTP id 20so65122722uak.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 11 Dec 2016 12:38:29 -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
:cc; bh=wJ1VEi2sW5DW3hfxy1k9zNMj4lBzgDu/Cx8EHZVBZFE=;
b=n+UC/TZQUPXXvjRNpCVf2zO72MAd3m5WW5369XWoGWjqKMAYlUD+xeibFOuvr7dkdy
syVD6k4gxcv7j0MEnzZ7Ytq5nvPh3ZTnt2rf2VSpndlsvzGtoupyA+4r0EqhvvPwOXmi
csat8Dt3aRp5GOalvobCVC+Dq3Is/28TTMHD403q5ZG7rYCAxb0WROXqCLXOK6Xivwdv
3rF7lP/EnPIfmKSwhIxH2mRC9+fdvEgt57/XsglnTzO1jlUDuNapWAZ4Su1JlRo8lMuD
ZkmIoVr5qqfx2r2PVbdX7kGA6J5sbT2C5VhLyzhCnp5JI47vI5lBsYuW82lXL13BSPC2
1isA==
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:cc;
bh=wJ1VEi2sW5DW3hfxy1k9zNMj4lBzgDu/Cx8EHZVBZFE=;
b=eSiYFf+vg2uF14sEAhureFZOVBQ4osyfIPwHguxCtKBwzGNGe12zYEHsWuPDrnYfKg
nLLsx+FRUO4bdaGBTPi+XjEzC+Noh6ahQzaPLGsBHNSQ6FUlxsLNj5H5v8nbnJpCDhGJ
mXQ7qlZyWS6cgx7SKozJ/dWU+uZqZPr7AUpFOeYW7dGogHnsM/vsU8pJ8m6d5KGfn9Bx
dpx5d8t97drVfnGNlTR1w+qzuGHW8471YCNfS8KXp/tHl+xlGhZndQchS9ZZv01925Vp
6oAynmUhJTCMF4H6fUJ+gwvRmXLsTsn3fMtl4p/Irc59E12d8P9l9gQ3NaAdgRu36LuZ
cmYA==
X-Gm-Message-State: AKaTC03B3yhegNviJbg0DoAU21cIstxATQhGJXQ4Byj4bo7Fj4KXDNQl8LvNo9Z/oudhPujhtNcjK8t0Iv2Ggg==
X-Received: by 10.176.84.207 with SMTP id q15mr58034600uaa.177.1481488708389;
Sun, 11 Dec 2016 12:38:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.152.218 with HTTP; Sun, 11 Dec 2016 12:38:27 -0800 (PST)
Received: by 10.103.152.218 with HTTP; Sun, 11 Dec 2016 12:38:27 -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: Andrew Johnson <andrew.johnson83@gmail.com>
Date: Sun, 11 Dec 2016 14:38:27 -0600
Message-ID: <CAAy62_KLAJ2OOv863HB4CzoAr7QOURRMFF2pH2pGUVQ9gMpecg@mail.gmail.com>
To: s7r@sky-ip.org, Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c1b03b633f00e054367f8f2
X-Spam-Status: No, score=-1.7 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 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:53:55 +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 20:38:30 -0000
--94eb2c1b03b633f00e054367f8f2
Content-Type: text/plain; charset=UTF-8
"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."
This is easily detectable as long as the network isn't heavily
partitioned(which is an assumption we make today in order for transaction
propagation to work reliably as well as for xThin and CompactBlocks to work
effectively to reduce block transmission time). Other miners would have an
incentive to intentionally orphan blocks that contained a large number of
transactions that their nodes were unaware of.
I don't think this sort of attack would last long. Even later when
subsidies are drastically reduced, you would still lose out on significant
genuine fee revenue if your orphan rate increased even 10%(one out of ten
of your poison blocks intentionally orphaned by another miner).
On Dec 11, 2016 11:12 AM, "s7r via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
t. khan wrote:
> Miners 'gaming' the Block75 system -
> There is no financial incentive for miners to attempt to game the
> Block75 system. Even if it were attempted and assuming the goal was to
> create bigger blocks, the maximum possible increase would be 25% over
> the previous block size. And, that size would only last for two weeks
> before readjusting down. It would cost them more in transaction fees to
> stuff the network than they could ever make up. To game the system,
> they'd have to game it forever with no possibility of profit.
>
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.
> Blocks would get too big -
> Eventually, blocks would get too big, but only if bandwidth stopped
> increasing and the cost of disk space stopped decreasing. Otherwise, the
> incremental adjustments made by Block75 (especially in combination with
> SegWit) wouldn't break anyone's connection or result in significantly
> more orphaned blocks.
>
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.
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 ;)
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--94eb2c1b03b633f00e054367f8f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><span style=3D"font-family:sans-serif">"You mis=
s something obvious that makes this attack actually free of cost.</span><br=
style=3D"font-family:sans-serif"><span style=3D"font-family:sans-serif">No=
thing will "cost them more in transaction fees". A miner can crea=
te</span><br style=3D"font-family:sans-serif"><span style=3D"font-family:sa=
ns-serif">thousands of transactions paying to himself, and not broadcast th=
em to</span><br style=3D"font-family:sans-serif"><span style=3D"font-family=
:sans-serif">the network, but hold them and include them in the blocks he m=
ines. The</span><br style=3D"font-family:sans-serif"><span style=3D"font-fa=
mily:sans-serif">fees are collected by him because transactions are include=
d in a block</span><br style=3D"font-family:sans-serif"><span style=3D"font=
-family:sans-serif">that he mined and the left amount is in another wallet =
of the same</span><br style=3D"font-family:sans-serif"><span style=3D"font-=
family:sans-serif">person. Repeat this continuously to fill blocks."</=
span></div><div dir=3D"auto"><font face=3D"sans-serif"><br></font></div><di=
v dir=3D"auto"><font face=3D"sans-serif">This is easily detectable as long =
as the network isn't heavily partitioned(which is an assumption we make=
today in order for transaction propagation to work reliably as well as for=
xThin and CompactBlocks to work effectively to reduce block transmission t=
ime).=C2=A0 Other miners would have an incentive to intentionally orphan bl=
ocks that contained a large number of transactions that their nodes were un=
aware of.</font></div><div dir=3D"auto"><font face=3D"sans-serif"><br></fon=
t></div><div dir=3D"auto"><font face=3D"sans-serif">I don't think this =
sort of attack would last long.=C2=A0 Even later when subsidies are drastic=
ally reduced, you would still lose out on significant genuine fee revenue i=
f your orphan rate increased even 10%(one out of ten of your poison blocks =
intentionally orphaned by another miner).<br></font><div class=3D"gmail_ext=
ra" dir=3D"auto"><br><div class=3D"gmail_quote">On Dec 11, 2016 11:12 AM, &=
quot;s7r via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">=C2=
=A0t. khan wrote:<br>
> Miners 'gaming' the Block75 system -<br>
> There is no financial incentive for miners to attempt to game the<br>
> Block75 system. Even if it were attempted and assuming the goal was to=
<br>
> create bigger blocks, the maximum possible increase would be 25% over<=
br>
> the previous block size. And, that size would only last for two weeks<=
br>
> before readjusting down. It would cost them more in transaction fees t=
o<br>
> stuff the network than they could ever make up. To game the system,<br=
>
> they'd have to game it forever with no possibility of profit.<br>
><br>
<br>
</div>This is an incentive, if few miners agree to create a large conglomer=
ate<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>
<div class=3D"quoted-text"><br>
<br>
> Blocks would get too big -<br>
> Eventually, blocks would get too big, but only if bandwidth stopped<br=
>
> increasing and the cost of disk space stopped decreasing. Otherwise, t=
he<br>
> incremental adjustments made by Block75 (especially in combination wit=
h<br>
> SegWit) wouldn't break anyone's connection or result in signif=
icantly<br>
> more orphaned blocks.<br>
><br>
<br>
</div>Topology and 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>
<br>
If you think about it the other way around, dynamically 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 ;)<br>
<br>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.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-<wbr>dev</a><br>
<br></blockquote></div><br></div></div></div>
--94eb2c1b03b633f00e054367f8f2--
|
