Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.53 as permitted sender)
	client-ip=74.125.82.53; envelope-from=alex.mizrahi@gmail.com;
	helo=mail-wg0-f53.google.com; 
MIME-Version: 1.0
In-Reply-To: <54880492.9060300@intersango.com>
References: <54876653.4020403@certimix.com> <548769FA.5040406@bluematt.me>
	<CA+s+GJAe9MeO+Sr0+2BRwu3q-Be5JQt_s_xdnBBEcquXqOyxcA@mail.gmail.com>
	<417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com>
	<54880492.9060300@intersango.com>
Date: Tue, 16 Dec 2014 11:55:50 +0200
Message-ID: <CAE28kUQ1tzCXp=90-1ZQG67f2Vh3uCrApJTbx+Lf1r-1byV4Lw@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: patrick <patrick@intersango.com>
Content-Type: multipart/alternative; boundary=047d7b874b262cbfeb050a525d21
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of
 burn on parent chain
Precedence: list

--047d7b874b262cbfeb050a525d21
Content-Type: text/plain; charset=UTF-8

>  The goal is to have an opportunity cost to breaking the rules.
>

You could as well have said "The goal is to implement it in a specific way
I want it to be implemented."
This makes zero sense.
You aren't even trying to compare properties of different possible
implementations, you just outright reject the alternatives.

So the thing is, relying on opportunity cost is rather problematic.

1. can't work when system isn't heavily used (you'll have to rely on the
honesty of miners instead)
2. chicken-and-egg: system is not secure until it is heavily used, and it
isn't heavily used until it is secure
3. finally, if the expected profit from attack is higher than the
opportunity cost of it, it just makes no sense

Let's put 1 and 2 aside. For the start, you need to prove that attack
cannot yield profits which are higher than honest mining.

The problem with it is that the total amount of money is much higher than
the amount of money which is being transacted in a short time frame. And it
is much higher than what fees might yield within a reasonable time frame.

So if there is a way to attack the whole (with a profit proportional to the
whole), you won't be able to rely on opportunity cost to prevent the attack.

Usually at this point people say "we assume that miners aren't going to
collude, otherwise even Bitcoin is not secure".
Well, this is BS. The fact that a pool can acquire more than 50% of total
hashpower was successfully demonstrated by ghash.io.
But the thing is, Bitcoin doesn't offer one a good way to attack the whole,
as there are powerful factors which will work against the attacker.
But this is not the case with sidechains (or any merged-mined chains, for
that matter).
And once you have a clear incentive, collusion is much more likely.


> Proof of Burn is a real cost for following the rules.
>

 So what? As long as cost is less than revenue, it is OK.

--047d7b874b262cbfeb050a525d21
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    The goal is to have an opportunity cost to breaking the rules.<br></div=
></blockquote><div><br></div><div>You could as well have said &quot;The goa=
l is to implement it in a specific way I want it to be implemented.&quot;</=
div><div>This makes zero sense.</div><div>You aren&#39;t even trying to com=
pare properties of different possible implementations, you just outright re=
ject the alternatives.</div><div><br></div><div>So the thing is, relying on=
 opportunity cost is rather problematic.</div><div><br></div><div>1. can=
9;t work when system isn&#39;t heavily used (you&#39;ll have to rely on the=
 honesty of miners instead)</div><div>2. chicken-and-egg: system is not sec=
ure until it is heavily used, and it isn&#39;t heavily used until it is sec=
ure</div><div>3. finally, if the expected profit from attack is higher than=
 the opportunity cost of it, it just makes no sense</div><div><br></div><di=
v>Let&#39;s put 1 and 2 aside. For the start, you need to prove that attack=
 cannot yield profits which are higher than honest mining.</div><div><br></=
div><div>The problem with it is that the total amount of money is much high=
er than the amount of money which is being transacted in a short time frame=
. And it is much higher than what fees might yield within a reasonable time=
 frame.</div><div><br></div><div>So if there is a way to attack the whole (=
with a profit proportional to the whole), you won&#39;t be able to rely on =
opportunity cost to prevent the attack.</div><div><br></div><div>Usually at=
 this point people say &quot;we assume that miners aren&#39;t going to coll=
ude, otherwise even Bitcoin is not secure&quot;.</div><div>Well, this is BS=
. The fact that a pool can acquire more than 50% of total hashpower was suc=
cessfully demonstrated by <a href=3D"http://ghash.io">ghash.io</a>.</div><d=
iv>But the thing is, Bitcoin doesn&#39;t offer one a good way to attack the=
 whole, as there are powerful factors which will work against the attacker.=
</div><div>But this is not the case with sidechains (or any merged-mined ch=
ains, for that matter).</div><div>And once you have a clear incentive, coll=
usion is much more likely.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">Proof of Burn is a real cost=
 for following the rules.</div></blockquote><div><br></div><div>=C2=A0So wh=
at? As long as cost is less than revenue, it is OK.</div></div></div></div>

--047d7b874b262cbfeb050a525d21--