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 559C8C07FF for ; Thu, 7 May 2020 15:03:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 43F2E8863D for ; Thu, 7 May 2020 15:03:22 +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 k5QKkIayjPHs for ; Thu, 7 May 2020 15:03:19 +0000 (UTC) X-Greylist: delayed 00:08:12 by SQLgrey-1.7.6 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by whitealder.osuosl.org (Postfix) with ESMTPS id D4C5A8849B for ; Thu, 7 May 2020 15:03:18 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id pg17so4836682ejb.9 for ; Thu, 07 May 2020 08:03:18 -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=oaKQWMyys/OK98hUKoGd6YdPwVFK+SDIJ/0SnQSRYsY=; b=hXeiMPYzHDGKe8vmTWecl2b9+pozuIQoxTNRKqPFEIeNAXgFcJgvooMhyLNobRtUBI TYOUw38PpmXkygZ6NaFD57jWXmxClnU8C0KrforlpYSYpSV7W9efvNrcdFIj2L6lru1Y ukYrHWeDdGh7CT4P8WA85mOKheaon5YeYtVC0fPYZGDHJjAHIk1rTuZmQixytOxWam0R wBFYUsIpcJ03pJTSOyxqRtCXzYA+fuylWwh9JML6Xc7mG3wupDtrGJg0d1CNf3LHS41g jFGRevUcZ3KC/jRsNv+eb9rWvLGXDfzg5xLb8VSa1oaVbHU2jb/RjFsJ2I9K1lfgTzTU r1zA== 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=oaKQWMyys/OK98hUKoGd6YdPwVFK+SDIJ/0SnQSRYsY=; b=O/7s/v2L1QPlRvUyAaXwrocEQRo+BF1UBfI1+5ep/pmdFFrJ3AcbGs/8Qeq52LhNvW aWnEYyugloJaklRq5WoNopbosdbEDe8+C5jj5QCLQK2l+89u3B/g8nLqVwVHLvYEAZyD C/BiN/dKM77Q7XAPjkYaK7TSoKnGGJPEN/5ZOzW1vtMRTTD2/d4HGkrxJIPE6B5JfxNY PQsdonCWLAuohj2ZTv9gHe1XWED7W2Y22pKg9ASbsq0wL40F+XtEDJsfw2o2/7H84GeN vuAIHCEqhnwazxYq0taZePNEXHO6e7JtijWNPS4DhC5G7p57k9fjiJAFdDjQROqUBOJ2 4h/A== X-Gm-Message-State: AGi0PuYecRrXYYlVn46BB62p0xH39ga56SXmi4416KCwL79CRCSLadOk +YJUQYmStQ45Dqr8p5MmjGkY+A5HnGg6xSvgNip8c7OTpQ== X-Google-Smtp-Source: APiQypJT2kt9/2IkYFfvN4pAaR5AycXc4xZ2LXELlf14qnPK+uJpzKs0deS7jxYCGKZQa/IaLx75MBerdI63R8NxO98= X-Received: by 2002:a17:906:5608:: with SMTP id f8mr12874541ejq.190.1588863304509; Thu, 07 May 2020 07:55:04 -0700 (PDT) MIME-Version: 1.0 References: <20200331103508.asvxujkhtifj6n7i@ganymede> <20200405141717.GN28113@mcelrath.org> In-Reply-To: From: Tom Trevethan Date: Thu, 7 May 2020 15:54:53 +0100 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000dcbff105a510107c" X-Mailman-Approved-At: Thu, 07 May 2020 15:08:01 +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: Thu, 07 May 2020 15:03:22 -0000 --000000000000dcbff105a510107c Content-Type: text/plain; charset="UTF-8" Hi, An quick update on progress with our statechain implementation which we are pressing ahead with - we have started work on a version in Rust ( https://github.com/commerceblock/mercury) that is based on the 2P ECDSA gotham-city wallet from KZen (https://github.com/KZen-networks/gotham-city), and using their implementation of Lindel's 2P ECDSA protocol, which is very fast (we can always swap to a different protocol later). Also, we are planning on using a sparse Merkle tree attested to a Mainstay slot ( mainstay.xyz) for the proof-of-publication/proof-of-ownership - using the protocol described here: https://github.com/commerceblock/mercury/blob/master/doc/statechains.md and https://github.com/thyeem/monotree. Any comments on these choices or on anything else are highly appreciated. Tom On Sun, Apr 5, 2020 at 10:25 PM Tom Trevethan wrote: > Hi Bob and Nadav, > > There seems to be no way to prevent a malicious SE from stealing an > output from the current owner by either colluding with (or being) a > previous owner. But with a proof-of-publication (i.e. the statechain) it is > possible for the current owner to have a proof that the SE has stolen from > them. It seems to me that the statechain itself provides two functions: 1. > Proof that an output has only a single owner at any time (preventing the SE > from double-spending) and 2. a way for the current owner to prove their > ownership, and require their permission to change ownership. 1. can just be > a publication by the SE, but 2. requires that the output is transferred to > a public key of the owner, and only via a signature of the previous owner > (in this way the SE cannot re-assign ownership unilaterally). Therefore I > think Nadav is right, and this needs to be a key that the SE can never know > (even if they are malicious), but which can be used to prove ownership, and > in turn prove fraud on the part of the SE. > > I don't think that this should be too much of an issue: any wallet will > have to use new keys for each output and transfer anyway. The statechain > key (used for the ownership proof) and the output key share can be on > different hardened HD paths (following on from a path derived from the > outpoint of the UTXO, similar to the method in BIP175). > > Tom > > > > On Sun, Apr 5, 2020 at 3:17 PM Bob McElrath wrote: > >> Note that this attack requires collaboration with the current UTXO owner. >> Generally if there's some form of address/payment request, the current >> holder is >> trying to transfer the UXTO to some other (non-statechain) entity, and he >> knows >> the target of the transfer, and participates in the protocol to authorize >> it. >> The current holder must obtain the target pubkey for the transfer >> out-of-band >> with respect to the SE, or the SE can MITM that. >> >> It's a stated security assumption that the sender or receiver do not >> collude >> with the SE. If either do, then your attack is generally possible and all >> bets >> are off. So what you've described is simply the SE colluding with the >> receiver. >> The receiver will *already* receive the UTXO, so the receiver here is >> assisting >> the SE in stealing his (the receiver's) funds, or the SE has done a MITM >> on the >> transfer. Various improvements including blind signing, a SE-federation, >> etc >> are valuable to consider to mitigate this. But the SE must be prevented, >> one way >> or another, from "buying the UTXO". The SE cannot be allowed to be both >> operator >> of the SE and a customer of it, as this clearly violates the no-receiver >> collusion principle. >> >> "Adding a new user key" doesn't change the situation. There's already a >> user key >> involved, and the user has already acquiesced to the transfer. >> Acquiescing with >> two keys doesn't change anything. >> >> As far as proving and tracing the fraud, this is where "single use seals" >> come >> in. Each SE transfer can involve an "opening" of a seal, followed by a >> "close" >> when it is transferred, creating a linear history of ownership. If the SE >> obtains the full private key x, one way or another, the spend of that >> UTXO will >> fall outside this seal-based history, and proof of fraud will be evident. >> It >> won't be possible to determine *which* of the old owners collaborated >> with the >> SE, but it gives clear proof that the SE is not to be trusted. A customer >> might >> demand that a seal-based system be in use as an independent entity from >> the SE, >> to audit the honesty of the SE. The seal system does not require any of >> the keys >> required for transfer. See https://mainstay.xyz as a potential >> implementation. >> There are lots of reasons this might required as an AML solution for some >> businesses anyway. >> >> Nadav Kohen via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] >> wrote: >> > 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 < >> 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 >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> > !DSPAM:5e87670a231323960034969! >> >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev@lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> > >> > !DSPAM:5e87670a231323960034969! >> >> -- >> Cheers, Bob McElrath >> >> "For every complex problem, there is a solution that is simple, neat, and >> wrong." >> -- H. L. Mencken >> >> --000000000000dcbff105a510107c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

An quick update on progress with ou= r statechain implementation which we are pressing ahead with - we have star= ted work on a version in Rust (https://github.com/commerceblock/mercury)=C2=A0that is=C2=A0ba= sed on the 2P ECDSA gotham-city wallet from KZen (https://github.com/KZen-networks/gotham-cit= y), and using their implementation of Lindel's 2P ECDSA protocol, w= hich is very fast (we can always swap to a different protocol later). Also,= we are planning on using a sparse Merkle tree attested to a Mainstay slot = (mainstay.xyz) for the proof-of-publica= tion/proof-of-ownership - using the protocol described here:=C2=A0https://github.com/commerceblock/mercury/blob/master/doc/statechains.md=C2=A0and=C2=A0https://git= hub.com/thyeem/monotree. Any comments on these choices or on anything e= lse are highly appreciated.=C2=A0

Tom
<= br>
On Sun,= Apr 5, 2020 at 10:25 PM Tom Trevethan <tom@commerceblock.com> wrote:
Hi Bob and Nadav,

There seems to be no way to prevent a malicious SE from stealing a= n output=C2=A0from the current owner=C2=A0by either colluding with (or=C2= =A0being) a previous owner. But with a proof-of-publication (i.e. the state= chain) it is possible for the current owner to have a proof that the SE has= stolen from them. It=C2=A0seems to me that the statechain itself provides = two functions: 1. Proof that an output has only a single owner at any time = (preventing the SE from double-spending) and 2. a way for the current owner= to prove their ownership, and require their permission to change ownership= . 1. can just be a publication by the SE, but 2. requires that the output i= s transferred=C2=A0to a public key of the owner, and only via a signature o= f the previous owner (in this way the SE cannot re-assign ownership unilate= rally). Therefore I think Nadav is right, and this needs to be a key that t= he SE can never know (even if they are malicious), but which can be used to= prove ownership, and in turn prove fraud on the part of the SE.=C2=A0

I don't think that this should be too much of an i= ssue: any wallet will have to use new keys for each output and transfer any= way. The statechain key (used for the ownership proof) and the output key s= hare can be on different hardened HD paths (following on from a path derive= d from the outpoint of the UTXO, similar to the method in BIP175).=C2=A0

Tom



On Sun, Apr 5= , 2020 at 3:17 PM Bob McElrath <bob@mcelrath.org> wrote:
Note that this attack requires collaboration = with the current UTXO owner.
Generally if there's some form of address/payment request, the current = holder is
trying to transfer the UXTO to some other (non-statechain) entity, and he k= nows
the target of the transfer, and participates in the protocol to authorize i= t.
The current holder must obtain the target pubkey for the transfer out-of-ba= nd
with respect to the SE, or the SE can MITM that.

It's a stated security assumption that the sender or receiver do not co= llude
with the SE. If either do, then your attack is generally possible and all b= ets
are off. So what you've described is simply the SE colluding with the r= eceiver.
The receiver will *already* receive the UTXO, so the receiver here is assis= ting
the SE in stealing his (the receiver's) funds, or the SE has done a MIT= M on the
transfer.=C2=A0 Various improvements including blind signing, a SE-federati= on, etc
are valuable to consider to mitigate this. But the SE must be prevented, on= e way
or another, from "buying the UTXO". The SE cannot be allowed to b= e both operator
of the SE and a customer of it, as this clearly violates the no-receiver collusion principle.

"Adding a new user key" doesn't change the situation. There&#= 39;s already a user key
involved, and the user has already acquiesced to the transfer. Acquiescing = with
two keys doesn't change anything.

As far as proving and tracing the fraud, this is where "single use sea= ls" come
in. Each SE transfer can involve an "opening" of a seal, followed= by a "close"
when it is transferred, creating a linear history of ownership. If the SE obtains the full private key x, one way or another, the spend of that UTXO = will
fall outside this seal-based history, and proof of fraud will be evident. I= t
won't be possible to determine *which* of the old owners collaborated w= ith the
SE, but it gives clear proof that the SE is not to be trusted. A customer m= ight
demand that a seal-based system be in use as an independent entity from the= SE,
to audit the honesty of the SE. The seal system does not require any of the= keys
required for transfer. See https://mainstay.xyz as a potential implementatio= n.
There are lots of reasons this might required as an AML solution for some businesses anyway.

Nadav Kohen via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wro= te:
> Hey all,
>
> So my main concern with the proposal as written is that the Statechain= Entity
> (SE) can untraceably=C2=A0scam its users with the following attack: >
> 1) Buy the utxo (have it transferred to a key it knows), this first st= ep 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=C2=A0
> knows the full private key, x, from when it owned the UTXO (and had bo= th
> shards), and so it can compute x/s_n =3D the current users shard. It c= an then
> sign for the current user, and forge a state transition to a key it ow= ns before
> spending the UTXO on chain.
>
> The main problem here is that the user who had their funds stolen cann= ot prove
> to anyone that this has happened since the attack compromises their ke= y.
> That said, I think this problem is easily fixed by adding a new user k= ey to the
> protocol with which they must sign in order for the transfer to be con= sidered
> valid on the state chain. This way, if the SE wishes to steal the fund= s (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:
>
>=C2=A0 =C2=A0 =C2=A0Thanks for all of the input and comments - I do now= think that the
>=C2=A0 =C2=A0 =C2=A0decrementing nSequence relative locktime backup sys= tem with kick-off
>=C2=A0 =C2=A0 =C2=A0transaction is the way to go, including a fee penal= ty via CPFP to
>=C2=A0 =C2=A0 =C2=A0disincentivise=C2=A0DoS, as suggested.=C2=A0
>=C2=A0 =C2=A0 =C2=A0I have started a more detailed document specifying = the proposed protocol in
>=C2=A0 =C2=A0 =C2=A0more detail:=C2=A0https= ://github.com/commerceblock/mercury/blob/master/
>=C2=A0 =C2=A0 =C2=A0statechains.md=C2=A0which includes improvements to = the transfer=C2=A0mechanism (and
>=C2=A0 =C2=A0 =C2=A0an explanation of how this can be used to transfer/= novate positions in
>=C2=A0 =C2=A0 =C2=A0DLCs). Always happy to get more feedback or PRs.=C2= =A0
>
>=C2=A0 =C2=A0 =C2=A0Tom
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <= tom@commercebloc= k.com>
>=C2=A0 =C2=A0 =C2=A0wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi David,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just for clarity, I left nChain over = 2 years ago (having worked there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since 2016). While there, I (along wi= th other researchers) were given
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0free rein to work on any ideas we wan= ted to. I had been interested in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the scaling of Bitcoin off-chain, and= this was one of several things I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spent time on (including things like = sidechains,=C2=A0pegs and threshold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures). This patent application = came out of an idea I had to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transfer ownership of UTXOs off-chain= that has some similarities to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statechains proposal, which has shown= there is interest and demand for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this type of system.=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Although I think the existence of thi= s application is something to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mindful of, there are several importa= nt things to note:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Although there are similarities, t= he current ideas are significantly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different to those in the application= .=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. The key transfer protocol as descr= ibed in the application is not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secure (for several reasons, includin= g as discussed above, by Albert
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Bob etc.) - and a different mecha= nism is required.=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Decrementing timelocks (as suggest= ed in the application) are prior
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0art (Decker-Wattenhofer 2015), and in= any case any implementation will
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0most likely use an 'invalidation = tree' relative locktime backup
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism for open-ended UTXOs.=C2=A0=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. The patent application has not bee= n granted (it was made in May
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02017) and the international search re= port rejected it on the grounds of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prior art.=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tom
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Mar 31, 2020 at 11:36 AM Davi= d A. Harding <dave@dt= rt.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, Mar 25, 2020 at= 01:52:10PM +0000, Tom Trevethan via
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi all,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> We are starting to= work on an implementation of the statechains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concept (
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> https://med= ium.com/@RubenSomsen/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statechains-non-custodi= al-off-chain-bitcoin-transfer-1ae4845a4a39),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> There are two main= modifications we are looking at:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> 2. Replacing the 2= -of-2 multisig output (paying to statechain
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entity SE key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> and transitory key= ) with a single P2(W)PKH output where the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> shared between the= SE and the current owner. The SE and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current owner
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> can then sign with= a 2-of-2 ECDSA MPC.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dr. Trevethan,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would you be able to ex= plain how your proposal to use statechains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02P-ECDSA relates to you= r patent assigned to nChain Holdings for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Secure
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0off-chain blockchain tr= ansactions"?[1]=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 [1] https://patents.google.com/patent/US20200074464A1 >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here are some excerpts = from the application that caught my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attention in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the context of statecha= ins in general and your proposal to this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> an exchange platfo= rm that is trusted to implement and operate the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> transaction protoc= ol, without requiring an on-chain transaction.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> off-chain transact= ions enable one computer system to generate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> transactions that = are recordable to a blockchain in different
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> circumstances
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> at least some of t= he off-chain transactions are valid for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recording on
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the blockchain eve= n in the event of a catastrophic failure of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> exchange (e.g., ex= change going permanently off-line or loosing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> shares).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> there may be provi= ded a computer readable storage medium
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> two-party elliptic= curve digital signature algorithm (two-party
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ECDSA)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> script comprising = computer executable instructions which, when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> executed, configur= e a processor to perform functions of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0two-party
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> elliptic curve dig= ital signature algorithm described herein.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> [...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> In this instance t= he malicious actor would then also have to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0collude
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> with a previous ow= ner of the funds to recreate the full key.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> an attack requires= either the simultaneous theft of both exchange
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> depositor keys or = collusion with previous legitimate owners of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0funds,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the opportunities = for a malicious attacker to compromise the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exchange
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> platform are limit= ed.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-Dave
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list
>=C2=A0 =C2=A0 =C2=A0bitcoin-dev@lists.linuxfoundation.org
>=C2=A0 =C2=A0 =C2=A0https://lists.= linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> !DSPAM:5e87670a231323960034969!

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev
>
>
> !DSPAM:5e87670a231323960034969!

--
Cheers, Bob McElrath

"For every complex problem, there is a solution that is simple, neat, = and wrong."
=C2=A0 =C2=A0 -- H. L. Mencken

--000000000000dcbff105a510107c--