public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Thu, 9 Jan 2014 18:19:04 +0100	[thread overview]
Message-ID: <CAC1+kJPjj1N59PbAKyymwcF3DC6x4Ra+z8LKdzae4oUvmpERCA@mail.gmail.com> (raw)
In-Reply-To: <20140106154456.GA18449@savin>

On 1/6/14, Peter Todd <pete@petertodd•org> wrote:
> On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> It's not meant to prove anything - the proof-of-sacrificed-bitcoins
> mentioned(*) in it is secure only if Bitcoin itself is secure and
> functional. I referred you to it because understanding the system will
> help you understand my thinking behind merge-mining.
>
> *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct
> because you're sacrificing the thing that the chain is about. Now that
> has some proof-of-stake tinges to it for sure - I myself am not
> convinced it is or isn't a viable scheme.

I'm not sure I understand all the differences between
proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm
still convinced this doesn't have anything to do with MM PoW vs PoW.
The idea looks very interesting and I will ask you and adam to
understand it better on IRC, but take into account that when you say
"merged mining is insecure" some people hear "merged mined altcoins
are less secure than non-MM altcoins" (which is false) and somehow
conclude "scrypt altchains are more secure than SHA256 altchains".
Whether we like it or not, many people believe that scrypt, quark or
primecoin PoW algorithms are somehow more secure than SHA256, and
claims that "merged mining is insecure" from core bitcoin developers
contribute to spread those beliefs and that no new altcoin has been
created with the intend of being merged mined for quite a while.
I'm not trying to make you or anyone here responsible for the mistakes
other people make.

But rephrasing your claims as "We're exploring new ideas for altchains
that could be more secure than MM..." sounds very different from "MM
is insecure, by the way look at this new idea..."

>> 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.
>
> You're argument is perfectly valid and correct, *if* the assumptions
> behind it hold. The problem is you're assuming miners act rationally and
> have equal opportunities - that's a very big assumption and I have
> strong doubts it holds, particularly for alts with a small amount of
> hashing power.

That's why I made the offer above.
What you point out is the reason why freicoin started without merged
mining, to grow its own independent security first, before starting to
be merged mined.

> You know, something that I haven't made clear in this discussion is that
> while I think merge-mining is insecure, in the sense of "should my new
> fancy alt-coin protocol widget use it?", I *also* don't think regular
> mining is much better. In some cases it will be worse due to social
> factors. (e.g. a bunch of big pools are going to merge-mine my scheme on
> launch day because it makes puppies cuter and kids smile)

Fair enough.
Do you see any case where an independently pow validated altcoin is
more secure than a merged mined one?
The reason why I participated in the discussion was that I believe
that merged mined PoW is more secure than
completely-independent-from-bitcoin pow.
And I thought that that was the general understanding in the Bitcoin
development community.

If that's the case, we agree on what's more important to me.

About the new proposal, I don't have a firm opinion yet. I'm sorry but
I have to understand it better and think about it in more depth.



  reply	other threads:[~2014-01-09 17:19 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 [this message]
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
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+kJPjj1N59PbAKyymwcF3DC6x4Ra+z8LKdzae4oUvmpERCA@mail.gmail.com \
    --to=jtimon@monetize$(echo .)io \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=pete@petertodd$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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