Re: [Bitcoin-development] The insecurity of merge-mining

[Peter Todd <pete@petertodd.org>]

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

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.

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.

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

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