path: root/30/7f182d77c0cf46e40e7c29fb98cb8eb9d515dc

Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DC0725AC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 09:51:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com
	[209.85.218.50])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25A5B1AE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 09:51:28 +0000 (UTC)
Received: by mail-oi0-f50.google.com with SMTP id l18so194192379oig.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 23 May 2017 02:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; 
	bh=FeT23f45sWePAECppDhpruhanB8FI/XAQeMe1ib0tO8=;
	b=t+7YgvFP5eq/R8fuYmkzUcFmLeXwDmXQz6spKw1NuuCmapCHekcvVXjWDQF4VBCH/q
	K0kPcp7uoUPhoIxtlP1TyfV2eWtaPeQplmu7QZ8EkYJCTDlzVKZuuSxrDvyjjOtR9IT2
	aU4T40XxRtEArfwqTHo1fGaJyTnGjBmhHco/pw7mY8wv4wWl3RCNrwbFvEXbANbfImxO
	RnoaQ8Kuv39mrezTLxvGaxzqT9q3XvHXFBx4F2Vwy5AuELtb5a6MEplrA6WSp08c1MG6
	4Twpi89LZULZ4Eno3Kh5e9gh0JQzc5x+pcY7AHQrq2FBMbIi/Oj9o3aF8N6bV/xtksat
	NGdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:cc;
	bh=FeT23f45sWePAECppDhpruhanB8FI/XAQeMe1ib0tO8=;
	b=Kfw61QtejyMy+L/d+4OM5U21EkBlnu8RzGvB86vNuX8rCV9R5FEBvvqu47DrK/wagf
	4oRnvZTt+xhot+jBR6QdPANy9u0I4maMxPhK/7JZDTB0mjYv10kYLxHpa3/5BmLTKyBD
	7AG718TdGO6mKSGeCepdQGKuatfrMEEIGdrBxdNJnR/k7JKpFFS2L9gDZ/EcSyOb+Jxu
	qKDUZfqe0KAgpY0cJkJn3ItKMFCE4pPlm66lDi9zkjI277FAGTvUiz1dBoJLe2oL/CCg
	2fk4jEdvFyZTTzudha7HDXrz7Kwbf2imGayvBSIRHVrK8BVpRl9CHJQkl0/t3K8zEADa
	OdcA==
X-Gm-Message-State: AODbwcBgONDZRY4qTsmxLI3VHMSydGpW5nJfsljZXAppGxlGe1F9o6us
	1bUlJ6Y/cttzUKc5PLoZIHb1EyVlyw==
X-Received: by 10.157.19.67 with SMTP id q3mr1385204otq.110.1495533087107;
	Tue, 23 May 2017 02:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.100.89 with HTTP; Tue, 23 May 2017 02:51:26 -0700 (PDT)
In-Reply-To: <CA+XQW1hRhcxJBoOJ57YG0t5y5j1Qm3RO4wr2eXV5V-UzDaiPPw@mail.gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
	<dhstGQudLBiwjDlaRrmMfy-ixwvXcwMr1CzCkPKh285RLICGZixkbdwpTDc2Sgz8eYIqSem8lwxW6QeJCD7aFfwQjLDnZ2NmOw0Zzd-KgSs=@protonmail.com>
	<CA+XQW1jZpJ9wnEg47fouyywL09=_vU8dMP3owkkuNqRvzTZUDg@mail.gmail.com>
	<CAE-z3OUYuAXE2+h60A=r4UyGU4CSQuF98oFgHnD7iaj-=Z=yOw@mail.gmail.com>
	<CA+XQW1hRhcxJBoOJ57YG0t5y5j1Qm3RO4wr2eXV5V-UzDaiPPw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Tue, 23 May 2017 10:51:26 +0100
Message-ID: <CAE-z3OVWXN58X-+nAFTm61G1=v_1xrniyrBy8x=VRG4N149aXQ@mail.gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113919b0682ff805502deef6"
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
	RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Drivechain -- Request for Discussion
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 09:51:29 -0000

--001a113919b0682ff805502deef6
Content-Type: text/plain; charset="UTF-8"

On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin@gmail.com> wrote:

> I would replace "Bitcoins you manage to steal" with "Bitcoins you manage
> to double-spend". Then, it still seems the same to me.
>
>
With double spending, you can only get ownership of coins that you owned at
some point in the past.  Coins that are owned by someone else from coinbase
to their current owners cannot be stolen by a re-org (though they can be
moved around).

With BMM, you can take the entire reserve.  Creating a group of double
spenders can help increase the reward.


>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in addition
> to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
>
>
That is a fair point.  If sidechains are how Bitcoin is scaled, then
shaking confidence in a side-chain would shake confidence in Bitcoin's
future.

I wasn't thinking of a direct miner 51% attack.  It is enough to assume
that a majority of the miners go with the highest bidder each time.

If (average fees) * (timeout) is less than the total reserves, then it is
worth it for a 3rd party to just bid for his theft fork.  Miners don't have
to be assumed to be coordinating, they just have to be assumed to take the
highest bid.

Again, I don't really think it is that different. One could interchange
> "recent txns" (those which could be double-spent within 2-3 weeks) with
> "sidechain deposit tnxs".
>

It is not "recent txns", it is recent txns that you (or your group) have
the key for.  No coordination is required to steal the entire reserve from
the sidechain.

Recent txns and money on the sidechain have the property that they are
riskier than money deep on the main chain.  This is the inherent point
about sidechains, so maybe not that big a deal.

My concern is that you could have a situation where an attack is possible
and only need to assume that the miners are indifferent.

If the first attacker who tries it fails (say after creating a fork that is
90% of the length required, so losing a lot of money), then it would
discourage others.   If he succeeds, then it weakens sidechains as a
concept and that creates the incentive for miners to see that he fails.

I wonder how the incentives work out.  If a group had 25% of the money on
the sidechain, they could try to outbid the attacker.

In fact, since the attacker, by definition, creates an illegal fork, the
effect is that he reduces the block rate for the side chain (possibly to
zero, if he wins every auction).  This means that there are more
transactions per block, if there is space, or more fees per transaction, if
the blocks are full.

In both cases, this pushes up the total fees per block, so he has to pay
more per block, weakening his attack.  This is similar to where transaction
spam on Bitcoin is self-correcting by increasing the fees required to keep
the spam going.

Is there a description of the actual implementation you decided to go with,
other than the code?

--001a113919b0682ff805502deef6
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">On M=
on, May 22, 2017 at 9:00 PM, Paul Sztorc <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:truthcoin@gmail.com" target=3D"_blank">truthcoin@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""></span><div =
dir=3D"auto"><div dir=3D"auto"><span style=3D"font-family:sans-serif">I wou=
ld replace &quot;Bitcoins you manage to steal&quot; with &quot;Bitcoins you=
 manage to double-spend&quot;. Then, it still seems the same to me.</span><=
br></div><span class=3D""><div dir=3D"auto"><span style=3D"font-family:sans=
-serif"><br></span></div></span></div></blockquote><div><br>With double spe=
nding, you can only get ownership of coins that you owned at some point in =
the past.=C2=A0 Coins that are owned by someone else from coinbase to their=
 current owners cannot be stolen by a re-org (though they can be moved arou=
nd).=C2=A0 <br><br></div><div>With BMM, you can take the entire reserve.=C2=
=A0 Creating a group of double spenders can help increase the reward.<br></=
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 dir=3D"auto"><span=
 class=3D""><div dir=3D"auto"><br></div></span><div dir=3D"auto">It may des=
troy great value if it shakes confidence in the sidechain infrastructure. T=
hus, the value of the stolen BTC may decrease, in addition to the lost futu=
re tx fee revenues of the attacked chain.</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><a href=3D"http://www.truthcoin.info/blog/drivechain/#dri=
vechains-security" target=3D"_blank">http://www.truthcoin.info/<wbr>blog/dr=
ivechain/#drivechains-<wbr>security</a><br></div><div dir=3D"auto"><br></di=
v></div></blockquote><div><br></div><div>That is a fair point.=C2=A0 If sid=
echains are how Bitcoin is scaled, then shaking confidence in a side-chain =
would shake confidence in Bitcoin&#39;s future.<br><br></div><div>I wasn&#3=
9;t thinking of a direct miner 51% attack.=C2=A0 It is enough to assume tha=
t a majority of the miners go with the highest bidder each time.<br><br></d=
iv><div>If (average fees) * (timeout) is less than the total reserves, then=
 it is worth it for a 3rd party to just bid for his theft fork.=C2=A0 Miner=
s don&#39;t have to be assumed to be coordinating, they just have to be ass=
umed to take the highest bid.<br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"auto"><span class=3D""></span><div dir=3D"auto">Again=
, I don&#39;t really think it is that different. One could interchange &quo=
t;recent txns&quot; (those which could be double-spent within 2-3 weeks) wi=
th &quot;sidechain deposit tnxs&quot;.</div></div></blockquote><div><br></d=
iv><div>It is not &quot;recent txns&quot;, it is recent txns that you (or y=
our group) have the key for.=C2=A0 No coordination is required to steal the=
 entire reserve from the sidechain.<br><br></div><div>Recent txns and money=
 on the sidechain have the property that they are riskier than money deep o=
n the main chain.=C2=A0 This is the inherent point about sidechains, so may=
be not that big a deal.=C2=A0 <br><br></div><div>My concern is that you cou=
ld have a situation where an attack is possible and only need to assume tha=
t the miners are indifferent.<br></div><div><br></div><div>If the first att=
acker who tries it fails (say after creating a fork that is 90% of the leng=
th required, so losing a lot of money), then it would discourage others.=C2=
=A0=C2=A0 If he succeeds, then it weakens sidechains as a concept and that =
creates the incentive for miners to see that he fails.<br><br></div><div>I =
wonder how the incentives work out.=C2=A0 If a group had 25% of the money o=
n the sidechain, they could try to outbid the attacker.<br><br></div><div>I=
n fact, since the attacker, by definition, creates an illegal fork, the eff=
ect is that he reduces the block rate for the side chain (possibly to zero,=
 if he wins every auction).=C2=A0 This means that there are more transactio=
ns per block, if there is space, or more fees per transaction, if the block=
s are full.=C2=A0 <br><br>In both cases, this pushes up the total fees per =
block, so he has to pay more per block, weakening his attack.=C2=A0 This is=
 similar to where transaction spam on Bitcoin is self-correcting by increas=
ing the fees required to keep the spam going.<br><br></div><div>Is there a =
description of the actual implementation you decided to go with, other than=
 the code?<br></div></div></div></div>

--001a113919b0682ff805502deef6--