From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size
Date: Mon, 11 May 2015 16:47:47 +0000 [thread overview]
Message-ID: <201505111647.51088.luke@dashjr.org> (raw)
In-Reply-To: <55505441.3010906@certimix.com>
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
next prev parent reply other threads:[~2015-05-11 17:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-11 7:03 Sergio Lerner
2015-05-11 10:34 ` Peter Todd
2015-05-11 11:10 ` insecurity
2015-05-11 11:49 ` Dave Hudson
2015-05-11 12:34 ` Christian Decker
2015-05-11 16:47 ` Luke Dashjr [this message]
[not found] ` <5551021E.8010706@LeoWandersleb.de>
2015-05-12 18:55 ` Sergio Lerner
2015-05-11 7:30 Thy Shizzle
2015-05-11 8:16 ` Dave Hudson
2015-05-11 8:50 insecurity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201505111647.51088.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox