From: Peter Todd <pete@petertodd•org>
To: Sergio Lerner <sergiolerner@certimix•com>
Cc: "bitcoin-development@lists•sourceforge.net"
<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 06:34:02 -0400 [thread overview]
Message-ID: <20150511103402.GA21748@savin.petertodd.org> (raw)
In-Reply-To: <55505441.3010906@certimix.com>
[-- Attachment #1: Type: text/plain, Size: 5829 bytes --]
On Mon, May 11, 2015 at 04:03:29AM -0300, Sergio Lerner wrote:
> Arguments against reducing the block interval
>
> 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.
It's *way* easier to buy more bandwidth that it is to get lower latency.
After all, getting to the other side of the planet via fiber takes at
*minimum* 100ms simply due to the speed of light; routing overheads
approximately double or triple that for all but highly specialized and
very, very expensive, networking services. Bandwidth simply can't fix
the speed of light.
It's also not at all realistic or desirable to assume connectivity in a
single hop, so you can again multiply that base latency by 2-5 times.
And on top of *that* you have to take into account latency from hasher
to mining pool - time that the hashing power isn't working on the new
block because they're work unit hasn't been updated matters just as much
as the time to get that block to the pool in the first place. Being
forced to reduce that latency is very damaging to the ecosystem as
you're making it more profitable to keep hashing power centralized.
In any case, even with 10 minute blocks pools already pay a lot of
attention to latency... Why make that problem 10x worse?
> 2. It will increase the probability of a block-chain split
>
> The convergence of the network relies on the diminishing probability of
> two honest miners creating simultaneous competing blocks chains. To
> increase the competition chain, competing blocks must be generated in
> almost simultaneously (in the same time window approximately bounded by
> the network average block propagation delay). The probability of a block
> competition decreases exponentially with the number of blocks. In fact,
> the probability of a sustained competition on ten 1-minute blocks is one
> million times lower than the probability of a competition of one
> 10-minute block. So even if the competition probability of six 1-minute
> blocks is higher than of six ten-minute blocks, this does not imply
> reducing the block rate increases this chance, but on the contrary,
> reduces it.
Can you explain your reasoning here in detail?
> 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%
Actually the correct figure is less than ~30%:
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html
> percent. But this strategy of creating bloated blocks is too risky in
> practice, and surely doomed to fail, as network conditions dynamically
> change.
They dynamically change? Source?
Remember that the strategy still gives you a benefit if you simply
target, say, 75% rather than the minimum threshold.
> 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.
How do you see that blacklisting actually being done?
Equally, it's easy to portray such mining as being "for the good of
Bitcoin" - "we're just making transaction cheap! tough luck if your
shitty pool can't keep up" This is quite unlike selfish mining.
> 7. There has been insufficient testing and/or insufficient research into
> technical/economic implications or reducing the block rate
>
> This is partially true. in the GHOST paper, this has been analyzed, and
> the problem was shown to be solvable for block intervals of just a few
> seconds.
GHOST works radically differently than a linear blockchain, and it's not
clear that it actually has the correct economic incentives.
> These networking optimizations ( O(1) propagation using headers-first or
> IBLTs), can be added later.
Keep in mind that miners already use optimized propagation techniques,
like p2pool's implementation or Matt Corallo's block relaying network.
--
'peter'[:-1]@petertodd.org
00000000000000000c2b75113c6d2539f436ee9ac90abf620d9d3a3a4a19d3e8
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-05-11 10:34 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 [this message]
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
[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=20150511103402.GA21748@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=sergiolerner@certimix$(echo .)com \
/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