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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1YrrSm-000382-MQ
for bitcoin-development@lists.sourceforge.net;
Mon, 11 May 2015 17:25:56 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of dashjr.org
designates 85.234.147.28 as permitted sender)
client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
helo=zinan.dashjr.org;
Received: from 85-234-147-28.static.as29550.net ([85.234.147.28]
helo=zinan.dashjr.org)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YrrSl-0005Lz-7T for bitcoin-development@lists.sourceforge.net;
Mon, 11 May 2015 17:25:56 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 24F50108371C;
Mon, 11 May 2015 16:47:52 +0000 (UTC)
X-Hashcash: 1:25:150511:bitcoin-development@lists.sourceforge.net::pVqZ+alb/yPIgGUb:gYRL
X-Hashcash: 1:25:150511:sergiolerner@certimix.com::YMANzNVDKd/bNLBI:a20PY
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Mon, 11 May 2015 16:47:47 +0000
User-Agent: KMail/1.13.7 (Linux/3.14.37-gentoo; KDE/4.14.3; x86_64; ; )
References: <55505441.3010906@certimix.com>
In-Reply-To: <55505441.3010906@certimix.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505111647.51088.luke@dashjr.org>
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 TVD_RCVD_IP Message was received from an IP address
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YrrSl-0005Lz-7T
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
increasing the maximum block size
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 11 May 2015 17:25:56 -0000
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
> 1. It will encourage centralization, because participants of mining
> pools will loose more money because of excessive initial block template
> latency, which leads to higher stale shares
>
> When a new block is solved, that information needs to propagate
> throughout the Bitcoin network up to the mining pool operator nodes,
> then a new block header candidate is created, and this header must be
> propagated to all the mining pool users, ether by a push or a pull
> model. Generally the mining server pushes new work units to the
> individual miners. If done other way around, the server would need to
> handle a high load of continuous work requests that would be difficult
> to distinguish from a DDoS attack. So if the server pushes new block
> header candidates to clients, then the problem boils down to increasing
> bandwidth of the servers to achieve a tenfold increase in work
> distribution. Or distributing the servers geographically to achieve a
> lower latency. Propagating blocks does not require additional CPU
> resources, so mining pools administrators would need to increase
> moderately their investment in the server infrastructure to achieve
> lower latency and higher bandwidth, but I guess the investment would be
> low.
1. Latency is what matters here, not bandwidth so much. And latency reduction
is either expensive or impossible.
2. Mining pools are mostly run at a loss (with exception to only the most
centralised pools), and have nothing to invest in increasing infrastructure.
> 3, It will reduce the security of the network
>
> The security of the network is based on two facts:
> A- The miners are incentivized to extend the best chain
> B- The probability of a reversal based on a long block competition
> decreases as more confirmation blocks are appended.
> C- Renting or buying hardware to perform a 51% attack is costly.
>
> A still holds. B holds for the same amount of confirmation blocks, so 6
> confirmation blocks in a 10-minute block-chain is approximately
> equivalent to 6 confirmation blocks in a 1-minute block-chain.
> Only C changes, as renting the hashing power for 6 minutes is ten times
> less expensive as renting it for 1 hour. However, there is no shop where
> one can find 51% of the hashing power to rent right now, nor probably
> will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
> confirmation (60 1-minute blocks) if you wish for high-valued payments,
> so the security decreases only if participant wish to decrease it.
You're overlooking at least:
1. The real network has to suffer wasted work as a result of the stale blocks,
while an attacker does not. If 20% of blocks are stale, the attacker only
needs 40% of the legitimate hashrate to achieve 50%-in-practice.
2. Since blocks are individually weaker, it becomes cheaper to DoS nodes with
invalid blocks. (not sure if this is a real concern, but it ought to be
considered and addressed)
> 4. Reducing the block propagation time on the average case is good, but
> what happen in the worse case?
>
> Most methods proposed to reduce the block propagation delay do it only
> on the average case. Any kind of block compression relies on both
> parties sharing some previous information. In the worse case it's true
> that a miner can create and try to broadcast a block that takes too much
> time to verify or bandwidth to transmit. This is currently true on the
> Bitcoin network. Nevertheless there is no such incentive for miners,
> since they will be shooting on their own foots. Peter Todd has argued
> that the best strategy for miners is actually to reach 51% of the
> network, but not more. In other words, to exclude the slowest 49%
> percent. But this strategy of creating bloated blocks is too risky in
> practice, and surely doomed to fail, as network conditions dynamically
> change. Also it would be perceived as an attack to the network, and the
> miner (if it is a public mining pool) would be probably blacklisted.
One can probably overcome changing network conditions merely by trying to
reach 75% and exclude the slowest 25%. Also, there is no way to identify or
blacklist miners.
> 5. Thousands of SPV wallets running in mobile devices would need to be
> upgraded (thanks Mike).
>
> That depends on the current upgrade rate for SPV wallets like Bitcoin
> Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
> develop the source code for the change now and apply the change in Q2
> 2016, then most of the nodes will already be upgraded by when the
> hardfork takes place. Also a public notice telling people to upgrade in
> web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
> advance will give plenty of time to SPV wallet users to upgrade.
I agree this shouldn't be a real concern. SPV wallets are also more likely and
less risky (globally) to be auto-updated.
> 6. If there are 10x more blocks, then there are 10x more block headers,
> and that increases the amount of bandwidth SPV wallets need to catch up
> with the chain
>
> A standard smartphone with average cellular downstream speed downloads
> 2.6 headers per second (1600 kbits/sec) [3], so if synchronization were
> to be done only at night when the phone is connected to the power line,
> then it would take 9 minutes to synchronize with 1440 headers/day. If a
> person should accept a payment, and the smart-phone is 1 day
> out-of-synch, then it takes less time to download all the missing
> headers than to wait for a 10-minute one block confirmation. Obviously
> all smartphones with 3G have a downstream bandwidth much higher,
> averaging 1 Mbps. So the whole synchronization will be done less than a
> 1-minute block confirmation.
Uh, I think you need to be using at least median speeds. As an example, I can
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G has
worse range/coverage than 2G. No doubt the *average* is skewed so high because
of densely populated areas like San Francisco having 400+ Mbps cellular data.
It's not reasonable to assume sync only at night: most payments will be during
the day, on battery - so increased power use must also be considered.
> According to CISCO mobile bandwidth connection speed increases 20% every
> year.
Only in small densely populated areas of first-world countries.
Luke
|
