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: Mon, 6 Jan 2014 10:44:56 -0500	[thread overview]
Message-ID: <20140106154456.GA18449@savin> (raw)
In-Reply-To: <CAC1+kJNM=67Yw0Rde9y7H0v0x07MsWmh6oK++hDtsKEmLtqcNg@mail.gmail.com>

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

On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote:
> > It's a thought experiment; read my original post on how to make a
> > zerocoin alt-chain and it might make more sense:
> >
> > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html
> >
> > Even better might be to use a merge-mined version of Mastercoin as an
> > example, where the initial distribution of coins is fixed at genesis and
> > forward from that is independent of the Bitcoin blockchain.
> 
> I've read it until the end this time, and I have many doubts about
> proof of sacrifice as a security mechanism. Although it's certainly
> not proof of stake, it smells similarly to me. I'll have to think more
> about it.
> I still think that link doesn't prove anything against merged mining security.

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 think Namecoin has a lower reward for miners than litecoin and still
> >> has much better security. I haven't run the numbers but, will you deny
> >> it?
> >> How many amazon VMs do you need to attack each one of them?
> >
> > I'll give you a hint: "marginal cost"
> 
> Please, don't give me clues and let's discuss the economics, that's
> precisely what I want and where I think you're getting it wrong.
> Since you refuse to try to prove that MM is less secure, I'll try
> myself to prove the opposite.

<snip>

> 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.

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)

All I'm saying is that if you can afford the transaction fees stuffing
your data into the Bitcoin blockchain has orders of magnitude better
security. I'm not saying it'll be cheap - if miners start trying to
block your protocol blacklists they can make it fairly expensive for
your alt - but it will be just as secure against reorganization attack
as Bitcoin itself.

> PD I'm eager to read your post on BIP32-ish payment protocol, bloom
> filters and prefix filters, so I hope I'm not distracting you too much
> with this.

Heh, my one line reply might have been a bit harsh because of that. :)

-- 
'peter'[:-1]@petertodd.org
0000000000000000bf0a7634ebb2c909bada84ce0dce859e9298d3ac504db3c8

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

  reply	other threads:[~2014-01-06 15:45 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 [this message]
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
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=20140106154456.GA18449@savin \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=jtimon@monetize$(echo .)io \
    /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