path: root/d2/97272356346ec55d5e15cd918c1aac1b65704f

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1Yrl2O-00041w-UQ
	for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 10:34:16 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.95 as permitted sender)
	client-ip=62.13.149.95; envelope-from=pete@petertodd.org;
	helo=outmail149095.authsmtp.com; 
Received: from outmail149095.authsmtp.com ([62.13.149.95])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Yrl2M-0003h8-T8 for bitcoin-development@lists.sourceforge.net;
	Mon, 11 May 2015 10:34:16 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4BAY6ff040297;
	Mon, 11 May 2015 11:34:06 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
	[75.119.251.161]) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4BAY27A079951
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 11 May 2015 11:34:05 +0100 (BST)
Date: Mon, 11 May 2015 06:34:02 -0400
From: Peter Todd <pete@petertodd.org>
To: Sergio Lerner <sergiolerner@certimix.com>
Message-ID: <20150511103402.GA21748@savin.petertodd.org>
References: <55505441.3010906@certimix.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs"
Content-Disposition: inline
In-Reply-To: <55505441.3010906@certimix.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 3fbb7a79-f7c9-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwMUFVQNAgsB AmMbWlVeU1l7WWY7 bA9PbARUfEhLXhtr
	VklWR1pVCwQmRRhz d3ccVWhycAxPfX8+ Z0drV3MVXxIoJ0Es
	RUdJQ2pVbHphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
	NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJDMw WhsDGzpnAU0IDy83
	KBclYkQVAEtZM0Mp LVYoVRofPX1aCwtV BUxEGy5fKBEdRydj
	CApKXEsDFXVXRSBX AVUzIw1Fai0I
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-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: 1Yrl2M-0003h8-T8
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
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 10:34:17 -0000


--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 11, 2015 at 04:03:29AM -0300, Sergio Lerner wrote:
> Arguments against reducing the block interval
>=20
> 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
>=20
> 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 l=
ow.

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
>=20
> 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,=20
> 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?
>=20
> 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/msg03=
200.html

> percent. But this strategy of creating bloated blocks is too risky in
> practice, and surely doomed to fail, as network conditions dynamically=20
> 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
> =20
> 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.

--=20
'peter'[:-1]@petertodd.org
00000000000000000c2b75113c6d2539f436ee9ac90abf620d9d3a3a4a19d3e8

--82I3+IH0IqGh5yIs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVUIWWXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxNTQ2YmQyOTM0NTg2NDZiMjRkMjYxMDAxZWE2NGNiM2Jh
ZGQzZGUwNTI2MjQ5ZTkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvt7Af7BVOZxWKq399lZ5BuAs0e6y7H
uY2IwRSqqKAFNqgshX7eZVVZIzDHECNwwlQPNxwK/J3IJxgOcnpoQF7ySfl5Jl+T
qDzQWQni/gQvopnTS13iPgaloGabYUry7G5tfm9wRYcRNFRffdHVmS7JhfmN2Hj6
U1e+qVPXvITEtAJMqwiYR1wC+b8RFR3TstNIb2OpV0ESq1NYzBhCed73wFWyEp9+
IJs4krvVT1aseXdYZGSyfK/4CCm2V77yNLiuWo/4eaTmMOMUlc0NAffiQpzyDP7G
dG2dXgw+l3mETDTGbJVmfkiq9gQsQ+Yxrmko64LzMAwTTynLFh0xBGCGiPWTjQ==
=J+7W
-----END PGP SIGNATURE-----

--82I3+IH0IqGh5yIs--