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; 
Date: Wed, 1 Jan 2014 00:25:14 -0500
From: Peter Todd <pete@petertodd.org>
To: Luke-Jr <luke@dashjr.org>
Message-ID: <20140101052513.GB7103@tilt>
References: <CAMkFLsSwKEiEtV1OaAsGPiU8iAWbb77fDNJDmRwbgKnZ_kjG6Q@mail.gmail.com>
	<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)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The insecurity of merge-mining
Precedence: list


--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--