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 06:11:28 -0500 [thread overview]
Message-ID: <20140110111128.GC25749@savin> (raw)
In-Reply-To: <CAC1+kJPjj1N59PbAKyymwcF3DC6x4Ra+z8LKdzae4oUvmpERCA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3663 bytes --]
On Thu, Jan 09, 2014 at 06:19:04PM +0100, Jorge Timón wrote:
> 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.
Proof-of-sacrified-bitcoins is always a true sacrifice - provided
Bitcoin itself maintains consensus the proof is a guarantee that
something of value was given up.
Proof-of-sacrificed-"newcoins" means that within some consensus system I
created a signed statement that *within the system* means I lose
something of value. However that sacrifice is only valid if the
consensus of the system includes that sacrifice within the consensus,
and if the mechanism by which that consensus is maintained has anything
to do with those sacrifices you quickly find yourself on pretty shakey
ground.
> > 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?
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.
The problem here is that my new system has a substantial *negative*
value to those existing Namecoin holders - if it catches on the value of
their Namecoin investment in the form of coins and domain names may go
down. Thus for them doing nothing has a negative return, attacking my
coin has a positive return minus costs, and with merge-mining the costs
are zero.
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.
Of course, this is what Luke-Jr was getting at when he was talking about
scam-coins and merge mining: if you're alt-currency is a currency, and
it catches on, then it dilutes the value of your existing coins and
people who own those coins have an incentive to attack the competitor.
That's why merge-mined alt-coins that are currencies get often get
attacked very quickly.
--
'peter'[:-1]@petertodd.org
00000000000000028a5c9edabc9697fe96405f667be1d6d558d1db21d49b8857
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-01-10 11:11 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 [this message]
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=20140110111128.GC25749@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