path: root/d2/94f324e8c95180b87013aa3bf52dcb7f16fd3e

Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id EFA8D7F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Aug 2015 21:29:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f172.google.com (mail-io0-f172.google.com
	[209.85.223.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ACF2F16A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Aug 2015 21:29:51 +0000 (UTC)
Received: by iods203 with SMTP id s203so98194472iod.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Aug 2015 14:29:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=2UnQpbrO/G3obUCUOIe+kesetODdI9QQ7KgPoQwY8CE=;
	b=dn6IY+/TmeOdbt2ZpVegPbH7KRWzAn7HHsTZ9LWkZnlZSI9M75C3+MqAfoPRcJtCCO
	u9hOJpzvpCX4WB7Ks2ZWj0fMG2Ru9Z8TJUBkS8tWcJ4CzWI3zf83ViRqldoIPT17O5LG
	h0dvpiOZtdhV6vBQvxP8v5ocOjZ32pCLsb9+3ahAXkNJ4o8ze+zTfnYqYkXM9ODzX5bE
	h48T5NyGY6AsK0OjRLFRLBFV5O0LCayQTSar2P2ipEH7jQ9lO3iEIXYEiamAa5lS8hWB
	hlNHeTkVCJgEQW9M7cuYy4ebNe+6GaYjlLeVm+6FU4SM7dZNE+veZEo4pGhYuMMh7/rb
	O8SQ==
X-Gm-Message-State: ALoCoQka5O5WO4IkyHG0aNWM+0PCPTu4PTrdQ02ID5B5VgCz88Lt/+JNqts0TShmYK/HBOpO/r9N
X-Received: by 10.107.35.138 with SMTP id j132mr52314827ioj.159.1439587791150; 
	Fri, 14 Aug 2015 14:29:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.138.14 with HTTP; Fri, 14 Aug 2015 14:29:31 -0700 (PDT)
X-Originating-IP: [172.56.17.178]
In-Reply-To: <55CE3947.8060802@mattcorallo.com>
References: <CADJgMztgE_GkbrsP7zCEHNPA3P6T=aSFfhkcN-q=gVhWP0vKXg@mail.gmail.com>
	<20150813234213.GH2123@lightning.network>
	<CAOG=w-vJ3DQdXoVfdyXPQXWCvS=ByW-CgqY50OEZYfQbxR5bMg@mail.gmail.com>
	<55CE3947.8060802@mattcorallo.com>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Fri, 14 Aug 2015 14:29:31 -0700
Message-ID: <CAOG=w-tmtrkQX3TX2i0D+nUx6oz5_BsfT8VR0TrvDFq712u9Zg@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary=001a1140f4e6ea39a3051d4c26dd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for
 relative locktime
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Fri, 14 Aug 2015 21:29:53 -0000

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

With the assumed malleability-fix CHECKSIG2 version of lightning, watching
for and responding to bad behavior is fully outsourceable. You can
synchronize channel state (signed refund transactions) with a third party
that watches for replay of old transactions on the mainnet, and starts the
refund process if it observes them, paying the fees necessary to get on the
chain.

With the CLTV/CSV-only form of the hash time-lock contracts that Rusty has
developed, this is indeed something the users' wallets would have to be
online to observe happening and respond to. I presume that we are
eventually going to get a CHECKSIG2 with some kind of malleability-immune
signing scheme in the long term, and that we are not interested in
introducing new consensus behavior to cover that short stopgap.

> I'm not even sure if sufficient coordination is a sufficient solution.

A regrettable choice of words. In this case it is game theoretic
cooperation, not coordination. The users need only expect that each other
would react the same way, being willing to burn money as fees that would
otherwise be stolen. They don't actually have to communicate with each
other in order to cooperate.

You are correct though that hubs-with-hashpower complicate this situation.
Although a hub with hashpower also creates risk in the timestop scenario
too...

On Fri, Aug 14, 2015 at 11:53 AM, Matt Corallo <lf-lists@mattcorallo.com>
wrote:

>
>
> On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:
> > On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> >     I haven't tested the details of this, but is there another bit
> available
> >     for use in the future for the relative blockheight?
> >
> >     I strongly believe that Lightning needs mitigations for a systemic
> >     supervillan attack which attemps to flood the network with
> transactions,
> >     which can hypothetically be mitigated with something like a timestop
> >     bit (as originally suggested by gmaxwell).
> >
> >
> > This proposal includes no such provision.
> >
> > Since we talked about it, I spent considerable time thinking about the
> > supposed risk and proposed mitigations. I'm frankly not convinced that
> > it is a risk of high enough credibility to worry about, or if it is that
> > a protocol-level complication is worth doing.
> >
> > The scenario as I understand it is a hub turns evil and tries to cheat
> > every single one of its users out of their bonds. Normally a lightning
> > user is protected form such behavior because they have time to broadcast
> > their own transactions spending part or all of the balance as fees.
>
> My concern is how the hell do you automate this? Having a threat of
> "well, everyone could update their software to a new version which will
> destroy all coins right now" is kinda useless, and trying to come up
> with a reasonable set of metrics as to how much and when you move from
> just paying the fee to destroying coins is really hard, especially if
> you assume the attacker is a miner with, say, enough hashrate (maybe
> rented) to get one or three blocks in the next day (the timeout period).
>
> > Therefore because of the threat of mutually assured destruction, the
> > optimal outcome is to be an honest participant.
> >
> > But, the argument goes, the hub has many channels with many different
> > people closing at the same time. So if the hub tries to cheat all of
> > them at once by DoS'ing the network, it can do so and spend more in fees
> > than any one participant stands to lose. My issue with this is that
> > users don't act alone -- users can be assured that other users will
> > react, and all of them together have enough coins to burn to make the
> > attack unprofitable.
>
> Now users are coordinating quickly in an attack scenario?
>
> > The hub-cheats-many-users case really is the same
> > as the hub-cheats-one-user case if the users act out their role in
> > unison, which they don't have to coordinate to do.
> >
> > Other than that, even if you are still concerned about that  scenario,
> > I'm not sure timestop is the appropriate solution. A timestop is a
> > protocol-level complication that is not trivial to implement, indeed I'm
> > not even sure there is a way to implement it at all -- how do you
> > differentiate in consensus code a DoS attack from regular old blocks
> > filling up? And if you could, why add further complication to the
> > consensus protocol?
>
> Yea, implementation is really tricky here. I do not at all think we
> should be thinking about implementing this any time soon, and should
> assume Lightning will have to stand reasonably on its own without it
> first, and only if it gains a lot of traction will there be enough
> motivation for making such a change at the Bitcoin protocol level for
> Lightning.
>
> > A simpler solution to me seems to be outsourcing the response to an
> > attack to a third party
>
> Doesnt that defeat the purpose of Lightning?
>
> > or otherwise engineering ways for users to
> > respond-by-default even if their wallet is offline, or otherwise
> > assuring sufficient coordination in the event of a bad hub.
>
> I'm not even sure if sufficient coordination is a sufficient solution.
> If you assume a hub just shut down, and everyone is trying to flush to
> the chain, with a backlog of a few days worth of transactions (with
> timeouts of a day or so), and users are even paying huge fees (99% of
> what they'd get back), if the former-hub is a miner, it can claim that
> last 1% of many of the transactions that take longer than a day to confirm.
>

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

<div dir=3D"ltr"><div><div>With the assumed malleability-fix CHECKSIG2 vers=
ion of lightning, watching for and responding to bad behavior is fully outs=
ourceable. You can synchronize channel state (signed refund transactions) w=
ith a third party that watches for replay of old transactions on the mainne=
t, and starts the refund process if it observes them, paying the fees neces=
sary to get on the chain.<br><br>With the CLTV/CSV-only form of the hash ti=
me-lock contracts that Rusty has developed, this is indeed something the us=
ers&#39; wallets would have to be online to observe happening and respond t=
o. I presume that we are eventually going to get a CHECKSIG2 with some kind=
 of malleability-immune signing scheme in the long term, and that we are no=
t interested in introducing new consensus behavior to cover that short stop=
gap.<br><br>&gt; I&#39;m not even sure if sufficient coordination is a suff=
icient solution.<br><br></div>A regrettable choice of words. In this case i=
t is game theoretic cooperation, not coordination. The users need only expe=
ct that each other would react the same way, being willing to burn money as=
 fees that would otherwise be stolen. They don&#39;t actually have to commu=
nicate with each other in order to cooperate.<br><br></div>You are correct =
though that hubs-with-hashpower complicate this situation. Although a hub w=
ith hashpower also creates risk in the timestop scenario too...<br></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Aug 14, 201=
5 at 11:53 AM, Matt Corallo <span dir=3D"ltr">&lt;<a href=3D"mailto:lf-list=
s@mattcorallo.com" target=3D"_blank">lf-lists@mattcorallo.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
<br>
On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:<br>
&gt; On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
</span><span class=3D"">&gt; &lt;mailto:<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;&gt; wro=
te:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0I haven&#39;t tested the details of this, but is th=
ere another bit available<br>
&gt;=C2=A0 =C2=A0 =C2=A0for use in the future for the relative blockheight?=
<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0I strongly believe that Lightning needs mitigations=
 for a systemic<br>
&gt;=C2=A0 =C2=A0 =C2=A0supervillan attack which attemps to flood the netwo=
rk with transactions,<br>
&gt;=C2=A0 =C2=A0 =C2=A0which can hypothetically be mitigated with somethin=
g like a timestop<br>
&gt;=C2=A0 =C2=A0 =C2=A0bit (as originally suggested by gmaxwell).<br>
&gt;<br>
&gt;<br>
&gt; This proposal includes no such provision.<br>
&gt;<br>
&gt; Since we talked about it, I spent considerable time thinking about the=
<br>
&gt; supposed risk and proposed mitigations. I&#39;m frankly not convinced =
that<br>
&gt; it is a risk of high enough credibility to worry about, or if it is th=
at<br>
&gt; a protocol-level complication is worth doing.<br>
&gt;<br>
&gt; The scenario as I understand it is a hub turns evil and tries to cheat=
<br>
&gt; every single one of its users out of their bonds. Normally a lightning=
<br>
&gt; user is protected form such behavior because they have time to broadca=
st<br>
&gt; their own transactions spending part or all of the balance as fees.<br=
>
<br>
</span>My concern is how the hell do you automate this? Having a threat of<=
br>
&quot;well, everyone could update their software to a new version which wil=
l<br>
destroy all coins right now&quot; is kinda useless, and trying to come up<b=
r>
with a reasonable set of metrics as to how much and when you move from<br>
just paying the fee to destroying coins is really hard, especially if<br>
you assume the attacker is a miner with, say, enough hashrate (maybe<br>
rented) to get one or three blocks in the next day (the timeout period).<br=
>
<span class=3D""><br>
&gt; Therefore because of the threat of mutually assured destruction, the<b=
r>
&gt; optimal outcome is to be an honest participant.<br>
&gt;<br>
&gt; But, the argument goes, the hub has many channels with many different<=
br>
&gt; people closing at the same time. So if the hub tries to cheat all of<b=
r>
&gt; them at once by DoS&#39;ing the network, it can do so and spend more i=
n fees<br>
&gt; than any one participant stands to lose. My issue with this is that<br=
>
&gt; users don&#39;t act alone -- users can be assured that other users wil=
l<br>
&gt; react, and all of them together have enough coins to burn to make the<=
br>
&gt; attack unprofitable.<br>
<br>
</span>Now users are coordinating quickly in an attack scenario?<br>
<span class=3D""><br>
&gt; The hub-cheats-many-users case really is the same<br>
&gt; as the hub-cheats-one-user case if the users act out their role in<br>
&gt; unison, which they don&#39;t have to coordinate to do.<br>
&gt;<br>
&gt; Other than that, even if you are still concerned about that=C2=A0 scen=
ario,<br>
&gt; I&#39;m not sure timestop is the appropriate solution. A timestop is a=
<br>
&gt; protocol-level complication that is not trivial to implement, indeed I=
&#39;m<br>
&gt; not even sure there is a way to implement it at all -- how do you<br>
&gt; differentiate in consensus code a DoS attack from regular old blocks<b=
r>
&gt; filling up? And if you could, why add further complication to the<br>
&gt; consensus protocol?<br>
<br>
</span>Yea, implementation is really tricky here. I do not at all think we<=
br>
should be thinking about implementing this any time soon, and should<br>
assume Lightning will have to stand reasonably on its own without it<br>
first, and only if it gains a lot of traction will there be enough<br>
motivation for making such a change at the Bitcoin protocol level for<br>
Lightning.<br>
<span class=3D""><br>
&gt; A simpler solution to me seems to be outsourcing the response to an<br=
>
&gt; attack to a third party<br>
<br>
</span>Doesnt that defeat the purpose of Lightning?<br>
<span class=3D""><br>
&gt; or otherwise engineering ways for users to<br>
&gt; respond-by-default even if their wallet is offline, or otherwise<br>
&gt; assuring sufficient coordination in the event of a bad hub.<br>
<br>
</span>I&#39;m not even sure if sufficient coordination is a sufficient sol=
ution.<br>
If you assume a hub just shut down, and everyone is trying to flush to<br>
the chain, with a backlog of a few days worth of transactions (with<br>
timeouts of a day or so), and users are even paying huge fees (99% of<br>
what they&#39;d get back), if the former-hub is a miner, it can claim that<=
br>
last 1% of many of the transactions that take longer than a day to confirm.=
<br>
</blockquote></div><br></div>

--001a1140f4e6ea39a3051d4c26dd--