From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1W1fmv-0003oy-Rg for bitcoin-development@lists.sourceforge.net; Fri, 10 Jan 2014 17:22:29 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.109 as permitted sender) client-ip=62.13.148.109; envelope-from=pete@petertodd.org; helo=outmail148109.authsmtp.co.uk; Received: from outmail148109.authsmtp.co.uk ([62.13.148.109]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1W1fmr-0003Q2-BS for bitcoin-development@lists.sourceforge.net; Fri, 10 Jan 2014 17:22:29 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0AHMFAW091431; Fri, 10 Jan 2014 17:22:15 GMT Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s0AHM66M012455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 17:22:08 GMT Date: Fri, 10 Jan 2014 12:22:06 -0500 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20140110172205.GA11740@petertodd.org> References: <20131230232225.GA10594@tilt> <201312310114.05600.luke@dashjr.org> <20140101045342.GA7103@tilt> <20140103210139.GB30273@savin> <20140106154456.GA18449@savin> <20140110111128.GC25749@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: bc3cb8b4-7a1b-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwIUElQaAgsB AmIbWlNeUl97WWo7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQhxw fmMYVGRydgdCfXs+ Z0FgWHAVDhd5JhR1 EEpJEjwHN3phaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIj4x DxEEBjgkAFcEWzR7 KBJuL1MGE0tUN0Q0 MF0uMQAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/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: 1W1fmr-0003Q2-BS 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: Fri, 10 Jan 2014 17:22:30 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Tim=F3n wrote: > On 1/10/14, Peter Todd 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. >=20 > 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. >=20 > 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 de= mand. > 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. --=20 'peter'[:-1]@petertodd.org 000000000000000028e2c0ade6ce50b5ce4d95037e5e2dcd500b4bb52adbe73c --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJS0Cw9AAoJEBmcgzuo5/CFykYH/1Vo2chqAyPz9cCXGAC4/UYc kbe3DbQb4lZ9bqjX0dPT1mz5J2LA/qKcH2F1NkwIqByphbum671NiamXY6BRDggv sstQiKLewym0rzg/+9QD79U4RiLvV2IlmEcacMbwSe0xxT1hJ0qy949CAyEqs8Ow /2106lNilLFigS5h3WxqejnnfdRpCnt4KIlZA1vPbOe3NXr+9ZD+uNwmhUpliEyS kc0gXEGSWYV44i4Z0n+vkVYdlJzSu9SJg1ll1S0/gioPE7QJ0sC0TMHDkmfHXc9o SGI6aIZwDZZLRaWk5UF++twjIXIQFl/83gJwFRgCncUELU1/h1zJZUit/99KkB8= =Jwr/ -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK--