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
|
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 959AF7AD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:11:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com
[209.85.214.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9686BE8
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 22:11:50 +0000 (UTC)
Received: by obbhe7 with SMTP id he7so38579610obb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 15:11:50 -0700 (PDT)
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:content-type;
bh=jc/hzgVwsqs4W9v919laOvkzbwiUbK0tyAGqCQkU8bM=;
b=vMICo6laEMioBPNMDtC20b86D8pXW00cLqocD9fjW2ftURhGY0QQb50B3ZM1QgGwXi
+szpqXLdl6NBNM7winMoF4wzhp8druIIT3m7JCUv+WdrPyWeHh6RdtBUgZfRPhvCxb+v
GfvIpCbtjx1jrlHYAi/6VhidY1HYeiN/P+Hn9XZ5KHHspLwltKFtjUobUjRM+RtHybVA
qXLqLewn9/4eFd7quGRtozHqs4SFoxRFW6HpGfdoeggTZoEgVQaHzB2pJUg4JU/IgXCC
WmvnGHzSZ0mkRHmqp8S+DlnVC/YyutVikgQzr9x4Y4ibeqquDpqnsl0FxoY1Mp4vtEE3
syMw==
X-Received: by 10.182.108.170 with SMTP id hl10mr21152928obb.17.1439244710008;
Mon, 10 Aug 2015 15:11:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.116.207 with HTTP; Mon, 10 Aug 2015 15:11:10 -0700 (PDT)
In-Reply-To: <CAPg+sBjRFTZxOOg8ZUhTVqbZDJusZ4xyooRh1LcvwbBDSLu1oA@mail.gmail.com>
References: <CAKzdR-o7_A2N=-=3muXcs7ptnoO2d3wSBAMAziNGs7XjnceGBQ@mail.gmail.com>
<CAPg+sBjRFTZxOOg8ZUhTVqbZDJusZ4xyooRh1LcvwbBDSLu1oA@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Mon, 10 Aug 2015 19:11:10 -0300
Message-ID: <CAKzdR-rr6TACfxt84SeKWdbP=8YsFtDsc7DTSriiFjeffbbTiQ@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=089e0149d294af5ed5051cfc45a2
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_20,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:11:51 -0000
--089e0149d294af5ed5051cfc45a2
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > b. Reduce the block rate to a half (average 5 minute blocks)
> >
> > Suppose this is a one time hard fork. There no drastic technical
> problems with any of them: "SPV" mining and the relay network has shown
> that block propagation is not an issue for such as small change. Mining
> centralization won't radically change for a 2x adjustment.
>
> I don't understand this. All problems that result from propagation delay
> are literally doubled by doing so. Centralization pressure results from the
> ratio between propagation time and interblock time. Efficient propagation
> algorithms like the relay network make this presumably grow sublinear with
> larger blocks, but changing the interblock time affects it exactly
> proportionally.
>
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.
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.
All problems that result from propagation delay are literally doubled by
> doing this. Doubling the block size has a smaller effect. You may argue
> that these centralization effects are small, but reducing the interblock
> time has a stronger effect on them than the block size.
>
> 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 :)
Do you consider the TheBlueMatt relay network a "good thing". NO! It's a
very bad centralization thing, but it is unavoidable. I would like the
relay network to be embedded on the standard network protocol, using local
route optimizations to reduce latency for block propagation (there is one
old paper on this, and it says that with local prioritization you can have
a lower bound to get a propagation latency of at most two times the optimal
value (possibly generated by the minimum spanning tree)).
It requires trust between miners that know eachother, and fundamentally
> breaks the security assumption of SPV clients...
>
No is does not. 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.
"SPV" mining is safe as long as it is done for a certain bounded period of
time and bounded number of blocks (e.g: 30 seconds from that last validated
block, and no more than 1 non-validated block). SPV clients that accept a
transaction with 1 confirmation are already in danger of orphaning, and
long invalid "SPV" mining chain forks (as occurred last month) should never
had occurred if limits were in-place.
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.
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.
--089e0149d294af5ed5051cfc45a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille <span dir=3D"ltr"><<a=
href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gm=
ail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D""><p dir=3D"ltr">On Aug 7, 2015 11:19 PM, "Sergio Demian Lerner vi=
a bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote=
:<br>
> b. Reduce the block rate to a half (average 5 minute blocks)<br>
><br>
> Suppose this is a one time hard fork. There no drastic technical probl=
ems with any of them: "SPV" mining and the relay network has show=
n that block propagation is not an issue for such as small change. Mining c=
entralization won't radically change for a 2x adjustment.=C2=A0</p>
</span><p dir=3D"ltr">I don't understand this. All problems that result=
from propagation delay are literally doubled by doing so. Centralization p=
ressure results from the ratio between propagation time and interblock time=
. Efficient propagation algorithms like the relay network make this presuma=
bly grow sublinear with larger blocks, but changing the interblock time aff=
ects it exactly proportionally.</p></blockquote><div>What I'm saying is=
that this ratio may have improved 20x since miners began using the TheBlue=
Matt 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 we=
re a year ago.</div><div><br></div><div>But SPV mining has improved the rat=
io another 2x (because headers can be pushed even faster, fit in a single n=
etwork packet, and can do without inv/getdata round-trips because they basi=
cally "pay" for the bandwidth usage by its own proof of work).=C2=
=A0</div><div>With a better wire protocol you can "propagate" a 1=
0 MB block faster that the time it takes currently to propagate an empty bl=
ock.=C2=A0</div><div>So 10x deterioration of the ratio would be still somet=
hing acceptable.<br></div><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">All problems that result from propagation delay are literall=
y doubled by doing this. Doubling the block size has a smaller effect. You =
may argue that these centralization effects are small, but reducing the int=
erblock time has a stronger effect on them than the block size.</p>
<p dir=3D"ltr">Also, you seem to consider SPV mining a good thing? </p></bl=
ockquote><div>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 wo=
n'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 fea=
ture :)</div><div><br></div><div>Do you consider the TheBlueMatt relay netw=
ork a "good thing". NO! It's a very bad centralization thing,=
but it is unavoidable. I would like the relay network to be embedded on th=
e standard network protocol, using local route optimizations to reduce late=
ncy for block propagation (there is one old paper on this, and it says that=
with local prioritization you can have a lower bound to get a propagation =
latency of at most two times the optimal value (possibly generated by the m=
inimum spanning tree)).</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<p dir=3D"ltr">It requires trust between miners that know eachother, and fu=
ndamentally breaks the security assumption of SPV clients... </p></blockquo=
te><div>No is does not. The incentive follows directly from the cheating co=
st (the subsidy). Even if I don't know you, I know you wouldn't was=
te 25 BTC to try to cheat me for 25 BTC with a probability of 1/100, that&#=
39;s for sure. On average, you loose 24.75 BTC per cheat attempt.</div><div=
><br></div><div>"SPV" mining is safe as long as it is done for a =
certain bounded period of time and bounded number of blocks (e.g: 30 second=
s from that last validated block, and no more than 1 non-validated block). =
SPV clients that accept a transaction with 1 confirmation are already in da=
nger of orphaning, and long invalid "SPV" mining chain forks (as =
occurred last month) should never had occurred if limits were in-place.</di=
v><div><br></div><div>SPV mining incentive will stay until there is no subs=
idy, as many other incentives. SPV mining also must be there to prevent mal=
icious actors from DoS-ing the relay network. If it's there, then the D=
oS incentive disappears.</div><div><br></div><div>Let's code "inst=
ant" mining into Bitcoin Core, and do it right.</div><div><br></div><d=
iv>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 av=
erage block interval strengthens Bitcoin value proposition, so miners would=
be delighted that their bitcoins are more worthy.</div><div><br></div><div=
><br></div></div></div></div>
--089e0149d294af5ed5051cfc45a2--
|
