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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82931273
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 21:24:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f45.google.com (mail-la0-f45.google.com
[209.85.215.45])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79E34118
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 21:24:25 +0000 (UTC)
Received: by lacny3 with SMTP id ny3so14607697lac.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 14:24:23 -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=ArbjCaYZPa/P8UZROjmm/99eHsK14JvohnbtZbI+t/A=;
b=YI0074u5fNIQztBUKI6LNoqZ1OXdXCCLBmJfBXhv13HXkfwTLPNCAmKm81a5DXoXjM
cq5IOMKTTIJq+TGc17Ph5EzTd9pm41yB2UReG+9VI38FX+wc7A7enXfbwV0u0bFbdhrR
TrVy8Gv9zJItyQHroVp4Jch/IOB5mgHMvL1B4UABoORhXLQCx0SdxkoGeQjaRqvBQUIy
IscgI0DXyAIYb3F6CwtZVeyMYb2SjbubG0GEVa3z5rHl0JDAZ/7FUPWWIEqtBWaqM3kE
9tVyJDQz/xkjSSaLjCsbSJ6HaAicno1qva+P0QHpeRBXtQFHzgOy5pUqWIZCrzgdU5on
XpQg==
MIME-Version: 1.0
X-Received: by 10.112.55.70 with SMTP id q6mr35255767lbp.99.1435094663730;
Tue, 23 Jun 2015 14:24:23 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Tue, 23 Jun 2015 14:24:23 -0700 (PDT)
In-Reply-To: <20150623204646.GA18677@muck>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<20150623192838.GG30235@muck>
<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
<20150623204646.GA18677@muck>
Date: Tue, 23 Jun 2015 17:24:23 -0400
Message-ID: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a1133d13ca69d63051936034c
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@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
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: Tue, 23 Jun 2015 21:24:26 -0000
--001a1133d13ca69d63051936034c
Content-Type: text/plain; charset=UTF-8
On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd.org> wrote:
> Pieter Wuille showed with simulations that miners with bad connectivity
> are negatively affected by other miners creating larger blocks.
>
... but the effect is only significant if they have an absurdly
low-bandwidth connection and do NOTHING to work around it (like rent a
server on the other side of the bandwidth bottleneck and write some code to
make sure you're creating blocks that will propagate quickly on both sides
of the bottleneck).
Why do you think connectivity is a centralizing effect? It is just one
factor in the profitability-of-mining equation. A location with bad
connectivity (the US, maybe) but 10% cheaper electricity might be just as
good as one with great connectivity but more expensive electricity.
Having lots of variables in the profitability equation is a decentralizing
force, it means there is very likely to be several different places in the
world / on the net where mining is equally profitable.
> ... until transaction fees become significant. But by the time that
> > happens, protocol optimizations of block propagation will make the block
> > size an insignificant term in the "how profitable is it to mine in THIS
> > particular place on the Internet / part of the world" equation.
>
> These block propagation improvements are both already implemented (Matt
> Corallo's relay network, p2pool) and require co-operation.
>
Long term the p2p protocol will evolve to incorporate those optimizations,
so will require no co-operation.
> For instance, notice the recent full-RBF debate where Coinbase said
> they'd consider getting contracts directly with miners to get
> transactions they desired mined even when they otherwise would not be
> due to double-spends. This is one of many scenarios where block
> propagation improvements fail. Thus for a safety engineering
> analysis we need to talk about worst-case scenarioss
> Equally, I don't see any analysis from anyone of that % of non-optimized
> transactions need to fail for what kind of centralizing pressure.
>
> In any case, this ponts to the need for your proposal to explictly talk
> about what kind of resources are needed by miners for what kind of
> profitability, including the case where other miners are sabotaging
> their profitability.
>
Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?
I have written quite a lot about the kind of resources needed to run a full
node, and have asked you, specifically, several times "how much do you
think is too much" and received no answer.
--
--
Gavin Andresen
--001a1133d13ca69d63051936034c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 23, 2015 at 4:46 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">Pieter Wuille showed with simula=
tions that miners with bad connectivity<br>
are negatively affected by other miners creating larger blocks.<br></blockq=
uote><div><br></div><div>... but the effect is only significant if they hav=
e an absurdly low-bandwidth connection and do NOTHING to work around it (li=
ke rent a server on the other side of the bandwidth bottleneck and write so=
me code to make sure you're creating blocks that will propagate quickly=
on both sides of the bottleneck).</div><div><br></div><div><br></div><div>=
Why do you think connectivity is a centralizing effect? It is just one fact=
or in the profitability-of-mining equation. A location with bad connectivit=
y (the US, maybe) but 10% cheaper electricity might be just as good as one =
with great connectivity but more expensive electricity.</div><div><br></div=
><div>Having lots of variables in the profitability equation is a decentral=
izing force, it means there is very likely to be several different places i=
n the world / on the net where mining is equally profitable.</div><div><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"><span class=3D"">> .=
.. until transaction fees become significant.=C2=A0 But by the time that<br=
>
> happens, protocol optimizations of block propagation will make the blo=
ck<br>
> size an insignificant term in the "how profitable is it to mine i=
n THIS<br>
> particular place on the Internet / part of the world" equation.<b=
r>
<br>
</span>These block propagation improvements are both already implemented (M=
att<br>
Corallo's relay network, p2pool) and require co-operation.<br></blockqu=
ote><div><br></div><div>Long term the p2p protocol will evolve to incorpora=
te those optimizations, so will require no co-operation.</div><div><br></di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">For instance, notice the =
recent full-RBF debate where Coinbase said<br>
they'd consider getting contracts directly with miners to get<br>
transactions they desired mined even when they otherwise would not be<br>
due to double-spends. This is one of many scenarios where block<br>
propagation improvements fail. Thus for a safety engineering<br>
analysis we need to talk about worst-case scenarioss</blockquote><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
Equally, I don't see any analysis from anyone of that % of non-optimize=
d<br>
transactions need to fail for what kind of centralizing pressure.<br>
<br>
In any case, this ponts to the need for your proposal to explictly talk<br>
about what kind of resources are needed by miners for what kind of<br>
profitability, including the case where other miners are sabotaging<br>
their profitability.<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><div=
class=3D"gmail_extra"><br></div>Are you familiar with the terms "Gish=
Gallop" and "Moving the Goalposts" ?<br><br>I have written =
quite a lot about the kind of resources needed to run a full node, and have=
asked you, specifically, several times "how much do you think is too =
much" and received no answer.<br clear=3D"all"><div><br></div>-- <br><=
div class=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div></div>
--001a1133d13ca69d63051936034c--
|
