path: root/1d/1348509d95a9b9bcac32675204106286b955f0

Return-Path: <tom@commerceblock.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 559C8C07FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  7 May 2020 15:03:18 +0000 (UTC)
Received: by mail-ej1-f42.google.com with SMTP id pg17so4836682ejb.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAJvkSseW9OZ50yQiS7e0zt9tQt4v9aoikgGs_54_kMN-ORkQgw@mail.gmail.com>
 <20200331103508.asvxujkhtifj6n7i@ganymede>
 <CAJvkSsfWoTTUOUYjQDrP-xrwB8FwAGUaDKSrYX3=-+wAE3yDLA@mail.gmail.com>
 <CAJvkSseMqFUJD7rj1AAZPMy0Hf6tufkvrHFgzsViPEirWMWx_A@mail.gmail.com>
 <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
 <20200405141717.GN28113@mcelrath.org>
 <CAJvkSsf2UxDAkxMC4MuedP2xcgM4_aDQNQfofeW7MBh2oK73rw@mail.gmail.com>
In-Reply-To: <CAJvkSsf2UxDAkxMC4MuedP2xcgM4_aDQNQfofeW7MBh2oK73rw@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Thu, 7 May 2020 15:54:53 +0100
Message-ID: <CAJvkSsek2Z3a1tPHrfS4ebViNB0nCikm0mM6mXNbidtcZ86gGQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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, 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 <tom@commerceblock.com> 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 <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
>> 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

<div dir=3D"ltr">Hi,<div><br></div><div>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 (<a href=3D"https://github.com/commerceblock/=
mercury">https://github.com/commerceblock/mercury</a>)=C2=A0that is=C2=A0ba=
sed on the 2P ECDSA gotham-city wallet from KZen (<a href=3D"https://github=
.com/KZen-networks/gotham-city">https://github.com/KZen-networks/gotham-cit=
y</a>), and using their implementation of Lindel&#39;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 =
(<a href=3D"http://mainstay.xyz">mainstay.xyz</a>) for the proof-of-publica=
tion/proof-of-ownership - using the protocol described here:=C2=A0<a href=
=3D"https://github.com/commerceblock/mercury/blob/master/doc/statechains.md=
">https://github.com/commerceblock/mercury/blob/master/doc/statechains.md</=
a>=C2=A0and=C2=A0<a href=3D"https://github.com/thyeem/monotree">https://git=
hub.com/thyeem/monotree</a>. Any comments on these choices or on anything e=
lse are highly appreciated.=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 Sun,=
 Apr 5, 2020 at 10:25 PM Tom Trevethan &lt;<a href=3D"mailto:tom@commercebl=
ock.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 rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">Hi Bob and Nadav,<div><br></=
div><div>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</div=
><div><br></div><div>I don&#39;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</d=
iv><div><br></div><div>Tom</div><div><br></div><div><br></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 5=
, 2020 at 3:17 PM Bob McElrath &lt;<a href=3D"mailto:bob@mcelrath.org" targ=
et=3D"_blank">bob@mcelrath.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">Note that this attack requires collaboration =
with the current UTXO owner.<br>
Generally if there&#39;s some form of address/payment request, the current =
holder is<br>
trying to transfer the UXTO to some other (non-statechain) entity, and he k=
nows<br>
the target of the transfer, and participates in the protocol to authorize i=
t.<br>
The current holder must obtain the target pubkey for the transfer out-of-ba=
nd<br>
with respect to the SE, or the SE can MITM that.<br>
<br>
It&#39;s a stated security assumption that the sender or receiver do not co=
llude<br>
with the SE. If either do, then your attack is generally possible and all b=
ets<br>
are off. So what you&#39;ve described is simply the SE colluding with the r=
eceiver.<br>
The receiver will *already* receive the UTXO, so the receiver here is assis=
ting<br>
the SE in stealing his (the receiver&#39;s) funds, or the SE has done a MIT=
M on the<br>
transfer.=C2=A0 Various improvements including blind signing, a SE-federati=
on, etc<br>
are valuable to consider to mitigate this. But the SE must be prevented, on=
e way<br>
or another, from &quot;buying the UTXO&quot;. The SE cannot be allowed to b=
e both operator<br>
of the SE and a customer of it, as this clearly violates the no-receiver<br=
>
collusion principle.<br>
<br>
&quot;Adding a new user key&quot; doesn&#39;t change the situation. There&#=
39;s already a user key<br>
involved, and the user has already acquiesced to the transfer. Acquiescing =
with<br>
two keys doesn&#39;t change anything.<br>
<br>
As far as proving and tracing the fraud, this is where &quot;single use sea=
ls&quot; come<br>
in. Each SE transfer can involve an &quot;opening&quot; of a seal, followed=
 by a &quot;close&quot;<br>
when it is transferred, creating a linear history of ownership. If the SE<b=
r>
obtains the full private key x, one way or another, the spend of that UTXO =
will<br>
fall outside this seal-based history, and proof of fraud will be evident. I=
t<br>
won&#39;t be possible to determine *which* of the old owners collaborated w=
ith the<br>
SE, but it gives clear proof that the SE is not to be trusted. A customer m=
ight<br>
demand that a seal-based system be in use as an independent entity from the=
 SE,<br>
to audit the honesty of the SE. The seal system does not require any of the=
 keys<br>
required for transfer. See <a href=3D"https://mainstay.xyz" rel=3D"noreferr=
er" target=3D"_blank">https://mainstay.xyz</a> as a potential implementatio=
n.<br>
There are lots of reasons this might required as an AML solution for some<b=
r>
businesses anyway.<br>
<br>
Nadav Kohen via bitcoin-dev [<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>] wro=
te:<br>
&gt; Hey all,<br>
&gt; <br>
&gt; So my main concern with the proposal as written is that the Statechain=
 Entity<br>
&gt; (SE) can untraceably=C2=A0scam its users with the following attack:<br=
>
&gt; <br>
&gt; 1) Buy the utxo (have it transferred to a key it knows), this first st=
ep can be<br>
&gt; skipped if the utxo was created by the SE.<br>
&gt; 2) Transfer the UTXO to someone else, let it be for however long<br>
&gt; 3) When it wishes to steal the UTXO, the SE now knows its own shard s_=
n and it=C2=A0<br>
&gt; knows the full private key, x, from when it owned the UTXO (and had bo=
th<br>
&gt; shards), and so it can compute x/s_n =3D the current users shard. It c=
an then<br>
&gt; sign for the current user, and forge a state transition to a key it ow=
ns before<br>
&gt; spending the UTXO on chain.<br>
&gt; <br>
&gt; The main problem here is that the user who had their funds stolen cann=
ot prove<br>
&gt; to anyone that this has happened since the attack compromises their ke=
y.<br>
&gt; That said, I think this problem is easily fixed by adding a new user k=
ey to the<br>
&gt; protocol with which they must sign in order for the transfer to be con=
sidered<br>
&gt; valid on the state chain. This way, if the SE wishes to steal the fund=
s (which<br>
&gt; they still can), at least it is traceable/provable that this SE is not=
<br>
&gt; trustworthy as there is no evidence of a valid transfer for the funds =
that have<br>
&gt; been stolen.<br>
&gt; <br>
&gt; Best,<br>
&gt; Nadav<br>
&gt; <br>
&gt; On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Thanks for all of the input and comments - I do now=
 think that the<br>
&gt;=C2=A0 =C2=A0 =C2=A0decrementing nSequence relative locktime backup sys=
tem with kick-off<br>
&gt;=C2=A0 =C2=A0 =C2=A0transaction is the way to go, including a fee penal=
ty via CPFP to<br>
&gt;=C2=A0 =C2=A0 =C2=A0disincentivise=C2=A0DoS, as suggested.=C2=A0<br>
&gt;=C2=A0 =C2=A0 =C2=A0I have started a more detailed document specifying =
the proposed protocol in<br>
&gt;=C2=A0 =C2=A0 =C2=A0more detail:=C2=A0<a href=3D"https://github.com/com=
merceblock/mercury/blob/master/" rel=3D"noreferrer" target=3D"_blank">https=
://github.com/commerceblock/mercury/blob/master/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0statechains.md=C2=A0which includes improvements to =
the transfer=C2=A0mechanism (and<br>
&gt;=C2=A0 =C2=A0 =C2=A0an explanation of how this can be used to transfer/=
novate positions in<br>
&gt;=C2=A0 =C2=A0 =C2=A0DLCs). Always happy to get more feedback or PRs.=C2=
=A0<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0Tom<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan &lt;=
<a href=3D"mailto:tom@commerceblock.com" target=3D"_blank">tom@commercebloc=
k.com</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0wrote:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi David,<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Just for clarity, I left nChain over =
2 years ago (having worked there<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since 2016). While there, I (along wi=
th other researchers) were given<br>
&gt;=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<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the scaling of Bitcoin off-chain, and=
 this was one of several things I<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spent time on (including things like =
sidechains,=C2=A0pegs and threshold<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures). This patent application =
came out of an idea I had to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transfer ownership of UTXOs off-chain=
 that has some similarities to the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statechains proposal, which has shown=
 there is interest and demand for<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this type of system.=C2=A0<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Although I think the existence of thi=
s application is something to be<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mindful of, there are several importa=
nt things to note:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Although there are similarities, t=
he current ideas are significantly<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different to those in the application=
.=C2=A0<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. The key transfer protocol as descr=
ibed in the application is not<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0secure (for several reasons, includin=
g as discussed above, by Albert<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and Bob etc.) - and a different mecha=
nism is required.=C2=A0<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Decrementing timelocks (as suggest=
ed in the application) are prior<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0art (Decker-Wattenhofer 2015), and in=
 any case any implementation will<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0most likely use an &#39;invalidation =
tree&#39; relative locktime backup<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism for open-ended UTXOs.=C2=A0=
<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. The patent application has not bee=
n granted (it was made in May<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02017) and the international search re=
port rejected it on the grounds of<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0prior art.=C2=A0<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tom<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, Mar 31, 2020 at 11:36 AM Davi=
d A. Harding &lt;<a href=3D"mailto:dave@dtrt.org" target=3D"_blank">dave@dt=
rt.org</a>&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:<br>
&gt; <br>
&gt;=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<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bitcoin-dev wrote:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; Hi all,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; We are starting to=
 work on an implementation of the statechains<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0concept (<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; <a href=3D"https:/=
/medium.com/@RubenSomsen/" rel=3D"noreferrer" target=3D"_blank">https://med=
ium.com/@RubenSomsen/</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statechains-non-custodi=
al-off-chain-bitcoin-transfer-1ae4845a4a39),<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; [...]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; There are two main=
 modifications we are looking at:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; [...]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; 2. Replacing the 2=
-of-2 multisig output (paying to statechain<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0entity SE key<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; and transitory key=
) with a single P2(W)PKH output where the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0public key<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; shared between the=
 SE and the current owner. The SE and the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0current owner<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; can then sign with=
 a 2-of-2 ECDSA MPC.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Dr. Trevethan,<br>
&gt; <br>
&gt;=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<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with<br>
&gt;=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<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quot;Secure<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0off-chain blockchain tr=
ansactions&quot;?[1]=C2=A0<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 [1] <a hr=
ef=3D"https://patents.google.com/patent/US20200074464A1" rel=3D"noreferrer"=
 target=3D"_blank">https://patents.google.com/patent/US20200074464A1</a><br=
>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Here are some excerpts =
from the application that caught my<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attention in<br>
&gt;=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<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0list in<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0particular:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; an exchange platfo=
rm that is trusted to implement and operate the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; transaction protoc=
ol, without requiring an on-chain transaction.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; off-chain transact=
ions enable one computer system to generate<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; transactions that =
are recordable to a blockchain in different<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; circumstances<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; [...]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; at least some of t=
he off-chain transactions are valid for<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recording on<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; the blockchain eve=
n in the event of a catastrophic failure of the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; exchange (e.g., ex=
change going permanently off-line or loosing<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; shares).<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; [...]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; there may be provi=
ded a computer readable storage medium<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0including a<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; two-party elliptic=
 curve digital signature algorithm (two-party<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ECDSA)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; script comprising =
computer executable instructions which, when<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; executed, configur=
e a processor to perform functions of a<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0two-party<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; elliptic curve dig=
ital signature algorithm described herein.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; [...]<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; In this instance t=
he malicious actor would then also have to<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0collude<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; with a previous ow=
ner of the funds to recreate the full key.<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Because<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; an attack requires=
 either the simultaneous theft of both exchange<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; depositor keys or =
collusion with previous legitimate owners of<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0funds,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; the opportunities =
for a malicious attacker to compromise the<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0exchange<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&gt; platform are limit=
ed.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you,<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-Dave<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0_______________________________________________<br>
&gt;=C2=A0 =C2=A0 =C2=A0bitcoin-dev mailing list<br>
&gt;=C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0<a href=3D"https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
&gt; !DSPAM:5e87670a231323960034969!<br>
<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt; <br>
&gt; <br>
&gt; !DSPAM:5e87670a231323960034969!<br>
<br>
--<br>
Cheers, Bob McElrath<br>
<br>
&quot;For every complex problem, there is a solution that is simple, neat, =
and wrong.&quot;<br>
=C2=A0 =C2=A0 -- H. L. Mencken <br>
<br>
</blockquote></div>
</blockquote></div>

--000000000000dcbff105a510107c--