From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XlInk-0003Yt-SM for bitcoin-development@lists.sourceforge.net; Mon, 03 Nov 2014 14:40:13 +0000 Received: from mail-wi0-f173.google.com ([209.85.212.173]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XlInj-0006eU-34 for bitcoin-development@lists.sourceforge.net; Mon, 03 Nov 2014 14:40:12 +0000 Received: by mail-wi0-f173.google.com with SMTP id n3so6646582wiv.12 for ; Mon, 03 Nov 2014 06:40:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9j6Tfb2SHiqCFg2kLixrEoz+fdmcoI+DrKk3UnNLPsQ=; b=hMNrOVTqrnKFE75v3I+CIXvSHqsu9Pm9tPOStzuDHBINyll4HMWKjXrlWb6vZUSYDw IZuOYmW91qvBImcXzTSrxjHnG7bOtIZ7LTmcKjFshZLLB6aB1AFCmtEkNzcm4jrv/BQy jjIAzHuihMUtjTcA3OAZt0QRkccQPE7Ko/Yw0yU/a1680wA9RDuzdGOisuffQI6ADokD bDe7F8LH9I1JUKXcAjhX2nDjeK0Rwjy8tlr5wWqtFfGHlMNWYlTGIhecL7XAIuewh/nv CUwvKV1bU9bCktyK4S+pc5Y71ST/l5HCBRW+MDQqqtpMdTvLjxzRPvgCRnA3FS0X/Srg S3Yw== X-Gm-Message-State: ALoCoQljE9lY8I2gHPcTvT0NrSSOD1ZP+22bwYEHncYJBf6z/HY7xeRzRNHeow5im6sND6Elyoa4 MIME-Version: 1.0 X-Received: by 10.180.98.170 with SMTP id ej10mr7091597wib.74.1415024089578; Mon, 03 Nov 2014 06:14:49 -0800 (PST) Received: by 10.194.45.5 with HTTP; Mon, 3 Nov 2014 06:14:49 -0800 (PST) X-Originating-IP: [85.59.57.28] In-Reply-To: References: Date: Mon, 3 Nov 2014 15:14:49 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Alex Mizrahi Content-Type: text/plain; charset=UTF-8 X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1XlInj-0006eU-34 Cc: Bitcoin-Dev Subject: Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Nov 2014 14:40:14 -0000 On Mon, Nov 3, 2014 at 1:12 PM, Alex Mizrahi wrote: > >> 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. >From the introduction "[...]Because signers prove computational work, rather than proving secret knowledge as is typical for digital signatures, we refer to them as miners. To achieve stable consensus on the blockchain history, economic incentives are provided where miners are rewarded with fees and subsidies in the form of coins that are valuable only if the miners form a shared valid history, incentivising them to behave honestly.[...]" Ignoring altrustic miners, the irreversibility of a DMMS chain obviously depends on the rewards received by miners on that chain. Nobody is claiming that sidechains will be "as secure bitcoin", any 2 way pegged assets is always "more secure" (probably too vague of a term in this context) in its original chain. > 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. Since all seigniorage from Bitcoin's initial distribution is spent on mining subsidies for the main chain, it is not available to subsidize sidechains too. Thus sidechains, in principle, reward their miners with the same Bitcoin will use in the future: only transaction fees. Since some people claim that won't be enough (is not always clear to me if they believe that won't be enough for sidechains or also for bitcoin when the subsidies are gone), we included this section with other ideas we have explored to further. Some of them, like "time-shifted fees" could be interesting for Bitcoin itself in the future. > 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. Reorganizations are both a naturally occurring phenomenon and something that an attacker may cause to revert history. Section "11. Calculations" of the Bitcoin whitepaper gives you this formula (in C code): #include double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } Also says "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases." In this case, the contest period determines z, the number of blocks the attacker has to catch up from the honest chain. So the longer the contest period is, the harder it is to succeed with a fraudulent transfer. For example, if a given sidechain chooses 52560 as the contest period (1 year assuming 10 min blocks), it will be very hard for an attacker to produce a fake alternative longest-than-the-last-year-of-history fork to steal coins. A sidechain with such an extreme contest period would probably not be very practical though, since honest users would have to wait more than a year to complete transfers from the parent chain to the sidechain and viceversa. I hope this clarifies our assumptions.