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
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 237B37AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:31:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A73A13F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:31:34 +0000 (UTC)
Received: by igui7 with SMTP id i7so28767032igu.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 15:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=z3JLnDH42g6oZgEF4o2GPDlqfBuELuKAYI+rp4SJKHk=;
b=Hx0fgQn21a8aT1zISpboxaaCswUqxgIUGTMo+/+SYgGcP904C+7Ylwun11NQHM0AB2
Un0XlVj/up6Fb5UJsdKkMlO/fKERIbTb+Fu2i124YdOYGAibuoUPSo+AoNCNU9h4BPGe
kb4lo0d/K5tdQXFzY5jqxOLkikjz2Bs3kGvWVvaqqw23SrYg1Ww2GwsJj7M6T5cEEjmj
ipnvqRAX7/DiG1HJpLiDbbUj/Mv3vkIvbJEZgi8zl6LDaIJqO1wl80IAHggGg1pmiP4X
tsYX1ST0QzScGI9DJ6tdwqVuSyUSytSmGA9Zp7qLsScdCIcWTGbs/shBTwssyBaP/vjF
dnOQ==
MIME-Version: 1.0
X-Received: by 10.50.88.41 with SMTP id bd9mr7036860igb.4.1439245893860; Mon,
10 Aug 2015 15:31:33 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 15:31:33 -0700 (PDT)
Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 15:31:33 -0700 (PDT)
In-Reply-To: <CAKzdR-rr6TACfxt84SeKWdbP=8YsFtDsc7DTSriiFjeffbbTiQ@mail.gmail.com>
References: <CAKzdR-o7_A2N=-=3muXcs7ptnoO2d3wSBAMAziNGs7XjnceGBQ@mail.gmail.com>
<CAPg+sBjRFTZxOOg8ZUhTVqbZDJusZ4xyooRh1LcvwbBDSLu1oA@mail.gmail.com>
<CAKzdR-rr6TACfxt84SeKWdbP=8YsFtDsc7DTSriiFjeffbbTiQ@mail.gmail.com>
Date: Tue, 11 Aug 2015 00:31:33 +0200
Message-ID: <CAPg+sBi3pvrbxH6uM0pcOqvZVjOWU0LACRtQe5pps5Jv4-3eXA@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: multipart/alternative; boundary=089e013cb9843f84e3051cfc8c0e
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] If you had a single chance to double the
transactions/second Bitcoin allows...
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Mon, 10 Aug 2015 22:31:35 -0000
--089e013cb9843f84e3051cfc8c0e
Content-Type: text/plain; charset=UTF-8
On Aug 11, 2015 12:11 AM, "Sergio Demian Lerner" <sergio.d.lerner@gmail.com>
wrote:
> What I'm saying is that this ratio may have improved 20x since miners
began using the TheBlueMatt relay network, so deteriorating the ratio 2x
does not put miners in a unknown future, but in an future which is far
better than the state they were a year ago.
It's still worse than doubling the block size, which was your main argument.
> But SPV mining has improved the ratio another 2x (because headers can be
pushed even faster, fit in a single network packet, and can do without
inv/getdata round-trips because they basically "pay" for the bandwidth
usage by its own proof of work).
> With a better wire protocol you can "propagate" a 10 MB block faster that
the time it takes currently to propagate an empty block.
> So 10x deterioration of the ratio would be still something acceptable.
So yes, better relay protocols (whether you consider "SPV mining" a form of
that or not) reduce the effect of the block size. That does not give any
benefit for reduced interblock times.
Your argument seems to be "centralization pressure is not bad now, because
it already improved a lot... so we can make it worse again by reducing
interblock time"? I disagree that it is not bad, and shorter blocks have
other downsides which were already mentioned.
>> Also, you seem to consider SPV mining a good thing?
>
> I'm not saying it's a good thing. I'm saying that it's impossible to
avoid. It's a real incentive. It must exists so Bitcoin is incentive
compatible. We can talk for hours and hours and we won't prevent miners
from doing it. I predicted it back in 2013, without even being a miner
myself. It's here to stay. Forever. It's a pity Greg chose that awful name
of "SPV" mining instead some cool name like "Instant" mining that we could
market as Bitcoin latest feature :)
>> It requires trust between miners that know eachother, and fundamentally
breaks the security assumption of SPV clients...
>
> No is does not.
The SPV security assumption is that no hashrate majority will collude in
order to make my transactions incorrectly look confirmed.
With validation-less mining, even a 0.1% hashrate that is part of a group
with 60% hashrate is enough to make that happen.
Of course they won't intentionally do that. No other miner would agree to
do validation-less mining with them again, making it harder for them to
compete. So it is not permissionless: you get higher profitability by
making an agreement with the largest hashrate. I think that is a much worse
centralization effect than having an optional centralized relay network
available... there could even be multiple such networks.
> The incentive follows directly from the cheating cost (the subsidy). Even
if I don't know you, I know you wouldn't waste 25 BTC to try to cheat me
for 25 BTC with a probability of 1/100, that's for sure. On average, you
loose 24.75 BTC per cheat attempt.
Per cheat attempt, or per bug.
> SPV mining incentive will stay until there is no subsidy, as many other
incentives. SPV mining also must be there to prevent malicious actors from
DoS-ing the relay network. If it's there, then the DoS incentive disappears.
>
> Let's code "instant" mining into Bitcoin Core, and do it right.
I thought about this too. Since headers-first it would be trivial to do: if
our best header is ahead of our best block, hand out an empty template in
createblocktemplate, and we're done.
Unfortunately, Greg Maxwell pointed out that this (even with a time limit)
amplifies selfish mining, since I can propagate headers before propagating
blocks, in order to make others temporarily work on top of my chain.
> Also as Michael Rudy points out, higher block rate means lower variance,
and that's good for miners. Last, as I already said, having a lower average
block interval strengthens Bitcoin value proposition, so miners would be
delighted that their bitcoins are more worthy.
Only a small constant factor, but yes.
--
Pieter
--089e013cb9843f84e3051cfc8c0e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Aug 11, 2015 12:11 AM, "Sergio Demian Lerner" <<a href=3D"m=
ailto:sergio.d.lerner@gmail.com">sergio.d.lerner@gmail.com</a>> wrote:<b=
r>
> What I'm saying is that this ratio may have improved 20x since min=
ers began using the TheBlueMatt relay network, so deteriorating the ratio 2=
x does not put miners in a unknown future, but in an future which is far be=
tter than the state they were a year ago.</p>
<p dir=3D"ltr">It's still worse than doubling the block size, which was=
your main argument.</p>
<p dir=3D"ltr">> But SPV mining has improved the ratio another 2x (becau=
se headers can be pushed even faster, fit in a single network packet, and c=
an do without inv/getdata round-trips because they basically "pay"=
; for the bandwidth usage by its own proof of work).=C2=A0<br>
> With a better wire protocol you can "propagate" a 10 MB bloc=
k faster that the time it takes currently to propagate an empty block.=C2=
=A0<br>
> So 10x deterioration of the ratio would be still something acceptable.=
</p>
<p dir=3D"ltr">So yes, better relay protocols (whether you consider "S=
PV mining" a form of that or not) reduce the effect of the block size.=
That does not give any benefit for reduced interblock times.</p>
<p dir=3D"ltr">Your argument seems to be "centralization pressure is n=
ot bad now, because it already improved a lot... so we can make it worse ag=
ain by reducing interblock time"? I disagree that it is not bad, and s=
horter blocks have other downsides which were already mentioned.</p>
<p dir=3D"ltr">>> Also, you seem to consider SPV mining a good thing?=
<br>
><br>
> I'm not saying it's a good thing. I'm saying that it's=
impossible to avoid. It's a real incentive. It must exists so Bitcoin =
is incentive compatible. We can talk for hours and hours and we won't p=
revent miners from doing it. I predicted it back in 2013, without even bein=
g a miner myself. It's here to stay. Forever. It's a pity Greg chos=
e that awful name of "SPV" mining instead some cool name like &qu=
ot;Instant" mining that we could market as Bitcoin latest feature :)</=
p>
<p dir=3D"ltr">>> It requires trust between miners that know eachothe=
r, and fundamentally breaks the security assumption of SPV clients...<br>
><br>
> No is does not.</p>
<p dir=3D"ltr">The SPV security assumption is that no hashrate majority wil=
l collude in order to make my transactions incorrectly look confirmed.</p>
<p dir=3D"ltr">With validation-less mining, even a 0.1% hashrate that is pa=
rt of a group with 60% hashrate is enough to make that happen.</p>
<p dir=3D"ltr">Of course they won't intentionally do that. No other min=
er would agree to do validation-less mining with them again, making it hard=
er for them to compete. So it is not permissionless: you get higher profita=
bility by making an agreement with the largest hashrate. I think that is a =
much worse centralization effect than having an optional centralized relay =
network available... there could even be multiple such networks.</p>
<p dir=3D"ltr">> The incentive follows directly from the cheating cost (=
the subsidy). Even if I don't know you, I know you wouldn't waste 2=
5 BTC to try to cheat me for 25 BTC with a probability of 1/100, that's=
for sure. On average, you loose 24.75 BTC per cheat attempt.</p>
<p dir=3D"ltr">Per cheat attempt, or per bug.</p>
<p dir=3D"ltr">> SPV mining incentive will stay until there is no subsid=
y, as many other incentives. SPV mining also must be there to prevent malic=
ious actors from DoS-ing the relay network. If it's there, then the DoS=
incentive disappears.<br>
><br>
> Let's code "instant" mining into Bitcoin Core, and do it=
right.</p>
<p dir=3D"ltr">I thought about this too. Since headers-first it would be tr=
ivial to do: if our best header is ahead of our best block, hand out an emp=
ty template in createblocktemplate, and we're done.</p>
<p dir=3D"ltr">Unfortunately, Greg Maxwell pointed out that this (even with=
a time limit) amplifies selfish mining, since I can propagate headers befo=
re propagating blocks, in order to make others temporarily work on top of m=
y chain.</p>
<p dir=3D"ltr">> Also as Michael Rudy points out, higher block rate mean=
s lower variance, and that's good for miners. Last, as I already said, =
having a lower average block interval strengthens Bitcoin value proposition=
, so miners would be delighted that their bitcoins are more worthy.</p>
<p dir=3D"ltr">Only a small constant factor, but yes.</p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>
--089e013cb9843f84e3051cfc8c0e--
|
