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
|
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 7C631AAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 20:46:58 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148106.authsmtp.co.uk (outmail148106.authsmtp.co.uk
[62.13.148.106])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id A55DA137
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 20:46:57 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5NKkpxq031717;
Tue, 23 Jun 2015 21:46:51 +0100 (BST)
Received: from muck ([209.141.138.18]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5NKklao043884
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 23 Jun 2015 21:46:49 +0100 (BST)
Date: Tue, 23 Jun 2015 16:46:47 -0400
From: Peter Todd <pete@petertodd.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20150623204646.GA18677@muck>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
<20150623192838.GG30235@muck>
<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
In-Reply-To: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
X-Server-Quench: f8f7825f-19e8-11e5-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAEUEkAaAgsB AmMbWVVeVFt7XGM7 aQpYcwRZY1RPXA10
UUBWR1pVCwQmRRl/ fUVCA0ZycwZOcHo+ ZEBjWXYVCkwsck5/
RxhJFGRTbXphaTUa TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
FQ4vNDcwO3BTJTpg Ci0XJFwOCWwqJnZu Dx4DDTgjWFYORyg/
MhgrYlQYG00Sel4z I1ZpWFQTKRIbEQA2
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 209.141.138.18/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: Tue, 23 Jun 2015 20:46:58 -0000
--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 23, 2015 at 04:12:17PM -0400, Gavin Andresen wrote:
> > In particular, if bandwidth scaling doesn't go according to your plan,
> > e.g. the exponential exponent is too large, perhaps due to technological
> > growth not keeping pace, or the political realities of actual bandwidth
> > deployment making theoretical technological growth irrelevant, what
> > mechanism will prevent centralization? (if any)
>=20
>=20
> Simulations show that:
>=20
> Latency/bandwidth matter for miners. Low latency, high bandwidth is
> better. However, miners with bad connectivity can simply create smaller
> blocks...
Pieter Wuille showed with simulations that miners with bad connectivity
are negatively affected by other miners creating larger blocks.
Similarly I showed that with equation-based analysis. I've seen no
response to either argument, and it's a centralization pressure.
Note how propagation times are important enough to miners that they
already mine on top of unverified headers from other miners to increase
profitability, a grave threat to the security of the Bitcoin network.
> ... 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.
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 scenarios.
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.
--=20
'peter'[:-1]@petertodd.org
000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd
--ZGiS0Q5IWpPtfppv
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVicW0XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwOGMwYmUxNmUxNTJmODZhYjNhMjcxYTEzYzNmNDFjNTYy
MjhkNzI5OTBhYmY3YmQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udypSgf/Xlj8fPuGUDZWDAUtxQCvpN9r
tP6rjejtLUBrXytx+px1Q7+0LoJ/aywz1FNcIRyfusaRTiZuZ0aL9SoG0BGwJujw
rR03uP7mLmSxCjQzI4/g8Q+1JHYx1w9L7gcN3KDkEGBBrd8JJYs5klSW8TZewfpp
xw6jS8LErvcqsj5LSx+LA4t6bXqI2gnOxr5aaJQw/V7zJ5HJh9cFspdE9pM0zdZB
kfMbmsOWzsJwEVZGvQgHTOnPgyNv/wjHJj7gTh/SQPEXUVZahwUEh6utkK15E/l9
qJKtcG5t3slq9IGx3E4qCJKQSoBIix1bPYWMfN9PyVAReX5cWuRZZKr7zaRFHg==
=ZuF8
-----END PGP SIGNATURE-----
--ZGiS0Q5IWpPtfppv--
|
