path: root/84/7928c350f48ed0652a444d4584fd6f43fed9d0

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jtimon@jtimon.cc>) id 1XlLUf-0008Sh-2S
	for bitcoin-development@lists.sourceforge.net;
	Mon, 03 Nov 2014 17:32:55 +0000
Received: from mail-wg0-f48.google.com ([74.125.82.48])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1XlLUd-0004HS-8L
	for bitcoin-development@lists.sourceforge.net;
	Mon, 03 Nov 2014 17:32:40 +0000
Received: by mail-wg0-f48.google.com with SMTP id m15so6240206wgh.21
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 03 Nov 2014 09:32:31 -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
	:content-transfer-encoding;
	bh=vKgnhc4Y+1fA9GpvD75wFCr4G12ahrplJYVNwOo8Usc=;
	b=nAJnIq+Qo6lrhyVNwOnaWsB3nk+IyOeIiMahw4Sw8yjjKxvrOMmr4XgcqbY3Dqo0nb
	HeQEx5Jp7zJ5/WIwVLcvp4eZshspCZDYWnXL488pf6Bzpq3LQ9UJSHCBH1pErnUPM+Gw
	R00G/LAHsLe//HiuXGyVC8uFOc/TXr6mT8/HhCuQ1J47sTvSCpgRUcNqR5cMjYubAXsk
	evboMO2nzkFGfpewT+6Hhekvii0bdelcnoUgh9YEdGm2wp7l2JJr/YddKJTrtnzWhlqb
	LEAwXA57zeMzBzb6mN0Qj4UPnkCe1+ZzopOqiyOEPx0waszeukb4ocdLvLosmo5oaut8
	58kQ==
X-Gm-Message-State: ALoCoQkLQbqnq5eWPF+rC09lsXU/fauOurfJ57cVWzcmO7SL4CJ93PHMBZFwOkQqRv7EuNqbjas/
MIME-Version: 1.0
X-Received: by 10.194.241.194 with SMTP id wk2mr3959698wjc.132.1415035951466; 
	Mon, 03 Nov 2014 09:32:31 -0800 (PST)
Received: by 10.194.45.5 with HTTP; Mon, 3 Nov 2014 09:32:31 -0800 (PST)
X-Originating-IP: [85.59.60.175]
In-Reply-To: <CAE28kURz3smtwDvVuPQDFxosqB2tRNWiM3bf=BeLcjhJ2eiR5A@mail.gmail.com>
References: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
	<CAE28kUQS-ykQkLvZhKyR9ULh_=BPbdkm-TbVGOXdujy0e5xPFQ@mail.gmail.com>
	<CABm2gDqXkAKoNKwvznPfKKEq+c-F+Co7kudqQa2wHjcCU3iysQ@mail.gmail.com>
	<CAE28kURz3smtwDvVuPQDFxosqB2tRNWiM3bf=BeLcjhJ2eiR5A@mail.gmail.com>
Date: Mon, 3 Nov 2014 18:32:31 +0100
Message-ID: <CABm2gDpdTL7MLBgMFt9eSBdTDdFZNOF2EM4tXJbRtD48oHv8Dw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: 1XlLUd-0004HS-8L
Cc: 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?)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 03 Nov 2014 17:35:30 -0000
X-List-Received-Date: Mon, 03 Nov 2014 17:35:30 -0000

On Mon, Nov 3, 2014 at 5:01 PM, Alex Mizrahi <alex.mizrahi@gmail.com> wrote=
:
> This isn't applicable in case of sidechains: anybody with sufficient
> hashpower will be able to unlock a locked coin on the parent chain by
> producing an SPV proof.
> "Only if the miners form a shared valid history" isn't a requirement here=
,
> as miner will get bitcoins which aren't in any way connect to sidechain h=
e
> have wrecked.  Thus there is no incentive to behave honestly.

But if the majority of the sidechain miners keep working on the honest
chain, anyone can submit a reorg proof during the contest period that
invalidates this "unlockment" on the parent chain.
Honest sidechain miners will get rewarded in the sidechain, and those
rewards will only be valuable if they form a shared valid history.

> Whether it is enough depends on a variety of factors, including existence=
 of
> other chains miner can mine.
> You cannot assume that it is the same situation as with a simple
> single-chain model.

This is correct. There's many variables at play.

> E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining
> bitcoins as usual, and in parallel work on an SPV proof to claim these 10=
00
> BTC. (I assume that merged-mining is allowed.)
> In this case the amount of fees which miners could collect by honest mini=
ng
> on the sidechain is irrelevant, as long as it is smaller than 1000 BTC.

As explained many times, sidechains and merged mining are orthogonal:
pegged sidechains don't need to use merged mining just as merged
mining altchains don't need to be sidechains.
Anyway, I think you're somehow assuming that deciding to mine against
the sidechain instead of mining for its rewards.
This is simply not true. No matter how big the attack incentive is, if
you're assuming my 52560 contest period example and that the attacker
doesn't control the majority of the hashing power on the sidechain,
the probability of achieving a one-year reorg is negligible. In the
meantime honest nodes are getting some reward, let's say 0.1 BTC per
block. That's 5256 btc/year to the honest nodes vs 0 btc/year for the
attacker.
If the attacker controls, say, 10% of the network, he's losing 525.6
btc/year in opportunity costs for an extremely small chance of getting
1000 btc.

> This is quite different from attacks which can be performed on vanilla
> Bitcoin (see below), so I don't think you can say that the security model=
 is
> the same.

We're not claiming that the security model is the same, we just
compare it to Bitcoin's because it's similar in many senses.

>> 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."
>
>
> Yes, but that doesn't apply to reorganizations which attacker might cause
> intentionally.

Yes, that's precisely the kind of reorganizations the BITCOIN
WHITEPAPER is talking about in section "11 Calculations":
reorganizations caused intentionally by an attacker. Please read it
again.
"q_z =3D probability THE ATTACKER will ever catch up from z blocks behind".

> Hence I think it was disingenuous to include these two very different tre=
ats
> into one section:
> it sounds like you claim that attacker-induced reorganizations are unlike=
ly,
> while it isn't the case.

If it sounds to you like we're claiming that attacker-induced
reorganizations are not likely, maybe we could have expressed it some
other way. That was certainly not the intention.
That's not true for Bitcoin itself and that's not what we're claiming.

>> So the longer the contest period is, the harder it is to succeed with
>> a fraudulent transfer.
>
>
> Yes, but "harder" isn't same as "unlikely".

Exponentially harder with the number of blocks is good enough for me.

> Another problem with this section is that it only mentions reorganization=
s.
> But a fraudulent transfer can happen without a reorganization, as an
> attacker can produce an SPV proof which is totally fake. So this is not
> similar to double-spending, attacker doesn't need to own coins to perform=
 an
> attack.

That would be a reorganization too, you can't create a completely fake
history for a sidechain, the attacker will share some of the chain's
history.
Yes, the attacker can create an SPV proof of a fake chain and in that
sense, this is different from a regular double-spend.
If honest miners control the majority of the hashing power, they will
produce a valid chain longer than the fake chain. And then anyone can
use that reorg proof to stop the attacker before the contest period.
You see, "SPV security" is not the same as "SPV security with more
than 52560 confirmations of the transaction I'm receiving".

>> I hope this clarifies our assumptions.
>
> Yep, thanks. It looks like you assume that sidechain security will be
> similar to Bitcoin security in the long term.
> Now quite the assumptions I've been looking for, but OK...
>
> I'm sorry for the harsh tone, but I just find it hilarious that people wh=
o
> explained that proof-of-stake is not going to work because an attacker mi=
ght
> collect everybody's past signing keys to rewrite the whole history
> (I'm referring to this: https://download.wpsoftware.net/bitcoin/pos.pdf )
> didn't bother to mention that miners can collude to wreck a sidechain and
> get an awesome reward, basically for free.

Proof of work is not free, that's the whole point of proof of work.
As said, sidechains, like Bitcoin itself, relies on the assumption
that an attacker won't control a majority of the network. Satoshi's
paper just says that p must be greater than q.
We go beyond that precisely at the beginning of the "6.1 Hashpower
attack resistance" section:

"The main thrust of this paper surrounds two-way peg using SPV proofs,
which are forgeable by a
51%-majority and blockable by however much hashpower is needed to
build a sufficiently-long
proof during the transfer=E2=80=99s contest period. (There is a tradeoff on
this latter point =E2=80=94 if 33%
hashpower can block a proof, then 67% is needed to successfully use a
false one, and so on.)"

I'm happy to keep trying to clarify things. But I think we will
advance faster if you first tell me what do you think the contest
period is for.
Because that's I think the source of your misunderstandings. From what
you're saying, I don't think you're having the contest period into
account at all.