From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7EC4EC0177 for ; Sun, 5 Apr 2020 21:26:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 6824A2281E for ; Sun, 5 Apr 2020 21:26:08 +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 gRC-0zpDi8t6 for ; Sun, 5 Apr 2020 21:26:05 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com [209.85.208.50]) by silver.osuosl.org (Postfix) with ESMTPS id 18229227FC for ; Sun, 5 Apr 2020 21:26:05 +0000 (UTC) Received: by mail-ed1-f50.google.com with SMTP id i7so16675703edq.3 for ; Sun, 05 Apr 2020 14:26:04 -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=/IOWhnlTrUk1ONLc9+LlLZcYpaVT8reUvBzPvKiD5pk=; b=z5cSmlCAeifglS6LesnbTlLfKtV7mg3GFPH1mzsDQGRewlbB3k6GtrWrm04AlJ3nrO HMLBjRWn6YTUVumpQw0QqhKL0i9YOu5IekfMvPTnK0+VZDeUAlpXXUiIUClU98MRDU1T ULZO+6Wf4nJmDTYvxdY9Xz7m87XeX//ZM7fVjo2MKdJ6hod42KATLUJr0UVbBFUrk/b/ snIfBwzq6AprdW3tqmgdXMLZXdUCMuMIzAdk50/SYZQ2scrcknz1kP/QxMntL5yVsrcg jW+ffoGMmX56X1A2xKpy7VpZqGpeNlrIHb49EIb8EobjNvJBBB4b8Hv9KNamVZVHv+w+ MNDw== 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=/IOWhnlTrUk1ONLc9+LlLZcYpaVT8reUvBzPvKiD5pk=; b=mFieVkPs0iV9nXyUj1E93BM6i2VyRQfdLcE5fqfntEfDLOTKtrG+L/S9Wp0mfEHy0d iv/UOciExOq0jzT+F46+tpy7SJ7l9/fHQo5xQ6mu/IUrQIEYPx4QSTf0NXDX2jKz+RbJ FL1mQlfdMqqgochnExdJhYikidbquIwk4Q6g4CH6rZx1vTANNQEGKmlUVhMQFrBmv7/A u7t2oZiV6JvmtRPjzCK2LcWn1FpwUwot9xDDrmeG60to4WHKwfcgmg3QyN4LgOCdCNpw R7s9nRfP0gp7CCEnFo8jQbU/YotQ9HOhkYPhR7NMrCvvs4uLo/FYR9Rg851LHSlo66Gh pKog== X-Gm-Message-State: AGi0PuZQzdrmtObI7mkEhh0Eda/YkGBdZWuuA6v+NXQtSKbXhQd/P6YV 49OFrp60yvu8M1ZNRL+Mv9b9dVxUiHpNnv27kPbd X-Google-Smtp-Source: APiQypK+m9oaVabGLTOPJ6F0TnbUdL4dd6pn6BXLENqX5V0fMn0JT676FWTciFxEUoXIK+hmphebAcCwcdzLBFWBHso= X-Received: by 2002:a50:d24c:: with SMTP id o12mr16819112edg.219.1586121963149; Sun, 05 Apr 2020 14:26:03 -0700 (PDT) MIME-Version: 1.0 References: <20200331103508.asvxujkhtifj6n7i@ganymede> <20200405141717.GN28113@mcelrath.org> In-Reply-To: <20200405141717.GN28113@mcelrath.org> From: Tom Trevethan Date: Sun, 5 Apr 2020 22:25:51 +0100 Message-ID: To: Bob McElrath Content-Type: multipart/alternative; boundary="0000000000002f2c4105a291cc13" X-Mailman-Approved-At: Sun, 05 Apr 2020 22:55:22 +0000 Cc: Bitcoin Protocol Discussion 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: Sun, 05 Apr 2020 21:26:08 -0000 --0000000000002f2c4105a291cc13 Content-Type: text/plain; charset="UTF-8" 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 > > > 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 > > --0000000000002f2c4105a291cc13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Bob and Nadav,

There seems to be no = way to prevent a malicious SE from stealing an 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 statechain) it is possible for the cu= rrent 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-s= pending) and 2. a way for the current owner to prove their ownership, and r= equire their permission to change ownership. 1. can just be a publication b= y the SE, but 2. requires that the output is transferred=C2=A0to a public k= ey of the owner, and only via a signature of the previous owner (in this wa= y 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 th= ey are malicious), but which can be used to prove ownership, and in turn pr= ove fraud on the part of the SE.=C2=A0

I don't= think that this should be too much of an issue: any wallet will have to us= e new keys for each output and transfer anyway. The statechain key (used fo= r the ownership proof) and the output key share can be on different hardene= d HD paths (following on from a path derived 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 &= lt;bob@mcelrath.org> wrote:
No= te 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

--0000000000002f2c4105a291cc13--