public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain
Date: Tue, 16 Dec 2014 07:36:42 -0500	[thread overview]
Message-ID: <20141216123642.GA19943@savin.petertodd.org> (raw)
In-Reply-To: <CAE28kUQ1tzCXp=90-1ZQG67f2Vh3uCrApJTbx+Lf1r-1byV4Lw@mail.gmail.com>

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

On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote:
> Usually at this point people say "we assume that miners aren't going to
> collude, otherwise even Bitcoin is not secure".
> Well, this is BS. The fact that a pool can acquire more than 50% of total
> hashpower was successfully demonstrated by ghash.io.
> But the thing is, Bitcoin doesn't offer one a good way to attack the whole,
> as there are powerful factors which will work against the attacker.
> But this is not the case with sidechains (or any merged-mined chains, for
> that matter).
> And once you have a clear incentive, collusion is much more likely.

+1

It's notable that blockstream hasn't published much if anything concrete
on what exactly you'd use merge-mined sidechains for; they're even worse
than Ethereum in that regard.

> > Proof of Burn is a real cost for following the rules.
> >
> 
>  So what? As long as cost is less than revenue, it is OK.

It's even better than that: if an attack does happen, the participants
in the consensus system have an incentive to defend against it to
maintain the value of their tokens. Proof-of-burn allows that defense to
be in response to a threat, and essentially unlimited in size.

So now any attacker knows that if they launch an attack in theory the
response could be as strong as the value of the system itself.

This can be improved upon with systems that allow the tokens to be
burned, "internal" proof-of-burn. This suffers from "nothing-at-stake"
vulnerabilities to an extent, OTOH within the context of the system it
is a true sacrifice of value; probably not a big deal in a zookeyv-style
block-DAG where multiple lines of history can be combined. Here the
incentives of the defenders are even more strongly tipped towards
burning their value to preserve the system, not unlike
replace-by-fee-scorched-earth thinking.

-- 
'peter'[:-1]@petertodd.org
00000000000000000e0c078667795abe21bfdebb913eba60cc7a625c732f0a89

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

  reply	other threads:[~2014-12-16 12:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 21:14 [Bitcoin-development] ACK NACK utACK "Concept ACK" Sergio Lerner
2014-12-09 21:30 ` Matt Corallo
2014-12-10  6:47   ` Wladimir
2014-12-10  7:35     ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Tamas Blummer
2014-12-10  8:30       ` patrick
2014-12-16  9:55         ` Alex Mizrahi
2014-12-16 12:36           ` Peter Todd [this message]
2014-12-15 14:55       ` Isidor Zeuner
2014-12-16  8:28         ` Tamas Blummer
2014-12-16 12:30       ` Tamas Blummer
2014-12-18 16:23         ` Tamas Blummer
2014-12-10  8:21     ` [Bitcoin-development] ACK NACK utACK "Concept ACK" Wladimir
2014-12-10 15:45       ` Austin Walne
2014-12-17  8:44         ` Wladimir
2014-12-10 15:52     ` Jeff Garzik
2014-12-16 23:40       ` Btc Drak
2014-12-11 12:09     ` [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain Isidor Zeuner
2014-12-11 14:56       ` Tamas Blummer
2014-12-15 10:21         ` Tamas Blummer
2014-12-15 12:39           ` Peter Todd
2014-12-15 13:06             ` Tamas Blummer
2015-02-04 13:54             ` Isidor Zeuner
2015-02-06  1:34               ` Peter Todd

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=20141216123642.GA19943@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=alex.mizrahi@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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