1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1Y0orG-0007wz-Az
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Dec 2014 09:55:58 +0000
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;
Received: from mail-wg0-f53.google.com ([74.125.82.53])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y0orE-00074Z-CF
for bitcoin-development@lists.sourceforge.net;
Tue, 16 Dec 2014 09:55:58 +0000
Received: by mail-wg0-f53.google.com with SMTP id l18so16608716wgh.26
for <bitcoin-development@lists.sourceforge.net>;
Tue, 16 Dec 2014 01:55:50 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.187.164 with SMTP id ft4mr59227803wjc.76.1418723750361;
Tue, 16 Dec 2014 01:55:50 -0800 (PST)
Received: by 10.27.203.198 with HTTP; Tue, 16 Dec 2014 01:55:50 -0800 (PST)
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
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(alex.mizrahi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Y0orE-00074Z-CF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Merged mining a side chain with proof of
burn on parent chain
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: Tue, 16 Dec 2014 09:55:58 -0000
--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 "The goa=
l is to implement it in a specific way I want it to be implemented."</=
div><div>This makes zero sense.</div><div>You aren'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't heavily used (you'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'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'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't be able to rely on =
opportunity cost to prevent the attack.</div><div><br></div><div>Usually at=
this point people say "we assume that miners aren't going to coll=
ude, otherwise even Bitcoin is not secure".</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'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--
|
