From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Sergio Lerner 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" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--