path: root/62/2bf2ea3da0268a1b1de6edd916d3c2dd3addfb

Return-Path: <rsomsen@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 78BA7C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Mar 2020 18:53:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 6354920444
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Mar 2020 18:53:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id fY8MxouOSjA3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Mar 2020 18:53:26 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f193.google.com (mail-oi1-f193.google.com
 [209.85.167.193])
 by silver.osuosl.org (Postfix) with ESMTPS id 2C79420413
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Mar 2020 18:53:26 +0000 (UTC)
Received: by mail-oi1-f193.google.com with SMTP id y71so6494141oia.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 26 Mar 2020 11:53:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=Zt9y/fSkxdaG5CdxlpEwWcbOmTN69QWBqoN4IctaFjw=;
 b=Bs7UrE8X33OB409MjGVobu14d6wd3c/Ehw4zMas5bSIP7RbBKrHyb4E+EaaD5aujDL
 mE5Kyak2uscMytbA9oH1mzhrf5hfzlCibgvpTIa5zu1quBZH5KpsQSev91vYGT1Xw5p4
 PEBsVU7D9SeXs2lkrzhKDyM9PZGiOh1WXxDKWF6KHcF4ypLkyeVpL4R6aLPvt9h0XvvB
 jufAgODLkYc/EivsXQndfRITKtUuAuooYmzuhs8LqzztAVpvIWLz0Myo4SkN4wK7I5+g
 xLIT/T6DZUgIEndtjtIoDVp8y75j3ogiQG5/Yi1FuPO0XSeFk1GXrJwDm0S4r2r8v95d
 +zRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=Zt9y/fSkxdaG5CdxlpEwWcbOmTN69QWBqoN4IctaFjw=;
 b=ulzfSgtObnf6xyz+AD0e9tk9orIAvjvwbzBhUfEjfhg92Gh4YSDkitiGYJePnMLFlo
 N7XdF1vm0E9X3lD/Ovz7gXR9WAmIkgDAmi36juFA1cZpEDZYwgNtxT2qhoRUfxUgfBzt
 V4sb6SMc9QHT18GNwv4yhcf1Vr9sCyWxq3rwsKZ09LkcK4MirSviUwx9UYrKvh3swR9J
 R0KITEvqWZ/VJMuX1ln7DHXp8YygM2kyN6Inob77nW0PZ62kdiAxke3NH0S9W+fADrm2
 ftF06x3Rtgoam15dmLUSGrAQ1fNKXz9+iDsJ5jqAY3qg6NoOTpyFPPfgtLecx0kfiMSz
 j2wQ==
X-Gm-Message-State: ANhLgQ22v5fe3Cfv1d94jBTnRsgx/4jPcEZm5dxw6hTEG9mMKCaewvHN
 NAsfuQRweVLdUfOBEGIW590mYZshrCzecFxdsrk=
X-Google-Smtp-Source: ADFU+vs2ZgohTTTpVDKC2f6HUFtwj3SQaPSjSmMUxmvWJEdxAzjWAE/8BxAcU277PeH2xbzGT4m7aGtStEcLFOY8DCA=
X-Received: by 2002:aca:adc7:: with SMTP id w190mr1304045oie.42.1585248805279; 
 Thu, 26 Mar 2020 11:53:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <79753214-9d5e-40c7-97ac-1d4e9ea3c64e@www.fastmail.com>
 <CAPv7TjZ45VD_5sGSFiQxmt981uDodq28mHOW=2LYLofXams43w@mail.gmail.com>
 <87369v6nw3.fsf@gmail.com>
 <CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com>
In-Reply-To: <CAB3F3Dt0z5bDMpzRGGJxJV8KpCk_4XGF23MGmYVkLppRbG7Wnw@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Thu, 26 Mar 2020 19:53:13 +0100
Message-ID: <CAPv7TjbAfLHFZgSvCTSG2rS6oZinyd6VWrT3U8Y++PL=Jm6igA@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000eb5c2d05a1c67f9d"
X-Mailman-Approved-At: Thu, 26 Mar 2020 18:53:58 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 tom@commerceblock.com, Greg Sanders <gsanders87@gmail.com>
Subject: Re: [bitcoin-dev] Statechain implementations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Thu, 26 Mar 2020 18:53:28 -0000

--000000000000eb5c2d05a1c67f9d
Content-Type: text/plain; charset="UTF-8"

Hey Christian,

Thanks for chiming in :)

>It might be worth adopting the late fee binding we have in eltoo

That is where my thinking originally went as well, but then I remembered
that this alters the txid, causing the settlement tx to become invalid.
What I am suggesting should be functionally the same (albeit less
space-efficient): a secondary output that can be spent by anyone, which can
be used to fee bump the kickoff tx with CPFP. I believe this same idea was
considered for Lightning as well at some point. Do you happen to recall if
there was some kind of non-standardness issue with it?

>Wouldn't that result in a changing pubkey at each update, and thus require
an onchain move to be committed?

I have yet to take a closer look at the math, but my understanding is that
the same key (x) gets redistributed. First x = s1 + o1 and after the
transfer x = s2 + o2 (not the actual math, but it demonstrates how the
transitory key can change from o1 to o2). Assuming s1 is then thrown away
(trust assumption), o1 becomes harmless information.

Cheers,
Ruben

On Thu, Mar 26, 2020 at 6:17 PM Greg Sanders <gsanders87@gmail.com> wrote:

> > Wouldn't that result in a changing pubkey at each update, and thus
> require an onchain move to be committed?
>
> Suggestion was in line with original proposal where no keys are changing
> ever, just not presupposing existence of MuSig.
>
> On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Ruben Somsen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
>> writes:
>> > Regarding modification 1, I agree with ZmnSCPxj that
>> > Decker-Wattenhofer is your next best option, given that eltoo is not
>> > yet available. But if you are going to use a kickoff transaction, keep
>> > in mind that every previous owner will have a copy of it. Because of
>> > this, you can't include a fee, and will instead need to have a second
>> > output for CPFP. This way a previous owner will at least have to pay
>> > the fee if they want to publish it. Note that it's still an
>> > improvement, because even if the kickoff transaction gets posted, it
>> > basically becomes no different than what it would have been, had you
>> > not used a kickoff transaction at all.
>>
>> It might be worth adopting the late fee binding we have in eltoo by
>> having the kickoff transaction input spending the funding tx signed with
>> sighash_single. This works because we only have 1 input and 1 output
>> that we really care about, and can allow others to attach fees at
>> will. That'd at least remove the need to guess the feerate days or
>> months in advance and thus having to overestimate.
>>
>> > Regarding modification 2, I like it a lot conceptually. It hadn't
>> > occurred to me before, and it's a clear security improvement. The only
>> > question is something Greg Sanders mentioned: whether it's enough to
>> > justify the added complexity of using 2P ECDSA. The alternative would
>> > be to simply use a regular 2-of-2 multisig (until Schnorr arrives,
>> > possibly).
>>
>> Wouldn't that result in a changing pubkey at each update, and thus
>> require an onchain move to be committed?
>>
>> > I'm looking forward to seeing statechains become a reality.
>>
>> That'd indeed be great :-)
>>
>> Cheers,
>> Christian
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--000000000000eb5c2d05a1c67f9d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hey Christian,</div><div><br></div><div>Thanks for ch=
iming in :)</div><div><br></div>&gt;It might be worth adopting the late fee=
 binding we have in eltoo<br><div><br></div><div>That is where my thinking =
originally went as well, but then I remembered that this alters the txid, c=
ausing the settlement tx to become invalid. What I am suggesting should be =
functionally the same (albeit less space-efficient): a secondary output tha=
t can be spent by anyone, which can be used to fee bump the kickoff tx with=
 CPFP. I believe this same idea was considered for Lightning as well at som=
e point. Do you happen to recall if there was some kind of non-standardness=
 issue with it?</div><div><br></div><div>&gt;Wouldn&#39;t that result in a =
changing pubkey at each update, and thus require an onchain move to be comm=
itted?<br></div><div><br></div><div>I have yet to take a closer look at the=
 math, but my understanding is that the same key (x) gets redistributed. Fi=
rst x =3D s1=C2=A0+ o1 and after the transfer x =3D s2=C2=A0+ o2 (not the a=
ctual math, but it demonstrates how the transitory key can change from o1 t=
o o2). Assuming s1 is then thrown away (trust assumption), o1 becomes harml=
ess information.</div><div><br></div><div>Cheers,</div><div>Ruben</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, Mar 26, 2020 at 6:17 PM Greg Sanders &lt;<a href=3D"mailto:gsanders87@g=
mail.com">gsanders87@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">&gt; Wouldn&#39;t that resul=
t in a changing pubkey at each update, and thus<br>require an onchain move =
to be committed?<div><br></div><div>Suggestion was in line with original pr=
oposal where no keys are changing ever, just not presupposing existence of =
MuSig.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"=
gmail_attr">On Thu, Mar 26, 2020 at 1:15 PM Christian Decker via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Ruben Somsen via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
writes:<br>
&gt; Regarding modification 1, I agree with ZmnSCPxj that<br>
&gt; Decker-Wattenhofer is your next best option, given that eltoo is not<b=
r>
&gt; yet available. But if you are going to use a kickoff transaction, keep=
<br>
&gt; in mind that every previous owner will have a copy of it. Because of<b=
r>
&gt; this, you can&#39;t include a fee, and will instead need to have a sec=
ond<br>
&gt; output for CPFP. This way a previous owner will at least have to pay<b=
r>
&gt; the fee if they want to publish it. Note that it&#39;s still an<br>
&gt; improvement, because even if the kickoff transaction gets posted, it<b=
r>
&gt; basically becomes no different than what it would have been, had you<b=
r>
&gt; not used a kickoff transaction at all.<br>
<br>
It might be worth adopting the late fee binding we have in eltoo by<br>
having the kickoff transaction input spending the funding tx signed with<br=
>
sighash_single. This works because we only have 1 input and 1 output<br>
that we really care about, and can allow others to attach fees at<br>
will. That&#39;d at least remove the need to guess the feerate days or<br>
months in advance and thus having to overestimate.=C2=A0 <br>
<br>
&gt; Regarding modification 2, I like it a lot conceptually. It hadn&#39;t<=
br>
&gt; occurred to me before, and it&#39;s a clear security improvement. The =
only<br>
&gt; question is something Greg Sanders mentioned: whether it&#39;s enough =
to<br>
&gt; justify the added complexity of using 2P ECDSA. The alternative would<=
br>
&gt; be to simply use a regular 2-of-2 multisig (until Schnorr arrives,<br>
&gt; possibly).<br>
<br>
Wouldn&#39;t that result in a changing pubkey at each update, and thus<br>
require an onchain move to be committed?<br>
<br>
&gt; I&#39;m looking forward to seeing statechains become a reality.<br>
<br>
That&#39;d indeed be great :-)<br>
<br>
Cheers,<br>
Christian<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000eb5c2d05a1c67f9d--