From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdJ9V-0002Yv-RJ for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 12:21:05 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.43 as permitted sender) client-ip=62.13.149.43; envelope-from=pete@petertodd.org; helo=outmail149043.authsmtp.co.uk; Received: from outmail149043.authsmtp.co.uk ([62.13.149.43]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VdJ9T-0005kd-Oz for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 12:21:05 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4CKhRm014239; Mon, 4 Nov 2013 12:20:43 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4CKdL3097907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 12:20:42 GMT Date: Mon, 4 Nov 2013 07:20:39 -0500 From: Peter Todd To: Mike Hearn Message-ID: <20131104122039.GC1013@savin> References: <52778BCE.8030904@ceptacle.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dkEUBIird37B8yKS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 863410ed-454b-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgYUFloCAgsB AmUbWlZeUl17XWE7 bAxPbAVDY01GQQRq WVdMSlVNFUsqcBhy fUpiURl7cAxGfzBx ZkJhXD5TWkd+dEYo FlNQEGlUeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4iAyI7 Ah8PGzg1FFEIS202 LhorMBYWFU0SOEI0 PDMA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] -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: 1VdJ9T-0005kd-Oz Cc: Bitcoin Dev , Michael Gronager Subject: Re: [Bitcoin-development] Auto-generated miner backbone 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, 04 Nov 2013 12:21:06 -0000 --dkEUBIird37B8yKS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 04, 2013 at 01:03:50PM +0100, Mike Hearn wrote: > > > > The suggested change is actually very simple (minutes of coding) and > > elegant and addresses precisely the identified problem. > > >=20 > Disagree. Unless I'm misunderstanding what they propose, their suggested > change would mean anyone could broadcast a newly discovered block at any > point and have a 50% chance of being the winner. That is a fundamental > change to the dynamics of how Bitcoin works that would require careful > thought and study. It's worth pointing out that my previous post on this list for "near-block broadcasts" - where blocks that almost but not quite met the proof-of-work threshold are also broadcast so that propagation of transactions can be proven - also naturally leads to their proposed solution. Any miner who sees a near-block-broadcast extending a chain fork that they aren't mining on would naturally see that as evidence that the other side has more hashing power, and thus it's in their interest to mine it rather than the side they are mining. You know, the whole paper follows the same logic as the point I made months ago in how if there is no explicit blocksize limit miners have incentives to make their blocks large enough that they only propagate to just over 50% of the hashing power, thus causing their competitors to waste effort. They analyze the situation in terms of a sybil attack, where I proposed a more fundemental mechanism to achieve the same goal based on simple physics. --=20 'peter'[:-1]@petertodd.org 000000000000000719f061e0fa83343ddbe80d2b6a1fefc84691ffe8652385e0 --dkEUBIird37B8yKS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGrBAEBCACVBQJSd5EWXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDNkZjMxNjFmMTM5NjYxOGRlZjYxZTdhM2U5ZWVlYTFjMTk0 ZDkwMzYxODJkOGE4NWQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuRHAgAkXDA/7f/6VGfuD3zRqz1yc3p LZjxh8qbHhO+Vn+/Ua6Lte/JjreFlIskFMRhZUX9aovBmkseFRm4iqctl3+kKaCj 9lexjoGa5cMm5hv/W1ZryYKCOTYAQ47gyYL/XXw5TxROtjkTFLDxFN8LYwyCFFtv fHpeaAl2wa92r4PMaJ8Z3InSjrYx3mzSK8d7UxQS75wegXbsy64fNkCP3tYgkjCe 7oWBKxKR26R8qbEH+sVOjWvEWB2OoK2xjCZx1JYo3lBhZthIY+ZUejhBbIrDQxma ZzKQhlv3mFHorTcpvR0ejJwcrFT4/tqkBSuAi1LQfANFeQIts6n7pqakizJB/Q== =xk9O -----END PGP SIGNATURE----- --dkEUBIird37B8yKS--