From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 64CF8C07FF for ; Fri, 3 Apr 2020 16:37:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4CB9A88305 for ; Fri, 3 Apr 2020 16:37:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3IvDyCk9nTI for ; Fri, 3 Apr 2020 16:37:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by whitealder.osuosl.org (Postfix) with ESMTPS id 97F16882BB for ; Fri, 3 Apr 2020 16:37:28 +0000 (UTC) Received: by mail-io1-f50.google.com with SMTP id o127so8208506iof.0 for ; Fri, 03 Apr 2020 09:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suredbits-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=77rdOYMG4j0bxS2KbpPnyIbEeeMoph123jbvCDUl4Cs=; b=th1g0lkq1bP2wGfp/2QRDWxMM7d3Hh2+iko/FrdX6hpWC7i8BYNGMvCJRJo+WqzQaj rwFXdzGhnzfdeg8NJFLTcWkp43KsIXckDFQ6yM4hP5De6aLTsG4lcnSL1IoJnQaGLI47 RR7D4S64gkXmEQRxiCCYKprF87brSrfaNLAhKaH5sIEz0YFxOWpkfkFWPfZ+iw71QFJy BkdI1t4Orbn1RtoOXmlp7RrM4haGeTxUtwuXGyr7dtbcTJoN0uK9RC149Z3ZqzTjKjkD x7GHbN04CpjjzsbAWRZVSUsY0m4NkCShTzcWhVDx7LaCEPpLx6IUh0V9Y9sbDYmom0Jy XuEA== 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=77rdOYMG4j0bxS2KbpPnyIbEeeMoph123jbvCDUl4Cs=; b=a8rUmR15ABstusF2vLTFUclJ7cJMhsYpfHQbOBxfhxUQ74IKF2sbJ796V6hEgXWmvl hOzZrT6B4ExvfhNRPR+wbahkcTun4HPQuXURq0iwidCYq3t9k6mB3KsQocDRxVK1c8I4 9krCtCCSClcuQH77aSQjHzs2iW8UG73wTxfJnJbhtMZAdDaJfooW213fITsbeHZhXePo uPm2ECfy3JS3XDXQ5OK37AkUEYy4gf/YjoxhHheAVzFEQ/Ma0GEA9mIFurb657SMp920 51gjQJhxI/WKosN7uPdSMfM0tHxjkMANjNu8feea8CmGNJMAQyU2SjbUHkMnzzf4lqC2 k50A== X-Gm-Message-State: AGi0PuZKZk0TlTQcU+OD6oJQ+rDi+mHDxdODuN824TE6hmIZzW1GdHYI rRYaSlV7guPNJTqfsTkAFiLGFtsgL0kKXP1FCdfNkg94HgM= X-Google-Smtp-Source: APiQypK/KigjB0T8JhNv9xfrO0Gbs3YgwS88QPXONqwNYzF5dOCfZo3I+2Fmc9zOHchrkasjLXlIdXZSxgdAX495L48= X-Received: by 2002:a5e:de45:: with SMTP id e5mr8159147ioq.37.1585931847699; Fri, 03 Apr 2020 09:37:27 -0700 (PDT) MIME-Version: 1.0 References: <20200331103508.asvxujkhtifj6n7i@ganymede> In-Reply-To: From: Nadav Kohen Date: Fri, 3 Apr 2020 11:37:15 -0500 Message-ID: To: Tom Trevethan , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000006ba3f005a265887f" X-Mailman-Approved-At: Fri, 03 Apr 2020 16:40:26 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 16:37:30 -0000 --0000000000006ba3f005a265887f Content-Type: text/plain; charset="UTF-8" Hey all, So my main concern with the proposal as written is that the Statechain Entity (SE) can untraceably scam its users with the following attack: 1) Buy the utxo (have it transferred to a key it knows), this first step can be skipped if the utxo was created by the SE. 2) Transfer the UTXO to someone else, let it be for however long 3) When it wishes to steal the UTXO, the SE now knows its own shard s_n and it knows the full private key, x, from when it owned the UTXO (and had both shards), and so it can compute x/s_n = the current users shard. It can then sign for the current user, and forge a state transition to a key it owns before spending the UTXO on chain. The main problem here is that the user who had their funds stolen cannot prove to anyone that this has happened since the attack compromises their key. That said, I think this problem is easily fixed by adding a new user key to the protocol with which they must sign in order for the transfer to be considered valid on the state chain. This way, if the SE wishes to steal the funds (which they still can), at least it is traceable/provable that this SE is not trustworthy as there is no evidence of a valid transfer for the funds that have been stolen. Best, Nadav On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > 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 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 >>> >> _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000006ba3f005a265887f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey all,

So my main concern with the pr= oposal as written is that the Statechain Entity (SE) can untraceably=C2=A0s= cam its users with the following attack:

1) Buy the utxo = (have it transferred to a key it knows), this first step can be skipped if = the utxo was created by the SE.
2) Transfer the UTXO to someone e= lse, let it be for however long
3) When it wishes to steal the UT= XO, the SE now knows its own shard s_n and it=C2=A0 knows the full private = key, x, from when it owned the UTXO (and had both shards), and so it can co= mpute x/s_n =3D the current users shard. It can then sign for the current u= ser, and forge a state transition to a key it owns before spending the UTXO= on chain.

The main problem here is that the user = who had their funds stolen cannot prove to anyone that this has happened si= nce the attack compromises their key.
That said, I think this pro= blem is easily fixed by adding a new user key to the protocol with which th= ey must sign in order for the transfer to be considered valid on the state = chain. This way, if the SE wishes to steal the funds (which they still can)= , at least it is traceable/provable that this SE is not trustworthy as ther= e is no evidence of a valid transfer for the funds that have been stolen.

Best,
Nadav

On Thu, Apr 2, 2020 at 7= :22 PM Tom Trevethan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:=
Thanks for all of the input and comments - I do now think that the decrem= enting nSequence relative locktime backup system with kick-off transaction = is the way to go, including a fee penalty via CPFP to disincentivise=C2=A0D= oS, as suggested.=C2=A0
I have started a more detailed document specify= ing the proposed protocol in more detail:=C2=A0https= ://github.com/commerceblock/mercury/blob/master/statechains.md=C2=A0whi= ch includes improvements to the transfer=C2=A0mechanism (and an explanation= of how this can be used to transfer/novate positions in DLCs). Always happ= y to get more feedback or PRs.=C2=A0

Tom

On T= ue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com> wrote:
Hi Dav= id,

Just for clarity, I left nChain over 2 years ago (ha= ving 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 intere= sted in the scaling of Bitcoin off-chain, and this was one of several thing= s I spent time on (including things like sidechains,=C2=A0pegs and threshol= d signatures). This patent application came out of an idea I had to transfe= r ownership of UTXOs off-chain that has some similarities to the statechain= s proposal, which has shown there is interest and demand for this type of s= ystem.=C2=A0

Although I think the existence of thi= s application is something to be mindful of, there are several important th= ings to note:

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

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:1= 0PM +0000, Tom Trevethan via bitcoin-dev wrote:
> Hi all,
>
> We are starting to work on an implementation of the statechains concep= t (
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitco= in-transfer-1ae4845a4a39),
>
> [...]
> There are two main modifications we are looking at:
> [...]
>
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity S= E 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 ow= ner
> 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 "Secur= e
off-chain blockchain transactions"?[1]=C2=A0

=C2=A0 =C2=A0 [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<= br> > depositor keys or collusion with previous legitimate owners of funds,<= br> > the opportunities for a malicious attacker to compromise the exchange<= br> > platform are limited.

Thank you,

-Dave
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000006ba3f005a265887f--