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 ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
