From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VzF5i-0006yx-Vq for bitcoin-development@lists.sourceforge.net; Sat, 04 Jan 2014 00:27:51 +0000 Received: from mail-lb0-f174.google.com ([209.85.217.174]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VzF5h-0000LQ-Fp for bitcoin-development@lists.sourceforge.net; Sat, 04 Jan 2014 00:27:50 +0000 Received: by mail-lb0-f174.google.com with SMTP id y6so8418888lbh.5 for ; Fri, 03 Jan 2014 16:27:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=d8OIG2v3dIgGbSRMkfKm5hK0Xg4cP57DGaM92HulFCg=; b=H05OmTLWYANd3yQ/lL0aobK124zXRoim9c3CFLZ8Kb3uDItg07MKnmoYOrXa8T4x2w Pdx2WIa8FO9g3fPlXgM9RsaGD3cyC4VINdbYLQM+7BxCWgYkC7mibM+ZSE0dNTOfp9y0 HomWIZ3EEovulbN47n9YUH6Q0ny+J7lyLrvkTxT8scqbDWoqXGNP13VPU1UTz++nXXua G9iUM4Tx4LSZKFcCbWRv66EAeUN1rtief39YUACk8CclCDJcOFnHuQQM9syjEF9/ykY8 du2Bdvk8NvJve0md0RX5t3yUPM0cND/I2nA4TPItctZYKlg8Bn8C13VVTg1FwaK+oZ9x zbGA== X-Gm-Message-State: ALoCoQlElNssYG4JM8jbiCS0jf2huydLJcN2KtIFe6qYCubMoISQsWJqvaqrIPmQw6t9YA3UYgo0 MIME-Version: 1.0 X-Received: by 10.152.1.234 with SMTP id 10mr37954721lap.19.1388795262696; Fri, 03 Jan 2014 16:27:42 -0800 (PST) Received: by 10.112.74.71 with HTTP; Fri, 3 Jan 2014 16:27:42 -0800 (PST) X-Originating-IP: [85.53.148.187] In-Reply-To: <20140103210139.GB30273@savin> References: <20131230232225.GA10594@tilt> <201312310114.05600.luke@dashjr.org> <20140101045342.GA7103@tilt> <20140103210139.GB30273@savin> Date: Sat, 4 Jan 2014 01:27:42 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Peter Todd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1VzF5h-0000LQ-Fp Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] The insecurity of merge-mining X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 00:27:51 -0000 On 1/3/14, Peter Todd wrote: > On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Tim=F3n 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/msg= 02472.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 securi= ty. >> 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 =3D 100*X GH/s B =3D 100*X GH/s C =3D 100*X GH/s D =3D 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 =3D 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.