From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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> <417518B4-1E4D-4467-BC87-95C9EAF0C599@bitsofproof.com> <54880492.9060300@intersango.com> Date: Tue, 16 Dec 2014 11:55:50 +0200 Message-ID: From: Alex Mizrahi To: patrick 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

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

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

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

1. can= 9;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 sec= ure until it is heavily used, and it isn't heavily used until it is sec= ure
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 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.

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 coll= ude, otherwise even Bitcoin is not secure".
Well, this is BS= . The fact that a pool can acquire more than 50% of total hashpower was suc= cessfully 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 ch= ains, for that matter).
And once you have a clear incentive, coll= usion is much more likely.
=C2=A0
Proof of Burn is a real cost= for following the rules.

=C2=A0So wh= at? As long as cost is less than revenue, it is OK.
--047d7b874b262cbfeb050a525d21--