public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Luke-Jr <luke@dashjr.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The insecurity of merge-mining
Date: Wed, 1 Jan 2014 00:25:14 -0500	[thread overview]
Message-ID: <20140101052513.GB7103@tilt> (raw)
In-Reply-To: <201401010509.27977.luke@dashjr.org>

[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]

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.
> > 
> > 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.
> 
> Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the 
> 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/msg02472.html

-- 
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2014-01-01  5:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-29 18:53 [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space Evan Duffield
2013-12-29 19:27 ` Matt Corallo
2013-12-30 23:22 ` Peter Todd
2013-12-31  1:14   ` Luke-Jr
2013-12-31  7:28     ` [Bitcoin-development] Merge mining Jeremy Spilman
2013-12-31  7:38       ` rob.golding
2014-01-04  8:49         ` David Vorick
2014-01-04 10:05           ` Jorge Timón
2014-01-04 10:08             ` David Vorick
2014-01-04 10:34               ` Jorge Timón
2014-01-01  4:53     ` [Bitcoin-development] The insecurity of merge-mining Peter Todd
2014-01-01  5:09       ` Luke-Jr
2014-01-01  5:25         ` Peter Todd [this message]
2014-01-03 19:14       ` Jorge Timón
2014-01-03 21:01         ` Peter Todd
2014-01-04  0:27           ` Jorge Timón
2014-01-06 15:44             ` Peter Todd
2014-01-09 17:19               ` Jorge Timón
2014-01-10 11:11                 ` Peter Todd
2014-01-10 11:25                   ` Peter Todd
2014-01-10 12:37                     ` Jorge Timón
2014-01-10 12:29                   ` Jorge Timón
2014-01-10 17:22                     ` Peter Todd
2014-01-10 18:50                       ` Jorge Timón
2014-01-03  5:11 ` [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space Troy Benjegerdes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140101052513.GB7103@tilt \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=luke@dashjr.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox