From: "Jorge Timón" <jtimon@monetize.io>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] The insecurity of merge-mining
Date: Fri, 10 Jan 2014 19:50:36 +0100 [thread overview]
Message-ID: <CAC1+kJPN=hWnrsTgJ2C+8vtm9BjGHSj5gt2FaAj_TBBo6iP40w@mail.gmail.com> (raw)
In-Reply-To: <20140110172205.GA11740@petertodd.org>
On 1/10/14, Peter Todd <pete@petertodd.org> wrote:
> 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.
But shouldn't your reasoning apply here so that ixcoin would be
destroyed by those who aren't even mining it. Because of the
"supposedly obvious" harm it does to Bitcoin through competition?
> 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.
That's precisely my worry. Most of those guys planning to implement
random altcoins will conclude after reading you that what they need is
not merged mining but yet another independent scrypt coin, or worse,
yet another stupid PoW algorithm.
> 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.
I'm approached many times with questions like "How much would it cost
to create a new altcoin?" (Thanks, BlueMatt for creating coingen!!).
I try to explain them that there's more currencies beyond p2p
currencies and they probably don't need that. I talk them about local
currencies, colored coins or open transactions as solution that
probably fit their needs much better without the need to bootstrap and
antire economy with a network of computer that consumes plenty of
resources.
If none of that fits them (say, for crazy experiments like datacoin or
gridcoin), I recommend them merged mining because is more secure for
them, more secure for bitcoin, and better for the environment and
everyone in general.
Still, for some reason a new non merged mined chain is the most popular choice.
Less efficient, less secure, more popular.
Why?
I wonder if devs warning against merged mining or making stupid
predictions like "bitcoin's PoW algorithm won't survive the year" have
anything to do with that...
>> > 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.
The harm TO THE MINERS alone (again, assuming they have any position
at all in the coins they're mining) is less than the "total harm" to
the competing system, assuming that's quantifiable at all.
Miners won't think about the "total harm", but only about their share
of harm vs their share of just mining the competing system alongside
with the old one.
>> 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.
Yeah, true, they will only mine if all those costs are lower than the
reward. Only the hashing is "for free".
I'm assuming that those costs are very small compared to the reward,
that is, that most of the reward pays for hashing and not validation.
>> 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."
Not exactly, a less secure chain can become completely useless due to
the lack of security.
What I'm saying is that a useless chain is still useless no matter the security.
> I don't think we're going to see eye to eye on this.
It is possible.
At least now we know each other position in MM.
I'm not sure if the silence means that only Maaku and Luke-Jr agree
with me on merged mining, that it is you who are more alone than me on
this one, or if it's just that not many people had taken the time to
think about this...
next prev parent reply other threads:[~2014-01-10 18:50 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
2014-01-10 18:50 ` Jorge Timón [this message]
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='CAC1+kJPN=hWnrsTgJ2C+8vtm9BjGHSj5gt2FaAj_TBBo6iP40w@mail.gmail.com' \
--to=jtimon@monetize.io \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=pete@petertodd.org \
/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