Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdLQj-0006Ut-MK for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 14:47:01 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VdLQi-0004VW-MC for bitcoin-development@lists.sourceforge.net; Mon, 04 Nov 2013 14:47:01 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4EkibM050542; Mon, 4 Nov 2013 14:46:44 GMT Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4EkVL3004829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 14:46:34 GMT Date: Mon, 4 Nov 2013 09:46:31 -0500 From: Peter Todd To: Pieter Wuille Message-ID: <20131104144631.GA2395@petertodd.org> References: <20131104142621.GA2190@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: e6d5e06c-455f-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR bgdMdgYUFloCAgsB AmUbWlBeVFt7Wmc7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQ20F c0V4LhpydwFOenc+ ZENgV3UVCUIucBN9 RB1JEWgDM3phaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNyMg QFUNEDMiB0QZSil7 Kh0gJ0RUFk8aMU81 N1ZJ X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/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 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] X-Headers-End: 1VdLQi-0004VW-MC Cc: Ittay Eyal , Bitcoin Dev 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 14:47:01 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 04, 2013 at 03:34:35PM +0100, Pieter Wuille wrote: > > Mining strategy is now to mine to extend the first block you see, on the > > assumption that the earlier one probably propagated to a large portion > > of the total hashing power. But as you receive "near-blocks" that are > > under the PoW target, use them to estimate the hashing power on each > > fork, and if it looks like you are not on the majority side, switch. >=20 > Doesn't that mean that by selective blocking these near-PoW headers, > you can bias peers into preferring to mine on those with near-PoW > headers, turning the attack around? Of course, because of their size, > headers are likely much harder to slow down (in propagation speed) > than full blocks... Remember that the attack described in the paper *doesn't* depend on the ability to selectively block or even just slow down anything - it works even on a unlimited bandwidth jam-free network so long as latency is non-zero. As for other possible attacks, if you can selectively block or slow down certain near-target headers you haven't achieved anything novel. Why not use that ability to block or slow down blocks themselves? Even if you did block some PoW headers for whatever reason the original purpose of broadcasting them - getting all hashing power to work to extend the same block - is still achieved. --=20 'peter'[:-1]@petertodd.org 0000000000000001d7eb7fceb2e27f3dd1eb5f516464a6b6874fdf6debbd0227 --AqsLC8rIMeq19msA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSd7NHAAoJEBmcgzuo5/CF4VEIAMEQ9kwH3sGHxTFHEAfoLXll /iSCyMhyZyC1UqLLVX5I7MHzfMOkjXV4U2EX69GGMVvuyAYBPOL0PoQn7xi2kodU 2tOAFIez+xmta+JNYB7VehbSWmKoFef0vmqnnSkv/ryHkUsEukSEuiTghr2T+zkH DhZ+qcfBHwFZwxpHALLlHPRtD8Sw5Y1mUyuYp2ui62b8OMjalKYo0QU6qRBjcFup /udXGZyY0e83DTqYvyzicnRFoPq5Cs1i+dS+HbhLbmxu434+RK8WVQYiYK1jyk7r SNnXes6ZUz1lkrJNrsldE8n4Z+Od/WN1kWwA1OrwU2usYphxcS7SYrG9XTCeUcA= =E8vX -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA--