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 18:01:46 +0200 [thread overview]
Message-ID: <CAE28kURz3smtwDvVuPQDFxosqB2tRNWiM3bf=BeLcjhJ2eiR5A@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDqXkAKoNKwvznPfKKEq+c-F+Co7kudqQa2wHjcCU3iysQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]
> 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.[...]"
>
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.
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
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.
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.
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.
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.
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.
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".
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.
> 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.
something something the mote in thy brother's eye something something
[-- Attachment #2: Type: text/html, Size: 5358 bytes --]
next prev parent reply other threads:[~2014-11-03 16:01 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
2014-11-03 14:14 ` Jorge Timón
2014-11-03 16:01 ` Alex Mizrahi [this message]
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='CAE28kURz3smtwDvVuPQDFxosqB2tRNWiM3bf=BeLcjhJ2eiR5A@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