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; 
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>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201505111647.51088.luke@dashjr.org>
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
	increasing the maximum block size
Precedence: list

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