public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Alex Mizrahi <alex.mizrahi@gmail•com>
To: Bitcoin-Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)
Date: Mon, 3 Nov 2014 14:12:26 +0200	[thread overview]
Message-ID: <CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>

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

> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf


Haven't seen any material discussion of this paper in this mailing list, so
I'll start.
(Otherwise, I've seen Peter Todd's reaction on reddit.)

This paper fails to demonstrate that sidechains are anything more than a
wishful thinking.
It can be distilled down to this:
"We want such and such features, hence we'll use DMMS, the same thing
Bitcoin uses, thus it will be secure!"
Um, no.
Alt-coins also use DMMS, but aren't as secure as Bitcoin.

So DMMS does not work by itself, it is a mechanism to secure a blockchain
using economic incentives.
The sidechains paper does not mention this, as far as I can tell.

In my opinion, this is not acceptable. If you're making a proposal, you
need to describe what conditions are required for it to work.

Authors are clearly aware of the problem and mention it in section 6
"Future directions" 6.1. "Hashpower attack resistance".
The problem is they do not make it clear that the proposal just makes no
sense until this is solved.

In the discussions on reddit I've noticed that pretty much everybody
believes that release of sidechains paper implies that the proposal is
complete and now we are just waiting the implementation.

It doesn't help that the paper itself tries to sweep the problem under the
rug and has misleading statements.
Particularly, I'm talking about section "4.2. Fraudulent transfers":

"Reorganisations of arbitrary depth are in principle possible, which could
allow an attacker to
completely transfer coins between sidechains before causing a
reorganisation longer than the contest
period on the sending chain to undo its half of the transfer. ... If the
attacker is allowed to return the transferred coins to  the original
chain, he would increase the number of coins in his possession at the
expense of other users of the sidechain.
Before discussing how to handle this, we observe that this risk can be made
arbitrarily small by
simply increasing the contest period for transfers."

Wow, really? Is this risk stochastic?

The first sentence implies that attacker is able to cause a reorganization
of an arbitrary depth, but the rest of the section implies that
reorganizations are a naturally occurring phenomenon.

All in all, I find this paper really disappointing. It's going to be
influential (9 co-authors, many of which are regarded as Bitcoin core
developers, must be good!) and hyped, and thus might focus research on an
area which is fundamentally flawed.

[-- Attachment #2: Type: text/html, Size: 3540 bytes --]

  parent reply	other threads:[~2014-11-03 12:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 21:54 Adam Back
2014-10-22 22:01 ` Daniel Murrell
2014-10-22 22:35   ` Bryan Bishop
2014-10-22 22:52     ` Daniel Murrell
2014-10-23  0:00       ` Jeff Garzik
2014-10-31 18:58 ` Melvin Carvalho
2014-11-03 12:12 ` Alex Mizrahi [this message]
2014-11-03 14:14   ` Jorge Timón
2014-11-03 16:01     ` Alex Mizrahi
2014-11-03 17:32       ` Jorge Timón
2014-11-03 17:54       ` Andrew Poelstra
2014-11-03 19:38         ` odinn

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='CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com' \
    --to=alex.mizrahi@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /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