public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: "Jorge Timón" <jtimon@monetize.io>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The insecurity of merge-mining
Date: Fri, 10 Jan 2014 12:22:06 -0500	[thread overview]
Message-ID: <20140110172205.GA11740@petertodd.org> (raw)
In-Reply-To: <CAC1+kJP0ehkSmrmJ-HSioF=W-hGjF2tXfWE9pOUYFcQpZiQ4cg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5040 bytes --]

On Fri, Jan 10, 2014 at 01:29:03PM +0100, Jorge Timón wrote:
> On 1/10/14, Peter Todd <pete@petertodd.org> 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.
> 
> 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.
> 
> 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 demand.
> 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.

-- 
'peter'[:-1]@petertodd.org
000000000000000028e2c0ade6ce50b5ce4d95037e5e2dcd500b4bb52adbe73c

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2014-01-10 17:22 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-29 18:53 [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space Evan Duffield
2013-12-29 19:27 ` Matt Corallo
2013-12-30 23:22 ` Peter Todd
2013-12-31  1:14   ` Luke-Jr
2013-12-31  7:28     ` [Bitcoin-development] Merge mining Jeremy Spilman
2013-12-31  7:38       ` rob.golding
2014-01-04  8:49         ` David Vorick
2014-01-04 10:05           ` Jorge Timón
2014-01-04 10:08             ` David Vorick
2014-01-04 10:34               ` Jorge Timón
2014-01-01  4:53     ` [Bitcoin-development] The insecurity of merge-mining Peter Todd
2014-01-01  5:09       ` Luke-Jr
2014-01-01  5:25         ` Peter Todd
2014-01-03 19:14       ` Jorge Timón
2014-01-03 21:01         ` Peter Todd
2014-01-04  0:27           ` Jorge Timón
2014-01-06 15:44             ` Peter Todd
2014-01-09 17:19               ` Jorge Timón
2014-01-10 11:11                 ` Peter Todd
2014-01-10 11:25                   ` Peter Todd
2014-01-10 12:37                     ` Jorge Timón
2014-01-10 12:29                   ` Jorge Timón
2014-01-10 17:22                     ` Peter Todd [this message]
2014-01-10 18:50                       ` Jorge Timón
2014-01-03  5:11 ` [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space Troy Benjegerdes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140110172205.GA11740@petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jtimon@monetize.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox