From: "Jeremy Spilman" <jeremy@taplink•co>
To: bitcoin-development@lists•sourceforge.net, Luke-Jr <luke@dashjr•org>
Subject: [Bitcoin-development] Merge mining
Date: Mon, 30 Dec 2013 23:28:10 -0800 [thread overview]
Message-ID: <op.w8x4c8vbyldrnw@laptop-air.hsd1.ca.comcast.net> (raw)
In-Reply-To: <201312310114.05600.luke@dashjr.org>
Merge mining lets Bitcoin miners support or attack an alt-coin without any
additional cost for their proof-of-work.
Since bitcoin miners have to install software to build and claim blocks in
the alt-coin, the percentage of bitcoin hashing power reflected toward the
alt-coin will follow some adoption curve based on convincing bitcoin
miners to opt-in.
Depending on where you are on that adoption curve or 'participation rate',
you need [a lot] less than 51% of of total Bitcoin hashing power in order
to 51% attack the alt-coin.
But there's so much 'dry powder' out there (GPUs), I wonder if *not*
supporting merge-mining is any better? At least the attacker has to do
some unique PoW, so you hope it's costing them something. Relatively large
amounts of hashing can definitely be deployed on target with zero startup
cost, and perhaps very little runtime cost (botnets).
I think the absolute cost of the PoW is very likely *not* the determining
factor in preventing a 51% attack on all but one or two blockchains
currently in existence.
Do I understand correctly, the question here is mostly a matter a game
theory?
On Mon, 30 Dec 2013 17:14:05 -0800, Luke-Jr <luke@dashjr•org> wrote:
> On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
>> that you are using merge-mining is a red-flag because without majority,
>> or
>> at least near-majority, hashing power an attacker can 51% attack your
>> altcoin at negligible cost by re-using existing hashing power.
>
> I strongly disagree on this isolated point. Using the same logic,
> Bitcoin is
> vulnerable to an attacker at negligible cost by re-using existing hashing
> power from mining Namecoin. Any non-scam altcoin is pretty safe using
> merged
> mining, since any would-be attacker is going to have it in their
> interests to
> invest in the altcoin instead of attacking it. It's only the scam ones
> that want to pump & dump with no improvements, that are really at risk
> here.
>
> The rational decision for a non-scam altcoin, is to take advantage of
> merged mining to get as much security as possible. There are also some
> possible
> tricks to get the full security of the bitcoin miners even when not all
> participate in your altcoin (but this area probably needs some studying
> to get right).
>
> Luke
>
next prev parent reply other threads:[~2013-12-31 7:33 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 ` Jeremy Spilman [this message]
2013-12-31 7:38 ` [Bitcoin-development] Merge mining 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
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=op.w8x4c8vbyldrnw@laptop-air.hsd1.ca.comcast.net \
--to=jeremy@taplink$(echo .)co \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(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