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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5418D83D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 19:08:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com
[62.13.148.98])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id ECE6013F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 19:08:14 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5QJ8BnL004010;
Fri, 26 Jun 2015 20:08:11 +0100 (BST)
Received: from muck (static-71-247-144-172.nycmny.east.verizon.net
[71.247.144.172]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5QJ87Ev036076
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 26 Jun 2015 20:08:10 +0100 (BST)
Date: Fri, 26 Jun 2015 15:08:07 -0400
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="2/5bycvrmDh4d1IB"
Content-Disposition: inline
In-Reply-To: <CABsx9T3-CbB0k2aKMqRYseUQ2dfW9ANAuYb2MPAw1S+_bF7_=w@mail.gmail.com>
X-Server-Quench: afba3531-1c36-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAQUEkAaAgsB AmMbWVReUFV7WGM7 bAtPbwFafEtKWxtr
V0pWR1pVCwQmRRlg fBYZJ19ydANGf3g+ ZEBnVnAVDRIoJEV4
QU9JFD4FY3phaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
FQ4vNDcwO3BTJTpg Ci0XJFwOCWwqJnZu Dx4DDTgjWFYORyg/
MhgrYlQYG00Sel4z I1ZpWFQTKRIbEQA2
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 71.247.144.172/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 19:08:16 -0000
--2/5bycvrmDh4d1IB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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:
>=20
> > Pieter Wuille showed with simulations that miners with bad connectivity
> > are negatively affected by other miners creating larger blocks.
> >
>=20
> ... 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.
> 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.
See above. The obvious thing to do if connectivity matters is keep your
hashing in the cheapest possible place and sell that hashing power to
centralized miners, an effect we're already seeing. Making this effect
about an order of magnitude worse, then doubling the problem every two
years is dangerous.
> 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.
As mining and hashing can be trivially separated that theory just
doesn't work.
Again, what concretely works against centralization of mining control?
A proper proposal would discuss this issue, and explain what the
expected effect will be.
> > These block propagation improvements are both already implemented (Matt
> > Corallo's relay network, p2pool) and require co-operation.
> >
>=20
> Long term the p2p protocol will evolve to incorporate those optimizations,
> so will require no co-operation.
The co-operation comes form the fact that mempool policies have to be
syncronized, not the protocol itself.
--=20
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
--2/5bycvrmDh4d1IB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVjaMUXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk
ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udy2swf/c0RUhmhcloZKdwzM2ITd9JVc
tcLBL8gPaLJqwW9Y1GljWWfVZ6ZxijcFoXgct4cySRmmqqFFUEJ8m1qUTW9pfyJ2
OjVqCZ+3Y9qJ2bNYV4Kq+f4CO10ihu+Y0tw7zExdtSHMcaTsCXkS/hvryfKPtxNE
dQRc57CJbcdTy3BfdVJmTrRpAD7GjHCHsaNQX0mfID25qQ8ldV2m8r4+7L20DeeI
Ea9I2urqO4AwEUjTG3fAc7oGenttgroXEDPe1r++qoK0O2lzbDs+g033mXFgmpWI
XSza2b07ejpkyVJEsY55pqC7zWWEqm9DgKhXTU7zi0+yNrXz+yIlr3G3x03uew==
=bD/L
-----END PGP SIGNATURE-----
--2/5bycvrmDh4d1IB--
|
