Re: [Bitcoin-development] The insecurity of merge-mining
On Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote: On 1/6/14, Peter Todd p...@petertodd.org wrote: On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote: It's not meant to prove anything - the proof-of-sacrificed-bitcoins mentioned(*) in it is secure only if Bitcoin itself is secure and functional. I referred you to it because understanding the system will help you understand my thinking behind merge-mining. *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct because you're sacrificing the thing that the chain is about. Now that has some proof-of-stake tinges to it for sure - I myself am not convinced it is or isn't a viable scheme. I'm not sure I understand all the differences between proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm still convinced this doesn't have anything to do with MM PoW vs PoW. Proof-of-sacrified-bitcoins is always a true sacrifice - provided Bitcoin itself maintains consensus the proof is a guarantee that something of value was given up. Proof-of-sacrificed-newcoins means that within some consensus system I created a signed statement that *within the system* means I lose something of value. However that sacrifice is only valid if the consensus of the system includes that sacrifice within the consensus, and if the mechanism by which that consensus is maintained has anything to do with those sacrifices you quickly find yourself on pretty shakey ground. You know, something that I haven't made clear in this discussion is that while I think merge-mining is insecure, in the sense of should my new fancy alt-coin protocol widget use it?, I *also* don't think regular mining is much better. In some cases it will be worse due to social factors. (e.g. a bunch of big pools are going to merge-mine my scheme on launch day because it makes puppies cuter and kids smile) Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. The problem here is that my new system has a substantial *negative* value to those existing Namecoin holders - if it catches on the value of their Namecoin investment in the form of coins and domain names may go down. Thus for them doing nothing has a negative return, attacking my coin has a positive return minus costs, and with merge-mining the costs are zero. Without merge mining if the value to the participants in the new system is greater than the harm done to the participants in the old system the total work on the new system's chain will still be positive and it has a chance of surviving. Of course, this is what Luke-Jr was getting at when he was talking about scam-coins and merge mining: if you're alt-currency is a currency, and it catches on, then it dilutes the value of your existing coins and people who own those coins have an incentive to attack the competitor. That's why merge-mined alt-coins that are currencies get often get attacked very quickly. -- 'peter'[:-1]@petertodd.org 00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On Fri, Jan 10, 2014 at 06:11:28AM -0500, Peter Todd wrote: Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. Come to think of it, we've got that exact situation right now: the new Twister P2P Microblogging thing has a blockchain for registering usernames that could have been easily done with Namecoin, thus in theory Namecoin owners have an incentive to make sure the Twister blockchain gets killed at birth. Pretty easy to do right now too as the hashing power behind Twister is miniscule and probably will stay that way - the only incentive to mining is that you get the right to make a promoted post - called a spam message in the codebase - that in theory Twister clients are supposed to show to their users. Of course, there's absolutely no way to guarantee that clients actually do that. -- 'peter'[:-1]@petertodd.org 00028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857 signature.asc Description: Digital signature -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/10/14, Peter Todd p...@petertodd.org wrote: Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. Namecoin, Devcoin and Ixcoin are also currencies and therefore compete with Bitcoin. How is that even Ixcoin (clearly a scamcoin that indirectly damages the image of Bitcoin) has survived? My explanation is that miners aren't necessarily holders. It's certain that there's holders who don't mind and can't do anything about it. In fact, I think many miners sell their mined coins for fiat to cover their investment and costs. The profit margin is reduced as the mining market becomes more competitive, so even for miners it will get very expensive and risky to do stupid things. Talking about stupid things, I don't see many bitcoiners throwing rocks at local currency users or barter clubs nor burning down banks to protect their investment. Barter is just another competitor in the media of exchange market. The problem here is that my new system has a substantial *negative* value to those existing Namecoin holders - if it catches on the value of their Namecoin investment in the form of coins and domain names may go down. Thus for them doing nothing has a negative return, attacking my coin has a positive return minus costs, and with merge-mining the costs are zero. What percentage of Bitcoin/Namecoin miners do you think own namecoins? How much can they afford to lose to attack competition? Without merge mining if the value to the participants in the new system is greater than the harm done to the participants in the old system the total work on the new system's chain will still be positive and it has a chance of surviving. No, the harm to the old system participants is distributed among all the participants, not only miners (assuming miners have any speculative position at all). I'm not denying that people do crazy and stupid things, but let's at least allow the anti-competition attacker be equally crazy in both cases. Miners attacking competition for one or more of the chains they mine are acting irrationally in both cases. You're trying to rationalize the actions of the MM attackers, but they're just being stupid, since if they weren't, they would just try to maximize profits. Of course, this is what Luke-Jr was getting at when he was talking about scam-coins and merge mining: if you're alt-currency is a currency, and it catches on, then it dilutes the value of your existing coins and people who own those coins have an incentive to attack the competitor. That's why merge-mined alt-coins that are currencies get often get attacked very quickly. I have many other explanations for the few currencies that died with MM (can you remember any name?). At the beginning all altcoins were much smaller and easier to attack, all of them. Bitcoin mining pools didn't wanted to update to merged mining and didn't acted very rationally about it. Namecoin went through a really delicate situation just before hardforking to MM, but now is by far the most secure altcoin of them all, all thanks to MM. All rational bitcoin miners should also mine namecoin. Period. All those who consider it competition with their current Bitcoin speculative position, should just attack in the market by selling the namecoins as soon as they get them. Providing security for a chain DOES NOT give it an utility or rise its demand. Operation COSTS DO NOT CAUSE VALUE. About Luke-Jr's thinking, I don't think it's along those lines. If you create a new chain for the long term, you should try to maximize its security and that currently means you should merged mine with bitcoin. The main rational reason to never do merged mining is to prevent competitive and rational miners from crashing the price of your currency, which is everything a scamcoiner cares about, the price and market cap. Of course Luke-Jr can correct me if that's not how he thinks. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/10/14, Peter Todd p...@petertodd.org wrote: Come to think of it, we've got that exact situation right now: the new Twister P2P Microblogging thing has a blockchain for registering usernames that could have been easily done with Namecoin, thus in theory Namecoin owners have an incentive to make sure the Twister blockchain gets killed at birth. You don't have to MM from birth. That I've already agreed is dangerous. But if you start with SHA256, then merged mining is a trivial fork at least 3 currencies have done successfully. As said we plan to make Freicoin merge-mineable in the future, and we expect to get much more security after we do. The only adverse effect may be a temporary drop in price due to the new miners selling all the frc they get until a new price equilibrates with the demand. But that's not really bad for the currency, just to the holders at that moment. Pretty easy to do right now too as the hashing power behind Twister is miniscule and probably will stay that way - the only incentive to mining is that you get the right to make a promoted post - called a spam message in the codebase - that in theory Twister clients are supposed to show to their users. Of course, there's absolutely no way to guarantee that clients actually do that. If a system doesn't compensate its miners in a liquid enough way, the system will probably be insecure, but that's another topic... -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote: On 1/10/14, Peter Todd p...@petertodd.org wrote: Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance if I were to create a competitor to Namecoin, perhaps because I thought the existing allocation of names was unfair, and/or I had technical improvements like SPV, it's easy to imagine Namecoin miners deciding to attack my competitor to preserve the value of their namecoins and domain names registered in Namecoin. Namecoin, Devcoin and Ixcoin are also currencies and therefore compete with Bitcoin. How is that even Ixcoin (clearly a scamcoin that indirectly damages the image of Bitcoin) has survived? Because there aren't that many pools out there and Ixcoin (and devcoin) appear to have been lucky enough to servive long enough to get the support of a reasonably big one. Once you do that, the potential attackers have PR to think about. (namecoin especially has a PR advantage) None of this stuff is hard and fast rules after all. Talking about stupid things, I don't see many bitcoiners throwing rocks at local currency users or barter clubs nor burning down banks to protect their investment. Barter is just another competitor in the media of exchange market. Those are all examples where the cost to the bitcoiner defending their currency is high - I might get arrested trying to burn down a bank. Anyway, I'm starting to think you're reading too much into my statement merge mining is insecure, which, keep in mind, I said in relation to a guy who was trying to recruit devs to implement some unknown altcoin thing. Imagine you're one of the first US cave divers back in the early 70's. You've been doing it for only a few years yourself, and you and your buddies, some of them now late, realized pretty quick it's bloody dangerous and there's all kinds of ways to get yourself killed. (caving itself is bad enough) On the other hand, if you're careful and have good training it *is* possible to reduce the risks significantly. Meanwhile the media and public in general is starting to pick up on caving and cave diving and there's a tonne of new people - most of whome don't seem to know what they're doing - are getting into both sports. You just know this is going to lead to a lot of people getting hurt and killed who probably should have just stuck to caving. (IE, stuck to making Bitcoin-using applications) In that context I sure as heck would loudly yell CAVE DIVING IS FUCKING DANGEROUS, DON'T DO IT. Sure, that's not quite telling the whole story, but the message is pretty close to the truth. The people that should be in the sport are the ones that take a statement like that as a warning to do their research; I have no reason to think the OP asking for developers was one of those people. Without merge mining if the value to the participants in the new system is greater than the harm done to the participants in the old system the total work on the new system's chain will still be positive and it has a chance of surviving. No, the harm to the old system participants is distributed among all the participants, not only miners (assuming miners have any speculative position at all). I'm not denying that people do crazy and stupid things, but let's at least allow the anti-competition attacker be equally crazy in both cases. Distributing harm among n people just reduces the harm for each person by a factor of n. That may or may not make that harm smaller than whatever tiny reward mining the chain would be. I have many other explanations for the few currencies that died with MM (can you remember any name?). At the beginning all altcoins were much smaller and easier to attack, all of them. Bitcoin mining pools didn't wanted to update to merged mining and didn't acted very rationally about it. Namecoin went through a really delicate situation just before hardforking to MM, but now is by far the most secure altcoin of them all, all thanks to MM. All rational bitcoin miners should also mine namecoin. Period. All You assume doing so has zero cost - it doesn't. Running namecoind involves effort and bandwidth on my part. those who consider it competition with their current Bitcoin speculative position, should just attack in the market by selling the namecoins as soon as they get them. Providing security for a chain DOES NOT give it an utility or rise its demand. Operation COSTS DO NOT CAUSE VALUE. Lets rephrase that A secure chain is no more useful than a less secure chain. A secure chain will not be more valuable than a less secure chain, all other things being equal. I don't think we're going to see eye to eye on this. -- 'peter'[:-1]@petertodd.org 28e2c0ade6ce50b5ce4d95037e5e2dcd500b4bb52adbe73c signature.asc Description: Digital signature --
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/6/14, Peter Todd p...@petertodd.org wrote: On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote: It's not meant to prove anything - the proof-of-sacrificed-bitcoins mentioned(*) in it is secure only if Bitcoin itself is secure and functional. I referred you to it because understanding the system will help you understand my thinking behind merge-mining. *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct because you're sacrificing the thing that the chain is about. Now that has some proof-of-stake tinges to it for sure - I myself am not convinced it is or isn't a viable scheme. I'm not sure I understand all the differences between proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm still convinced this doesn't have anything to do with MM PoW vs PoW. The idea looks very interesting and I will ask you and adam to understand it better on IRC, but take into account that when you say merged mining is insecure some people hear merged mined altcoins are less secure than non-MM altcoins (which is false) and somehow conclude scrypt altchains are more secure than SHA256 altchains. Whether we like it or not, many people believe that scrypt, quark or primecoin PoW algorithms are somehow more secure than SHA256, and claims that merged mining is insecure from core bitcoin developers contribute to spread those beliefs and that no new altcoin has been created with the intend of being merged mined for quite a while. I'm not trying to make you or anyone here responsible for the mistakes other people make. But rephrasing your claims as We're exploring new ideas for altchains that could be more secure than MM... sounds very different from MM is insecure, by the way look at this new idea... Feel free to ask for corrections in the example if you think it needs them. Feel free to bring your edge legal cases back, but please try to do it on top of the example. You're argument is perfectly valid and correct, *if* the assumptions behind it hold. The problem is you're assuming miners act rationally and have equal opportunities - that's a very big assumption and I have strong doubts it holds, particularly for alts with a small amount of hashing power. That's why I made the offer above. What you point out is the reason why freicoin started without merged mining, to grow its own independent security first, before starting to be merged mined. You know, something that I haven't made clear in this discussion is that while I think merge-mining is insecure, in the sense of should my new fancy alt-coin protocol widget use it?, I *also* don't think regular mining is much better. In some cases it will be worse due to social factors. (e.g. a bunch of big pools are going to merge-mine my scheme on launch day because it makes puppies cuter and kids smile) Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? The reason why I participated in the discussion was that I believe that merged mined PoW is more secure than completely-independent-from-bitcoin pow. And I thought that that was the general understanding in the Bitcoin development community. If that's the case, we agree on what's more important to me. About the new proposal, I don't have a firm opinion yet. I'm sorry but I have to understand it better and think about it in more depth. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/1/14, Peter Todd p...@petertodd.org wrote: On Tue, Dec 31, 2013 at 01:14:05AM +, 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. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. 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. The idea of sacrificing something external and make bitcoins appear still sounds crazy to me. I don't see how this pegging contributes in anything to a technical argument against merged mining, just looks like a moral argument against altcoin in general. But anyway, if you're going to make bitcoin's validation dependent on some external chain, it surprises me even more that you prefer that external dependency to be non-merge mineable. 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. Ok, so either we assume that the external-pegging hardfork wasn't a consensus or we just forget about the pegging and go back to talk about merged mining in general. Your argument is still for some reason some miners don't like the MM altcoin and prefer to attack it than to be profitable miners. If I mine BTC + NMC and you only mine BTC, it will be harder for you to compete against me: I can afford higher costs than you for the same BTC reward, since I'm also getting NMC. What you're saying is that Litecoin is more secure than Namecoin because while Litecoin can only be attacked by external attackers and current miners of other scrypt coins, Namecoin can also be attacked the Bitcoin miners that aren't currently mining Namecoin. This doesn't sound very reasonable to me. I think Namecoin is more secure than Litecoin and new coins should be created with SHA256 and merged mining in mind. At least merged mine with Litecoin if the still believe scrypt is so anti-ASIC and centralization-resistant (in fact Litecoin is more centralized than bitcoin with their shorter block intervals since better connections are favored, but that's another story). Merged mining is not only about not competing for proof of work like Satoshi defended. It is also about wasting resources: the more mining subsidies to different chains, the more wasted resources. By criticizing merged mining you're also indirectly legitimizing the same scamcoin madness you criticize. If you don't plan to merge mine, having SHA256 doesn't make sense because that makes you more fragile to potential bitcoin miners attacks and chainhopers. I don't think we would have this many alts living right now if all proof of work was SHA256. So if the anti-asic PoW myth and the absurd emerging morals of GPU-mining as an universal right weren't enough, you want to add an equally false merged mining is insecure to the collection of arguments supporting the search of the more absurd possible PoW holy grail. Please try to prove that MM is insecure and I'll try to prove your wrong. But we don't need zerocoin or an artificial pegging to discuss about this. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of them? -- 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
Re: [Bitcoin-development] The insecurity of merge-mining
On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote: You assume the value of a crypto-currency is equal to all miners, it's not. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. As I showed with my zerocoin example, often that is not the case, e.g. I do not support anonymity, or *can't* support it because of the local laws. Or for that matter, really boring examples like there's two competing implementations of some basic idea and we'd rather the winner be picked on technical merits rather than I have a grudge and a small pool so I'll this upstart at birth 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. The idea of sacrificing something external and make bitcoins appear still sounds crazy to me. I don't see how this pegging contributes in anything to a technical argument against merged mining, just looks like a moral argument against altcoin in general. It's a thought experiment; read my original post on how to make a zerocoin alt-chain and it might make more sense: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html Even better might be to use a merge-mined version of Mastercoin as an example, where the initial distribution of coins is fixed at genesis and forward from that is independent of the Bitcoin blockchain. 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. Ok, so either we assume that the external-pegging hardfork wasn't a consensus or we just forget about the pegging and go back to talk about merged mining in general. Your argument is still for some reason some miners don't like the MM altcoin and prefer to attack it than to be profitable miners. If I mine BTC + NMC and you only mine BTC, it will be harder for you to compete against me: I can afford higher costs than you for the same BTC reward, since I'm also getting NMC. What you're saying is that Litecoin is more secure than Namecoin because while Litecoin can only be attacked by external attackers and current miners of other scrypt coins, Namecoin can also be attacked the Bitcoin miners that aren't currently mining Namecoin. This doesn't sound very reasonable to me. I think Namecoin is more secure than Litecoin and new coins should be created with SHA256 and merged mining in mind. At least merged mine with Litecoin if the still believe scrypt is so anti-ASIC and centralization-resistant (in fact Litecoin is more centralized than bitcoin with their shorter block intervals since better connections are favored, but that's another story). Merged mining is not only about not competing for proof of work like Satoshi defended. It is also about wasting resources: the more mining subsidies to different chains, the more wasted resources. By criticizing merged mining you're also indirectly legitimizing the same scamcoin madness you criticize. If you don't plan to merge mine, having SHA256 doesn't make sense because that makes you more fragile to potential bitcoin miners attacks and chainhopers. I don't think we would have this many alts living right now if all proof of work was SHA256. So if the anti-asic PoW myth and the absurd emerging morals of GPU-mining as an universal right weren't enough, you want to add an equally false merged mining is insecure to the collection of arguments supporting the search of the more absurd possible PoW holy grail. Please try to prove that MM is insecure and I'll try to prove your wrong. But we don't need zerocoin or an artificial pegging to discuss about this. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of them? I'll give you a hint: marginal cost You're rant has rather little to do with my argument. -- 'peter'[:-1]@petertodd.org 0003065f32da26de1deda93eb722bf1dc4a1b787e7d68d282dbc signature.asc Description: Digital signature -- 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!
Re: [Bitcoin-development] The insecurity of merge-mining
On 1/3/14, Peter Todd p...@petertodd.org wrote: On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote: You assume the value of a crypto-currency is equal to all miners, it's not. They should be able to sell the reward at similar prices in the market. Attackers are losing the opportunity cost of mining the currency by attacking it, just like with Bitcoin. As I showed with my zerocoin example, often that is not the case, e.g. I do not support anonymity, or *can't* support it because of the local laws. Or for that matter, really boring examples like there's two competing implementations of some basic idea and we'd rather the winner be picked on technical merits rather than I have a grudge and a small pool so I'll this upstart at birth For whatever reason, someone wants to attack one chain, fine. But if the market is competitive enough and/or the reward of the MM-coin is high enough comparatively to the biggest ones in the MM group, then it is not profitable to mine. If you make a MM coin, it's fees reward are 5% of BTC + NMC rewards, and a jurisdiction somehow prohibits to mine the new coin (I can't imagine such a law being enforced, but I'll follow your argument), then BTC + NMC miners will just tend to disappear from that jurisdiction. It's a thought experiment; read my original post on how to make a zerocoin alt-chain and it might make more sense: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html Even better might be to use a merge-mined version of Mastercoin as an example, where the initial distribution of coins is fixed at genesis and forward from that is independent of the Bitcoin blockchain. I've read it until the end this time, and I have many doubts about proof of sacrifice as a security mechanism. Although it's certainly not proof of stake, it smells similarly to me. I'll have to think more about it. I still think that link doesn't prove anything against merged mining security. I think Namecoin has a lower reward for miners than litecoin and still has much better security. I haven't run the numbers but, will you deny it? How many amazon VMs do you need to attack each one of them? I'll give you a hint: marginal cost Please, don't give me clues and let's discuss the economics, that's precisely what I want and where I think you're getting it wrong. Since you refuse to try to prove that MM is less secure, I'll try myself to prove the opposite. Let's say we have currencies A, B, C and D, with daily rewards of 70, 20, 10 and 10 valuns respectively. A, B and C are merged mined, D is not. So with an equivalent reward to miners and one being merged mined while the other being independent, what's the more secure chain? C or D? Assuming similar hashing algorithms and perfect competition, the cost of producing enough hashing power to obtain 1 valun in rewards from D equals the cost of extracting 1 valun in rewards from the group A + B + C. Let's define 1 valun as the costs in energy and capital resources to produce X GH/s. So we have the following hashrates for each chain: A = 100*X GH/s B = 100*X GH/s C = 100*X GH/s D = 10*X GH/s Now here it comes our attacker paying for amazon servers. The costs in value to rent a server to produce X GH/s during a day cannot be lower than 1 valun, given the earlier assumptions. Let's assume it is equal to 1 valun for simplicity. So the cost to have 50% of D's hashing power for a day is 10 valuns. The cost to to have 50% of C's hashing power for a day is 100 valuns, but, hey, I'll use your hint now. Marginal costs. So I'm using 100 valuns to attack C, but I'm still getting my rewards from A and B as normal. As normal? Let's assume it's as normal first. I would be getting 90 valuns from chains A and B, so 100 - 90 = 10 valuns. Mhmm, it seems that although I need to make a considerably bigger investment in the case of attacking C, in the end the total costs will be the same of attacking D, that is 10 valuns. But, wait, I've doubled the hashrate!! Miners were getting 1 valun in reward per valun in mining costs when the hashrate was 100*X GH/s, now A and B hashrates are 200*X GH/s because I came to mine. Some of them will be smart enough to leave fast, but I will be really getting something between 45 and 90 valuns from honestly mining A + B, not 90 valuns as I was assuming. So it turns out that attacking D is actually cheaper than attacking C. Feel free to ask for corrections in the example if you think it needs them. Feel free to bring your edge legal cases back, but please try to do it on top of the example. PD I'm eager to read your post on BIP32-ish payment protocol, bloom filters and prefix filters, so I hope I'm not distracting you too much with this. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their
Re: [Bitcoin-development] The insecurity of merge-mining
On Tue, Dec 31, 2013 at 01:14:05AM +, 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 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 signature.asc Description: Digital signature -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote: On Tue, Dec 31, 2013 at 01:14:05AM +, 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=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The insecurity of merge-mining
On Wed, Jan 01, 2014 at 05:09:27AM +, 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 000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3 signature.asc Description: Digital signature -- 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=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
