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
|
Return-Path: <ibrightly@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8F1E4ACB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 22:01:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
[209.85.218.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E243A14C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 22:01:14 +0000 (UTC)
Received: by oiax193 with SMTP id x193so84667862oia.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 15:01:14 -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=TMKCF6Cg8MPfsnKgE4LP7G/Yp0pqWFNDSuq5I5PvZ7s=;
b=jWw08uXdF/QCWaDCOZ/A+kb6/zO18oS4jr7bTihg7eev60Hq8EOztrOnFHf6rxmQ/u
YXwZU02w/6mVqpzu3FAch3RvEw/ev3kU37Ep3YZy28NIA/QNny/6mQvbEuscofu2iX3Q
BMBkAxkfdRmcqB8MKOG7HXIcbHZ3tc/YuOMsRSuuYz7yre+hFlqG55ilYe3BsDlN5kPw
524WaRy+zy7ptpKL3vIIsi2/vHMKVOAD14YNy5kiNcmrV5biEkhki7tOMalrfgkqmfOr
xjUxN6XPQHTHjF99By6zWVvMZg07Ts+O7Fxk6DRk1N2TFKUO7Ou8Yi5Ye/ToZt0KJOZs
OgeA==
MIME-Version: 1.0
X-Received: by 10.60.178.33 with SMTP id cv1mr3304907oec.11.1435356074402;
Fri, 26 Jun 2015 15:01:14 -0700 (PDT)
Received: by 10.76.177.164 with HTTP; Fri, 26 Jun 2015 15:01:14 -0700 (PDT)
In-Reply-To: <20150626190739.GB10387@muck>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<20150623192838.GG30235@muck>
<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
<20150623204646.GA18677@muck>
<CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
<20150626190739.GB10387@muck>
Date: Fri, 26 Jun 2015 18:01:14 -0400
Message-ID: <CAAre=yREUeBCrB7=WH2yWsxnCEwKWo_BOMbbavvHfpQeKgDpBA@mail.gmail.com>
From: Ivan Brightly <ibrightly@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e01182252f0e90b051972e0cc
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: Fri, 26 Jun 2015 22:01:15 -0000
--089e01182252f0e90b051972e0cc
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 26, 2015 at 3:08 PM, Peter Todd <pete@petertodd.org> wrote:
> On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> > 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).
>
> "Just rent a server" forces miners into deploying insecure hosted
> infrastructure that's vulnerable to hacking and seizure; that we
> encourage this already is worrying; requiring it for miners to be
> profitable isn't acceptable.
>
There are a number of factors that contribute to mining vulnerabilities.
For example, presuming a miner is a meaningful contributor to the network,
they'll be using more electricity than their neighbors and will be easily
identifiable in the same way illegal grow-houses are identified by the
local power company working with authorities. A hacked or seized hosted
server is far easier to recover from than seized equipment. Its hard to see
how requiring a reasonably reliable internet connection is a particularly
high barrier to entry when compared to the other mining requirements, such
as funds to purchase ASICs, competitive electricity costs, reasonable
belief that equipment won't be stolen or seized, the technical knowledge
for setting up a p2pool node, etc.
--089e01182252f0e90b051972e0cc
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 F=
ri, Jun 26, 2015 at 3:08 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">On Tue, Jun 23, 2015 at 05:24:23=
PM -0400, Gavin Andresen wrote:<br>
> On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>> wrote:<br>
><br>
> > Pieter Wuille showed with simulations that miners with bad connec=
tivity<br>
> > are negatively affected by other miners creating larger blocks.<b=
r>
> ><br>
><br>
> ... but the effect is only significant if they have an absurdly<br>
> low-bandwidth connection and do NOTHING to work around it (like rent a=
<br>
> server on the other side of the bandwidth bottleneck and write some co=
de to<br>
> make sure you're creating blocks that will propagate quickly on bo=
th sides<br>
> of the bottleneck).<br>
<br>
"Just rent a server" forces miners into deploying insecure hosted=
<br>
infrastructure that's vulnerable to hacking and seizure; that we<br>
encourage this already is worrying; requiring it for miners to be<br>
profitable isn't acceptable.<br></blockquote><div><br></div><div>There =
are a number of factors that contribute to mining vulnerabilities. For exam=
ple, presuming a miner is a meaningful contributor to the network, they'=
;ll be using more electricity than their neighbors and will be easily ident=
ifiable in the same way illegal grow-houses are identified by the local pow=
er company working with authorities. A hacked or seized hosted server is fa=
r easier to recover from than seized equipment. Its hard to see how requiri=
ng a reasonably reliable internet connection is a particularly high barrier=
to entry when compared to the other mining requirements, such as funds to =
purchase ASICs, competitive electricity costs, reasonable belief that equip=
ment won't be stolen or seized, the technical knowledge for setting up =
a p2pool node, etc.</div></div></div></div>
--089e01182252f0e90b051972e0cc--
|
