From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F7BAB3F for ; Mon, 22 May 2017 13:33:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148161.authsmtp.com (outmail148161.authsmtp.com [62.13.148.161]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 424031CE for ; Mon, 22 May 2017 13:33:42 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt24.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v4MDXeUS075910; Mon, 22 May 2017 14:33:40 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v4MDXcCO024377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 May 2017 14:33:39 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id DD423400DE; Mon, 22 May 2017 13:33:37 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 142E420101; Mon, 22 May 2017 09:33:35 -0400 (EDT) Date: Mon, 22 May 2017 09:33:35 -0400 From: Peter Todd To: Paul Sztorc Message-ID: <20170522133335.GA17194@fedora-23-dvm> References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 43caff52-3ef3-11e7-829f-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAAUFVQNAgsB AmEbWlBeU157Wmo7 bghPaBtcak9QXgdq T0pMXVMcUgEVdXRS dWEeUB1xcAIIfnh1 ZwhmXSMKChJ/d1t+ FxhXCGwHMGB9YGIW Bl1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z GA41ejw8IwAXBD5U XAwGLVsTRw5OW3YG SgkfEC4zVUMCXW0f LgctN0UHHUEXWgAA X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 13:33:44 -0000 --gKMricLos+KVdGMg Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote: > This work includes the relatively new concept of "Blind Merged Mining" > [2] which I developed in January to allow SHA256^2 miners to merge-mine > these "drivechains", even if these miners aren't running the actual > sidechain software. The goal is to prevent sidechains from affecting the > levelness of the mining "playing field". BMM is conceptually similar to > ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not > required for drivechain, but it would address some of the last remaining > concerns. Thanks for the credit, although I think the security properties of what you= 're proposing are very different - and much weaker - than what I proposed in Zookeyv. As you state in [2] "if miners never validate sidechains at all, whoever bi= ds the most for the chain (on a continuous basis), can spam a 3-month long str= eam of invalid headers, and then withdraw all of the coins deposited to the sidechain." and "Since the mining is blind, and the sidechain-withdrawal security-level is SPV, miners who remain blind forever have no way of telli= ng who =E2=80=9Cshould=E2=80=9D really get the funds." Finally, you suggest that in this event, miners *do* have to upgrade to a f= ull node, an expensive and time-consuming operation (and one that may be imposs= ible for some miners if necessary data isn't available). It's unclear to me what the incentive is for miners to do any of this. Could you explain in more detail what that incentive is? > [2] http://www.truthcoin.info/blog/blind-merged-mining/ > [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZIuitAAoJECSBQD2l8JH7JvMH/iapcbd5y+yV7S2FcfrzBpvg 2OUVrivXwrlDRPO51dqsW0IiUt2eX+zqVvL7pX7zYxWh5kPshzz4g5OmEI6qA6jA VCYL230ieRkCg1WUGTC6xChK9I0GGvsxUvYpMpSHhXYMYdwhMrj/paVIxoMQ1eH0 7jHMwZbsSvfXsUShAg8MCprGsF4/8XPLCnXh/jrLOhCvYzhxPpSKcv9xtSBe78gS HKiyn7ccKPskTuq3xT7x1j9gOBxULmIXESp62G1YziqQdTMAEp3+cdLUiDjySdcT r6jpmCSToG/xnOpHhFF4LiF0NRTb4/WqufB6drXpFdwGTmJpy128pTC8ohy/5nM= =p8L2 -----END PGP SIGNATURE----- --gKMricLos+KVdGMg--