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 1VyEJj-0008KZ-J3 for bitcoin-development@lists.sourceforge.net; Wed, 01 Jan 2014 05:26:07 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.78 as permitted sender) client-ip=62.13.149.78; envelope-from=pete@petertodd.org; helo=outmail149078.authsmtp.net; Received: from outmail149078.authsmtp.net ([62.13.149.78]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VyEJh-0004NN-96 for bitcoin-development@lists.sourceforge.net; Wed, 01 Jan 2014 05:26:07 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s015PuYC029023; Wed, 1 Jan 2014 05:25:56 GMT Received: from tilt (dhcp186-112.theedge.ca [216.108.186.112]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s015PjTA040055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Jan 2014 05:25:51 GMT Date: Wed, 1 Jan 2014 00:25:14 -0500 From: Peter Todd To: Luke-Jr Message-ID: <20140101052513.GB7103@tilt> References: <201312310114.05600.luke@dashjr.org> <20140101045342.GA7103@tilt> <201401010509.27977.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <201401010509.27977.luke@dashjr.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 2fa6c4f0-72a5-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdgMUElQaAgsB AmIbW1FeUlh7XGc7 aQtXcwRdalRPVwN0 UUlLXVdaExppT18B Bxt+CH0DdwFGeHt1 K0dmXHBbEkYsJEAu RhhUCGoENGJ9aWFK U10KfwNWbQNKfBpM agF+USdcZitlM3Bw LCUyIzs2PDMaJClL TwUKNVcfR1o+VgI8 SlgDGy4iFlAfRjki ZxsoYlsRBkkcd0Az N1onVjoA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 216.108.186.112/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: 1VyEJh-0004NN-96 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] The insecurity of merge-mining 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: Wed, 01 Jan 2014 05:26:07 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 01, 2014 at 05:09:27AM +0000, Luke-Jr wrote: > > You assume the value of a crypto-currency is equal to all miners, it's > > not. > >=20 > > Suppose I create a merge-mined Zerocoin implementation with a 1:1 > > BTC/ZTC exchange rate enforced by the software. You can't argue this is > > a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the > > only thing you can do with the coin is get some privacy. But inevitably > > some miners won't agree that enabling better privacy is a good thing, or > > their local governments won't. Either way, they can attack the Zerocoin > > merge-mined chain with a marginal cost of nearly zero. >=20 > Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, = the=20 > worst they could do is not-participate by mining empty blocks. Nope. Tying the alt-coin difficulty to the Bitcoin difficulty isn't some magic way to avoid a 51% attack - you still need a majority of consensus. The attackers can still mine a conflicting chain and there's still no reasonable way to choose between the two chains other than proof-of-something. Even worse, then can do a data-hiding attack by mining a conflicting chain without publishing the blockchain data, then revealing it some time in the future, or just sowing FUD by making it clear that the mining is happening. Like it or not crypto-coins solve double-spending with proof-of-publication, and that can't be done without some kind of mathematically verifiable majority aligned with the interests of the crypto-coin users. Recall that my zookeyv(1) and zerocoin alt(2) proposals from last summer was specifically designed to take that situation into account, and of course could at best only make it clear that it was happening and how many Bitcoins needed to be sacrificed to make the chain secure. 1) #bitcoin-wizards, 2013-05-31 2) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms= g02472.html --=20 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJSw6a5AAoJECSBQD2l8JH75W0H/3hX5hz8tpUNaFel5kPnWC4/ DIJA2hsk2+zUAk3M48Ru+cz3HPrMI8zRf08T2FSVsNwxRj3QiO6dhzaa8oRNXD2P UFHtYGethchuYY9YtcBHlkx+4swraecPBXd37dLXhK/0DiqBADODNyQGgDjbbcew mhkj4UApBmdNWLcFtCqGXwBaDgL8qi4j8ZDA8p7qzuJvEAxpQyDQgoXQXC54hlZX s10k/3/9ROWsft+RvuBRJs27wDzfIqwjnytk1VboZEzEqEVDzp6Y0X2ynjxRyzqe nJieSBJi2KLqy132pxBB5eWMrsrCZlOShqqmvxbiE01D5jumv08xdb3Rzqlu0GU= =eBH1 -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O--