path: root/81/75010fc48f04d4ff0fb085b38fb7351f4c8908

Return-Path: <tom@commerceblock.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8CB79C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Apr 2020 22:56:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by silver.osuosl.org (Postfix) with ESMTP id 7600026754
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Apr 2020 22:56:32 +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 YHz6svvLrPHt
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Apr 2020 22:56:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com
 [209.85.208.47])
 by silver.osuosl.org (Postfix) with ESMTPS id B1A7520354
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Apr 2020 22:56:30 +0000 (UTC)
Received: by mail-ed1-f47.google.com with SMTP id cw6so6662393edb.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 02 Apr 2020 15:56:30 -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;
 bh=keQMhfOCcXT5UvLSkbZGTS2KLWNDKlPxTWF35U1TUfk=;
 b=Din0QbTNvpmernYyhy+P7PvcOkrI78QIxpJ4HlAhDqPB+PwNJD2qA+z+6XQDsxF7MK
 f/3JNj5ZmYmHm6vwWpmcxK42H8ow6jjbJJDBC725xOdxRNw3Ua8WRgiccynVMkrka30Z
 R3De+ZndyDG5yYCvQvM+r4pRcusAv06TGBjk1S+V4Rli8ZxiMB3qGavV9O0/2U9U90r0
 nA3kMaOttoor2qaTml55rKl5tPerbPuaTD3r9w9rBs6SwOU4LvCqtmBhe4LRgduRYIaA
 2cIAlzJi/e1+LflzZzhJV+taxREhm0isn0NXBLN2DWMIVHS0MpfP8/N9ttT1voUg26f+
 yaFg==
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;
 bh=keQMhfOCcXT5UvLSkbZGTS2KLWNDKlPxTWF35U1TUfk=;
 b=VLKMji18ucAoUrAVjpVwuvGcpxaIyRb1P4Axmjddfws4o7OH8/rhnPn1tNXoeqBgM2
 2iQnLE2v9Gb/nq9XjZVrGvCt4KqZ8zga7SN8sOcmOdrC4RUnMA/L2w/h23p3eeeYyjNZ
 G24X6pe4/0puTsW2lXMztF9X6U7dhCKcYUGa872nSDdERc95nLTj+VOmekenjzn/DTpG
 CXI9S1qOH7yyeHiC6aIoh5/AXFS/iRFIrKKG4aTbSlBialmaTKDxvFGn2m89riAvZKLq
 Ogyh3qesmxF53Z0HIOmOTNuayOJIxG4M6t3h+Gq6WfUZrwpTT7cpQscVIIBKthjFOlzT
 +cgQ==
X-Gm-Message-State: AGi0PuZ7CiNFoC0GEypzGlILasvZK0r7PRYOWYmo9qNm9cLaCV8gCf4N
 2ydDmNafN+WY7cTnttqkq0E44ex8FYmSm5o8GR+vnG2zLw==
X-Google-Smtp-Source: APiQypJen0o7sOA3W1lPpDhqnMjvD4QnHGtHcb5WRPZlChOGzTfxWZ0pb0DmFbMw3XiZXFKlxUgGzZgiOouQ9yUp38U=
X-Received: by 2002:a50:d61c:: with SMTP id x28mr5110755edi.344.1585868188753; 
 Thu, 02 Apr 2020 15:56:28 -0700 (PDT)
MIME-Version: 1.0
References: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <20200331103508.asvxujkhtifj6n7i@ganymede>
 <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
In-Reply-To: <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Thu, 2 Apr 2020 23:56:17 +0100
Message-ID: <CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000d302b05a256b6ef"
X-Mailman-Approved-At: Fri, 03 Apr 2020 00:22:24 +0000
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, 02 Apr 2020 22:56:32 -0000

--0000000000000d302b05a256b6ef
Content-Type: text/plain; charset="UTF-8"

Thanks for all of the input and comments - I do now think that the
decrementing nSequence relative locktime backup system with kick-off
transaction is the way to go, including a fee penalty via CPFP to
disincentivise DoS, as suggested.
I have started a more detailed document specifying the proposed protocol in
more detail:
https://github.com/commerceblock/mercury/blob/master/statechains.md which
includes improvements to the transfer mechanism (and an explanation of how
this can be used to transfer/novate positions in DLCs). Always happy to get
more feedback or PRs.

Tom

On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com>
wrote:

> 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
>>
>

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

<div dir=3D"ltr">Thanks for all of the input and comments - I do now think =
that the decrementing nSequence relative locktime backup system with kick-o=
ff transaction is the way to go, including a fee penalty via CPFP to disinc=
entivise=C2=A0DoS, as suggested.=C2=A0<div>I have started a more detailed d=
ocument specifying the proposed protocol in more detail:=C2=A0<a href=3D"ht=
tps://github.com/commerceblock/mercury/blob/master/statechains.md">https://=
github.com/commerceblock/mercury/blob/master/statechains.md</a>=C2=A0which =
includes improvements to the transfer=C2=A0mechanism (and an explanation of=
 how this can be used to transfer/novate positions in DLCs). Always happy t=
o get more feedback or PRs.=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 12:41 PM Tom Trevethan &lt;<a href=3D"mailto:tom@commerceb=
lock.com">tom@commerceblock.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hi David,<div><br></div><=
div>Just for clarity, I left nChain over 2 years ago (having worked there s=
ince 2016). While there, I (along with other researchers) were given free r=
ein 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,=C2=A0pegs and threshold signatures). This=
 patent application came out of an idea I had to transfer ownership of UTXO=
s off-chain that has some similarities to the statechains proposal, which h=
as shown there is interest and demand for this type of system.=C2=A0</div><=
div><br></div><div>Although I think the existence of this application is so=
mething to be mindful of, there are several important things to note:</div>=
<div><br></div><div>1. Although there are similarities, the current ideas a=
re significantly different to those in the application.=C2=A0</div><div>2. =
The key transfer protocol as described in the application is not secure (fo=
r several reasons, including as discussed above, by Albert and Bob etc.) - =
and a different mechanism is required.=C2=A0</div><div>3. Decrementing time=
locks (as suggested in the application) are prior art (Decker-Wattenhofer 2=
015), and in any case any implementation will most likely use an &#39;inval=
idation tree&#39; relative locktime backup mechanism for open-ended UTXOs.=
=C2=A0</div><div>4. The patent application has not been granted (it was mad=
e in May 2017) and the international search report rejected it on the groun=
ds of prior art.=C2=A0</div><div><br></div><div>Tom</div></div><br><div cla=
ss=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 31, 20=
20 at 11:36 AM David A. Harding &lt;<a href=3D"mailto:dave@dtrt.org" target=
=3D"_blank">dave@dtrt.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trev=
ethan 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>
</blockquote></div>

--0000000000000d302b05a256b6ef--