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
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
|
Return-Path: <keatonatron@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 78CA24A5
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Dec 2016 21:54:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com
[209.85.220.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9D99F141
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Dec 2016 21:54:09 +0000 (UTC)
Received: by mail-qk0-f173.google.com with SMTP id n21so9661400qka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 18 Dec 2016 13:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=pxgwrgVYS2UmNsS5q0L651tLmKM0It0U2wt72yB68mQ=;
b=koSaCuHnWZXFJ5wYIlBw0oJs5DpQm9w59/uxEShzYuL63pwVwXiSBsY/vepxRsKd4n
HWz1gUZwoxA3GMkt223qV9L6PheVkxG1vnB7pR7kNGYeZf8IC4wcFqCYl1CiK28lgGk7
gqr4dlvVFsjanVCP15FO2yd39HKtgCzToRG/98ABPm+QRjAOeXd/H3LfqmGIeTPYf1Be
s3ZtPbdNk1wC4mVj3RQQYr1t4U5x6YTljq7ZTzlghTgGjllDfZd7xucWeuvuVLLjM/OK
NIxBAxWr3NtOVVsJgDyndvQTceSM/pLfaFv9Yl11L6gWUjuVBJ3ehC/M45McQ3PsQa5B
ADSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=pxgwrgVYS2UmNsS5q0L651tLmKM0It0U2wt72yB68mQ=;
b=gr0LGCtQ5uHzod8ZURCbVcmov8ntwBXKApw/P6uX75AdM8cLAyjp3OYpXsh2kFPbjN
Q8H4eWFP3P27UG6lLNf7XOyCsarKwYUzHPLrcdoqx0Jp0rh0/pPAAS3iYtL44cEPqFuP
bOhhpKc5w+wBw/gf6Zhtzo2fi5v56kPq8bg+461NStoyrDWFeqlfCLMBvRXA7VqOjcF6
JEbRVBhoPQbJKYzt6NcHOZgJhthLPMksKIf+N8UuHiVjV//jZcCrhO0K7oUkzs9xhsvw
a2Cqmab2GtAW5Fxe5hGGS7PiJI72/FX4UYuICc7kVyxAttApuebN0GoUlxenz+t38jsT
ClFQ==
X-Gm-Message-State: AIkVDXJBPH2Gk2a09gOYhbXWbfPYMBVS2xRXwS198waZBpQmtqVwm5FAmJvayxapChHLRZZMeWzvyRbPaWRbCw==
X-Received: by 10.55.221.79 with SMTP id n76mr590488qki.276.1482098048469;
Sun, 18 Dec 2016 13:54:08 -0800 (PST)
MIME-Version: 1.0
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>
<CAAy62_KLAJ2OOv863HB4CzoAr7QOURRMFF2pH2pGUVQ9gMpecg@mail.gmail.com>
<8679ecea-b449-0f5a-d4d7-1f23ae6e29b2@sky-ip.org>
In-Reply-To: <8679ecea-b449-0f5a-d4d7-1f23ae6e29b2@sky-ip.org>
From: James MacWhyte <macwhyte@gmail.com>
Date: Sun, 18 Dec 2016 21:53:57 +0000
Message-ID: <CAH+Axy7H547kSh8y7OHzGRh0a=o0FDZ7N0eG3f5oAMTUGKJ-Fw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11499f94b392ac0543f5d7ce
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
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, 18 Dec 2016 21:54:11 -0000
--001a11499f94b392ac0543f5d7ce
Content-Type: text/plain; charset=UTF-8
Hi All,
I'm coming late to the party. I like the Block75 proposal.
Multiple people have said miners would/could stuff blocks with insincere
transactions to increase the block size, but it was never adequately
explained what they would gain from this. If there aren't enough legitimate
transactions to fill up the block, where do you plan to earn extra income
once the block is bigger?
Miners would be incentivized to include as many legitimate transactions as
possible, but if propagation time is as big an issue as some of you have
said it is, miners would also be incentivized to keep their blocks small
enough to propagate. So why not give them the choice? Once the block size
gets too big to propagate effectively, miners would be naturally
incentivized to limit how much data they put in each block, finding the
perfect balance.
In my opinion, none of the downsides presented so far have been a good
argument. Risk of a 51% attack is not unique to this proposal, saying "we
could also do that with hardcoded limits" doesn't actually point out any
problem with this proposal, and miners already have the ability to add or
withhold transactions from their blocks.
We trust our miners to serve us by acting in their own best interests, and
this proposal simply gives them more options for doing that. If anyone can
make a strong argument against that would earn top marks in a high school
debate class, I'd love to hear it!
James
On Sun, Dec 11, 2016 at 3:23 PM s7r via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Andrew Johnson wrote:
> > "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).
> >
>
> I disagree.
>
> I didn't say this is impossible to detect, but it is hard to act against
> it. One miner orphaning the block intentionally is very unlikely if that
> miner acts rationally. It would only make sense if 51% of the hash rate
> would intentionally orphan it. Otherwise the miner who intentionally
> orphans a valid block, let's say block X, has to continue to mine one in
> its place on top of block X-1, and by the time he finds one:
>
> a) his block X' is rejected by other miners because they already have a
> valid block X on top of which they already started to mine;
>
> b) block X+1 was already found and broadcasted, so the miner who
> orphaned X intentionally is on the shorter chain ignored by the network.
>
> So, one miner cannot do anything about it. Even a pool cannot do
> anything about it, because the loss is greater. You need 51% of the hash
> rate to intentionally orphan it, and all the miners forming 51% need to
> be colluding and know for sure that every one will intentionally orphan
> the said block, otherwise there's a huge risk of loss for who does it.
> Nobody would gamble to do this (I am not sure if gambling is the right
> word, since the loss is 100% sure here). But, we are not discussing 51%
> attacks because those are a different topic.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a11499f94b392ac0543f5d7ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi All,<div><br></div><div>I'm coming late to the part=
y. I like the Block75 proposal.</div><div><br></div><div>Multiple people ha=
ve said miners would/could stuff blocks with insincere transactions to incr=
ease the block size, but it was never adequately explained what they would =
gain from this. If there aren't enough legitimate transactions to fill =
up the block, where do you plan to earn extra income once the block is bigg=
er?</div><div><br></div><div>Miners would be incentivized to include as man=
y legitimate transactions as possible, but if propagation time is as big an=
issue as some of you have said it is, miners would also be incentivized to=
keep their blocks small enough to propagate. So why not give them the choi=
ce? Once the block size gets too big to propagate effectively, miners would=
be naturally incentivized to limit how much data they put in each block, f=
inding the perfect balance.</div><div><br></div><div>In my opinion, none of=
the downsides presented so far have been a good argument. Risk of a 51% at=
tack is not unique to this proposal, saying "we could also do that wit=
h hardcoded limits" doesn't actually point out any problem with th=
is proposal, and miners already have the ability to add or withhold transac=
tions from their blocks.</div><div><br></div><div>We trust our miners to se=
rve us by acting in their own best interests, and this proposal simply give=
s them more options for doing that. If anyone can make a strong argument ag=
ainst that would earn top marks in a high school debate class, I'd love=
to hear it!</div><div><br></div><div>James</div><div><br><div class=3D"gma=
il_quote"><div dir=3D"ltr">On Sun, Dec 11, 2016 at 3:23 PM s7r via bitcoin-=
dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">Andrew Johnson wrote:<br class=3D"gmail_msg">
> "You miss something obvious that makes this attack actually free =
of cost.<br class=3D"gmail_msg">
> Nothing will "cost them more in transaction fees". A miner c=
an create<br class=3D"gmail_msg">
> thousands of transactions paying to himself, and not broadcast them to=
<br class=3D"gmail_msg">
> the network, but hold them and include them in the blocks he mines. Th=
e<br class=3D"gmail_msg">
> fees are collected by him because transactions are included in a block=
<br class=3D"gmail_msg">
> that he mined and the left amount is in another wallet of the same<br =
class=3D"gmail_msg">
> person. Repeat this continuously to fill blocks."<br class=3D"gma=
il_msg">
><br class=3D"gmail_msg">
> This is easily detectable as long as the network isn't heavily<br =
class=3D"gmail_msg">
> partitioned(which is an assumption we make today in order for<br class=
=3D"gmail_msg">
> transaction propagation to work reliably as well as for xThin and<br c=
lass=3D"gmail_msg">
> CompactBlocks to work effectively to reduce block transmission time).<=
br class=3D"gmail_msg">
> Other miners would have an incentive to intentionally orphan blocks th=
at<br class=3D"gmail_msg">
> contained a large number of transactions that their nodes were unaware=
of.<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> I don't think this sort of attack would last long.=C2=A0 Even late=
r when<br class=3D"gmail_msg">
> subsidies are drastically reduced, you would still lose out on<br clas=
s=3D"gmail_msg">
> significant genuine fee revenue if your orphan rate increased even<br =
class=3D"gmail_msg">
> 10%(one out of ten of your poison blocks intentionally orphaned by<br =
class=3D"gmail_msg">
> another miner).<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I disagree.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I didn't say this is impossible to detect, but it is hard to act agains=
t<br class=3D"gmail_msg">
it. One miner orphaning the block intentionally is very unlikely if that<br=
class=3D"gmail_msg">
miner acts rationally. It would only make sense if 51% of the hash rate<br =
class=3D"gmail_msg">
would intentionally orphan it. Otherwise the miner who intentionally<br cla=
ss=3D"gmail_msg">
orphans a valid block, let's say block X, has to continue to mine one i=
n<br class=3D"gmail_msg">
its place on top of block X-1, and by the time he finds one:<br class=3D"gm=
ail_msg">
<br class=3D"gmail_msg">
a) his block X' is rejected by other miners because they already have a=
<br class=3D"gmail_msg">
valid block X on top of which they already started to mine;<br class=3D"gma=
il_msg">
<br class=3D"gmail_msg">
b) block X+1 was already found and broadcasted, so the miner who<br class=
=3D"gmail_msg">
orphaned X intentionally is on the shorter chain ignored by the network.<br=
class=3D"gmail_msg">
<br class=3D"gmail_msg">
So, one miner cannot do anything about it. Even a pool cannot do<br class=
=3D"gmail_msg">
anything about it, because the loss is greater. You need 51% of the hash<br=
class=3D"gmail_msg">
rate to intentionally orphan it, and all the miners forming 51% need to<br =
class=3D"gmail_msg">
be colluding and know for sure that every one will intentionally orphan<br =
class=3D"gmail_msg">
the said block, otherwise there's a huge risk of loss for who does it.<=
br class=3D"gmail_msg">
Nobody would gamble to do this (I am not sure if gambling is the right<br c=
lass=3D"gmail_msg">
word, since the loss is 100% sure here). But, we are not discussing 51%<br =
class=3D"gmail_msg">
attacks because those are a different topic.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div></div></div>
--001a11499f94b392ac0543f5d7ce--
|
