path: root/9e/627bdb7ce02a2d1457210d12c3a0fec75aca8c

Return-Path: <tom@commerceblock.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2A259C1AE8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Mar 2020 11:48:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 252FF86AB3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Mar 2020 11:48:39 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wsmzL_ax-Xb0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Mar 2020 11:48:38 +0000 (UTC)
X-Greylist: delayed 00:06:38 by SQLgrey-1.7.6
Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com
 [209.85.208.173])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id E54F386AA4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Mar 2020 11:48:37 +0000 (UTC)
Received: by mail-lj1-f173.google.com with SMTP id r7so13949652ljg.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 31 Mar 2020 04:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=commerceblock-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=YAdtR8PXTJGTCR/j43wEsr7S3tqw1YyBTu3BQ1xXq00=;
 b=Ah/Eh+sivqqKgMm9tBmzepDH1bScJ4RJXUl1T1soqUgB+v9xkV0mQUoebLNVhdGHLc
 o743R0QMcipVNCQjJWPm3tWvIsKExq+rXwvrcPdcAmxsmhYLqmh7lQqT+GEy9I73fppM
 rO2tNk2FZZbAQtbFvqQ85okDt32ws9hxi61zb8jsE86zQ6I/y1W4KZmtStPu+GxC9fey
 78s8pyzN1jKsTxXh9Sc/hzwp3FQsWj87xmeVqBt5Z6vrbDge9OK3POkuOETZLKB6QIlr
 p5BsNWZUVb3X0xt1ubqtwnG7rFMZhRyp/I7ZKIsajuNcIoSOyznJKv0B3d8+kFlSxMYw
 Yx2A==
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=YAdtR8PXTJGTCR/j43wEsr7S3tqw1YyBTu3BQ1xXq00=;
 b=Pp7rh7kJRS0OscOWXd6nqOYVup9iXP9g69HSc41qsLJSVWhMQv6bEMd5BzICso3gke
 uR6vVOWOwyRvtUAsOW76QVp7uJW9VjYYT7XoVPkm5TXwiC4Pf56oRmtsWxENV7eChfWP
 DTZjLH3Idt3xUsg+/xX2lSMy4Iadc2yn2n9nS6JXbNWiQh+OblSs5NWd8pZ9YJf5+a+f
 ttkUrgi9VWlZgKieq7FggmDa4uKtT0GzBcRuRABnIlzgG/5c7nLDXg2Pi7qtYAwa+z3X
 bilUJC8SCOdXtI80OzSn0u6lSYsRl51GhirAamHwPB5LBPHx5tjRIVl6AYqmDALaI3XR
 NFnw==
X-Gm-Message-State: AGi0PuZCMkilVKUnzkNO1k3kBtjtynz3OH/3aaC9dJJEocIEgFLRYc1N
 US9r1dbjHa/y5roedJ7a0lzKn4UOLjl1T0z6HynR3PKLgA==
X-Google-Smtp-Source: ADFU+vusZwbY3kOViwGNSbH/t4IA0OTVYGVtfwWMWs1NR7/p3HusYR0j/ynFIwhEgBg7Y+IIJFUUiXiJSuvVfjcE4hM=
X-Received: by 2002:a17:906:7383:: with SMTP id
 f3mr14589312ejl.197.1585654917697; 
 Tue, 31 Mar 2020 04:41:57 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <20200331103508.asvxujkhtifj6n7i@ganymede>
In-Reply-To: <20200331103508.asvxujkhtifj6n7i@ganymede>
From: Tom Trevethan <tom@commerceblock.com>
Date: Tue, 31 Mar 2020 12:41:46 +0100
Message-ID: <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>
Content-Type: multipart/alternative; boundary="0000000000001b27f305a2250e15"
X-Mailman-Approved-At: Tue, 31 Mar 2020 11:52:20 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 31 Mar 2020 11:48:39 -0000

--0000000000001b27f305a2250e15
Content-Type: text/plain; charset="UTF-8"

Hi David,

Just for clarity, I left nChain over 2 years ago (having worked there since
2016). While there, I (along with other researchers) were given free rein
to work on any ideas we wanted to. I had been interested in the scaling of
Bitcoin off-chain, and this was one of several things I spent time on
(including things like sidechains, pegs and threshold signatures). This
patent application came out of an idea I had to transfer ownership of UTXOs
off-chain that has some similarities to the statechains proposal, which has
shown there is interest and demand for this type of system.

Although I think the existence of this application is something to be
mindful of, there are several important things to note:

1. Although there are similarities, the current ideas are significantly
different to those in the application.
2. The key transfer protocol as described in the application is not secure
(for several reasons, including as discussed above, by Albert and Bob etc.)
- and a different mechanism is required.
3. Decrementing timelocks (as suggested in the application) are prior art
(Decker-Wattenhofer 2015), and in any case any implementation will most
likely use an 'invalidation tree' relative locktime backup mechanism for
open-ended UTXOs.
4. The patent application has not been granted (it was made in May 2017)
and the international search report rejected it on the grounds of prior
art.

Tom

On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <dave@dtrt.org> wrote:

> On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trevethan via bitcoin-dev
> wrote:
> > Hi all,
> >
> > We are starting to work on an implementation of the statechains concept (
> >
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
> ),
> >
> > [...]
> > There are two main modifications we are looking at:
> > [...]
> >
> > 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE
> key
> > and transitory key) with a single P2(W)PKH output where the public key
> > shared between the SE and the current owner. The SE and the current owner
> > can then sign with a 2-of-2 ECDSA MPC.
>
> Dr. Trevethan,
>
> Would you be able to explain how your proposal to use statechains with
> 2P-ECDSA relates to your patent assigned to nChain Holdings for "Secure
> off-chain blockchain transactions"?[1]
>
>     [1] https://patents.google.com/patent/US20200074464A1
>
> Here are some excerpts from the application that caught my attention in
> the context of statechains in general and your proposal to this list in
> particular:
>
> > an exchange platform that is trusted to implement and operate the
> > transaction protocol, without requiring an on-chain transaction. The
> > off-chain transactions enable one computer system to generate multiple
> > transactions that are recordable to a blockchain in different
> > circumstances
> >
> > [...]
> >
> > at least some of the off-chain transactions are valid for recording on
> > the blockchain even in the event of a catastrophic failure of the
> > exchange (e.g., exchange going permanently off-line or loosing key
> > shares).
> >
> > [...]
> >
> > there may be provided a computer readable storage medium including a
> > two-party elliptic curve digital signature algorithm (two-party ECDSA)
> > script comprising computer executable instructions which, when
> > executed, configure a processor to perform functions of a two-party
> > elliptic curve digital signature algorithm described herein.
> >
> > [...]
> >
> > In this instance the malicious actor would then also have to collude
> > with a previous owner of the funds to recreate the full key. Because
> > an attack requires either the simultaneous theft of both exchange and
> > depositor keys or collusion with previous legitimate owners of funds,
> > the opportunities for a malicious attacker to compromise the exchange
> > platform are limited.
>
> Thank you,
>
> -Dave
>

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

<div dir=3D"ltr">Hi David,<div><br></div><div>Just for clarity, I left nCha=
in over 2 years ago (having worked there since 2016). While there, I (along=
 with other researchers) were given free rein to work on any ideas we wante=
d to. I had been interested in the scaling of Bitcoin off-chain, and this w=
as one of several things I spent time on (including things like sidechains,=
=C2=A0pegs and threshold signatures). This patent application came out of a=
n idea I had to transfer ownership of UTXOs off-chain that has some similar=
ities to the statechains proposal, which has shown there is interest and de=
mand for this type of system.=C2=A0</div><div><br></div><div>Although I thi=
nk the existence of this application is something to be mindful of, there a=
re several important things to note:</div><div><br></div><div>1. Although t=
here are similarities, the current ideas are significantly different to tho=
se in the application.=C2=A0</div><div>2. The key transfer protocol as desc=
ribed in the application is not secure (for several reasons, including as d=
iscussed above, by Albert and Bob etc.) - and a different mechanism is requ=
ired.=C2=A0</div><div>3. Decrementing timelocks (as suggested in the applic=
ation) are prior art (Decker-Wattenhofer 2015), and in any case any impleme=
ntation will most likely use an &#39;invalidation tree&#39; relative lockti=
me backup mechanism for open-ended UTXOs.=C2=A0</div><div>4. The patent app=
lication has not been granted (it was made in May 2017) and the internation=
al search report rejected it on the grounds of prior art.=C2=A0</div><div><=
br></div><div>Tom</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, Mar 31, 2020 at 11:36 AM David A. Harding &l=
t;<a href=3D"mailto:dave@dtrt.org">dave@dtrt.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 25, 2020 at 01:=
52:10PM +0000, Tom Trevethan via bitcoin-dev wrote:<br>
&gt; Hi all,<br>
&gt; <br>
&gt; We are starting to work on an implementation of the statechains concep=
t (<br>
&gt; <a href=3D"https://medium.com/@RubenSomsen/statechains-non-custodial-o=
ff-chain-bitcoin-transfer-1ae4845a4a39" rel=3D"noreferrer" target=3D"_blank=
">https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitco=
in-transfer-1ae4845a4a39</a>),<br>
&gt;<br>
&gt; [...]<br>
&gt; There are two main modifications we are looking at:<br>
&gt; [...]<br>
&gt; <br>
&gt; 2. Replacing the 2-of-2 multisig output (paying to statechain entity S=
E key<br>
&gt; and transitory key) with a single P2(W)PKH output where the public key=
<br>
&gt; shared between the SE and the current owner. The SE and the current ow=
ner<br>
&gt; can then sign with a 2-of-2 ECDSA MPC. <br>
<br>
Dr. Trevethan,<br>
<br>
Would you be able to explain how your proposal to use statechains with<br>
2P-ECDSA relates to your patent assigned to nChain Holdings for &quot;Secur=
e<br>
off-chain blockchain transactions&quot;?[1]=C2=A0 <br>
<br>
=C2=A0 =C2=A0 [1] <a href=3D"https://patents.google.com/patent/US2020007446=
4A1" rel=3D"noreferrer" target=3D"_blank">https://patents.google.com/patent=
/US20200074464A1</a><br>
<br>
Here are some excerpts from the application that caught my attention in<br>
the context of statechains in general and your proposal to this list in<br>
particular:<br>
<br>
&gt; an exchange platform that is trusted to implement and operate the<br>
&gt; transaction protocol, without requiring an on-chain transaction. The<b=
r>
&gt; off-chain transactions enable one computer system to generate multiple=
<br>
&gt; transactions that are recordable to a blockchain in different<br>
&gt; circumstances<br>
&gt;<br>
&gt; [...]<br>
&gt;<br>
&gt; at least some of the off-chain transactions are valid for recording on=
<br>
&gt; the blockchain even in the event of a catastrophic failure of the<br>
&gt; exchange (e.g., exchange going permanently off-line or loosing key<br>
&gt; shares).<br>
&gt;<br>
&gt; [...]<br>
&gt;<br>
&gt; there may be provided a computer readable storage medium including a<b=
r>
&gt; two-party elliptic curve digital signature algorithm (two-party ECDSA)=
<br>
&gt; script comprising computer executable instructions which, when<br>
&gt; executed, configure a processor to perform functions of a two-party<br=
>
&gt; elliptic curve digital signature algorithm described herein.<br>
&gt;<br>
&gt; [...]<br>
&gt;<br>
&gt; In this instance the malicious actor would then also have to collude<b=
r>
&gt; with a previous owner of the funds to recreate the full key. Because<b=
r>
&gt; an attack requires either the simultaneous theft of both exchange and<=
br>
&gt; depositor keys or collusion with previous legitimate owners of funds,<=
br>
&gt; the opportunities for a malicious attacker to compromise the exchange<=
br>
&gt; platform are limited.<br>
<br>
Thank you,<br>
<br>
-Dave<br>
</blockquote></div>

--0000000000001b27f305a2250e15--