summaryrefslogtreecommitdiff
path: root/a0/f7ac6c61c6e0de47c8fbba1b187fa58e92efe4
blob: b1351e93f0bd13ed08f70ec50cf6ec7d3062fcd7 (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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1VyDp6-0001q6-TH
	for bitcoin-development@lists.sourceforge.net;
	Wed, 01 Jan 2014 04:54:28 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.43 as permitted sender)
	client-ip=62.13.149.43; envelope-from=pete@petertodd.org;
	helo=outmail149043.authsmtp.co.uk; 
Received: from outmail149043.authsmtp.co.uk ([62.13.149.43])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1VyDp5-0004vF-Mk for bitcoin-development@lists.sourceforge.net;
	Wed, 01 Jan 2014 04:54:28 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s014sH25031960;
	Wed, 1 Jan 2014 04:54:17 GMT
Received: from tilt (dhcp186-112.theedge.ca [216.108.186.112])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s014s8dn021751
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Wed, 1 Jan 2014 04:54:14 GMT
Date: Tue, 31 Dec 2013 23:53:42 -0500
From: Peter Todd <pete@petertodd.org>
To: Luke-Jr <luke@dashjr.org>
Message-ID: <20140101045342.GA7103@tilt>
References: <CAMkFLsSwKEiEtV1OaAsGPiU8iAWbb77fDNJDmRwbgKnZ_kjG6Q@mail.gmail.com>
	<20131230232225.GA10594@tilt> <201312310114.05600.luke@dashjr.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <201312310114.05600.luke@dashjr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: c40c3855-72a0-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdgMUElQaAgsB AmIbW1BeVVl7WGU7 aQtXcwRdalRPVwN0
	UUlLXVdaExppT18B BxpdWk0sdwdHf3tx K0dmW3lZEhd+dRV+
	SktRCGoENGd9aWFK U10KfwNWbQNKfBpM agF+USdcZitlM3Bw
	LCUyIzs2PDMaJClL TwUKNVcfR1o+VgI8 SlgDGy4iFlAfRjki
	ZxsoYlsRBkkcd0Az N1onVjoA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 216.108.186.112/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1VyDp5-0004vF-Mk
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: Wed, 01 Jan 2014 04:54:29 -0000


--ew6BAiZeqk4r7MaW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> I strongly disagree on this isolated point. Using the same logic, Bitcoin=
 is=20
> vulnerable to an attacker at negligible cost by re-using existing hashing=
=20
> power from mining Namecoin. Any non-scam altcoin is pretty safe using mer=
ged=20
> mining, since any would-be attacker is going to have it in their interest=
s to=20
> invest in the altcoin instead of attacking it. It's only the scam ones th=
at=20
> want to pump & dump with no improvements, that are really at risk here.
>=20
> The rational decision for a non-scam altcoin, is to take advantage of mer=
ged=20
> mining to get as much security as possible. There are also some possible=
=20
> tricks to get the full security of the bitcoin miners even when not all=
=20
> participate in your altcoin (but this area probably needs some studying t=
o get=20
> 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.

--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3

--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJSw59VAAoJECSBQD2l8JH72RUH/jKGDjjsqGMcsDzPstXj5LyV
XKw35/j5yYqRTK7Lsloyuz5qUTuCgcSkHp8dSzqBiP9LcN+EF+XH2eyuQv892Zzk
4ejFilQefX397xUMFaqbOyMfA3JxnPLJ0NbesRjrZZcqYhfvgi5nPZAwDxCP/Ttv
QuLmtK+9VN+YOdQYMEyUeGAGzjMKz0cRTYFKQijOyMHxm0dSjo5ZCfHZS3lW0F5U
oblB67H3NWSYoqZIR83fnygdAReETF+igwwnfahul0GGHipQw1nFUmXRkPrPJO/5
J/WqTUA4FecHNxzKwFKHN80tDYEz3LCxFe4iu7AfZ9RfZgIcFxLJv4gsX/lAYlo=
=qNgu
-----END PGP SIGNATURE-----

--ew6BAiZeqk4r7MaW--