[Bitcoin-development] The insecurity of merge-mining

[Luke-Jr]

On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote:
> On Tue, Dec 31, 2013 at 01:14:05AM +0000, Luke-Jr wrote:
> > On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
> > > that you are using merge-mining is a red-flag because without majority,
> > > or at least near-majority, hashing power an attacker can 51% attack
> > > your altcoin at negligible cost by re-using existing hashing power.
> > 
> > I strongly disagree on this isolated point. Using the same logic, Bitcoin
> > is vulnerable to an attacker at negligible cost by re-using existing
> > hashing power from mining Namecoin. Any non-scam altcoin is pretty safe
> > using merged mining, since any would-be attacker is going to have it in
> > their interests to invest in the altcoin instead of attacking it. It's
> > only the scam ones that want to pump & dump with no improvements, that
> > are really at risk here.
> > 
> > The rational decision for a non-scam altcoin, is to take advantage of
> > merged mining to get as much security as possible. There are also some
> > possible tricks to get the full security of the bitcoin miners even when
> > not all participate in your altcoin (but this area probably needs some
> > studying to get right).
> 
> 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.

> OTOH if the Zerocoin scheme was implemented by embedding ZTC
> transactions within standard Bitcoin transactions - even without any
> attempt at hiding them - the attackers would need a 50% majority of
> hashing power to succeed. Of course potentially slow confirmations is a
> trade-off, but that's likely a perfectly OK trade-off in this case.

Potentially slow confirmation is also the only shortcoming of using Bitcoin's 
proof-of-work directly.

Luke