summaryrefslogtreecommitdiff
path: root/ec/b398b9a844c3569e749128c0c27683e425a3c6
blob: 6368ffa1c4f19242220d233b2d739fa300138ada (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
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 <jtimon@monetize.io>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <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
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 04 Jan 2014 00:27:51 -0000

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.