[Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

[Jorge Timón]

On Mon, Nov 3, 2014 at 5:01 PM, Alex Mizrahi <alex.mizrahi at 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 he
> 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 1000
> BTC. (I assume that merged-mining is allowed.)
> In this case the amount of fees which miners could collect by honest mining
> 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 = probability THE ATTACKER will ever catch up from z blocks behind".

> Hence I think it was disingenuous to include these two very different treats
> into one section:
> it sounds like you claim that attacker-induced reorganizations are unlikely,
> 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 reorganizations.
> 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 who
> explained that proof-of-stake is not going to work because an attacker might
> 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’s contest period. (There is a tradeoff on
this latter point — 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.