MIME-Version: 1.0
In-Reply-To: <20140103210139.GB30273@savin>
References: <CAMkFLsSwKEiEtV1OaAsGPiU8iAWbb77fDNJDmRwbgKnZ_kjG6Q@mail.gmail.com>
	<20131230232225.GA10594@tilt> <201312310114.05600.luke@dashjr.org>
	<20140101045342.GA7103@tilt>
	<CAC1+kJPTYzvU4ngFspvULDMvQK4ckkM719Y+_hx272PCU3amyg@mail.gmail.com>
	<20140103210139.GB30273@savin>
Date: Sat, 4 Jan 2014 01:27:42 +0100
Message-ID: <CAC1+kJNM=67Yw0Rde9y7H0v0x07MsWmh6oK++hDtsKEmLtqcNg@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The insecurity of merge-mining
Precedence: list

On 1/3/14, Peter Todd <pete@petertodd.org> 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.