path: root/99/32a365bf8dacbc7fe62fce9a2f02ab178556ac

Return-Path: <bob@mcelrath.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9E66DC0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Apr 2020 14:17:21 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 8AE7886B7B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Apr 2020 14:17:21 +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 SM4psN8R3J7K
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Apr 2020 14:17:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 3358B86B0B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  5 Apr 2020 14:17:20 +0000 (UTC)
Received: from mcelrath.org (localhost [127.0.0.1])
 by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 035EHHs4004281
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); 
 Sun, 5 Apr 2020 14:17:17 GMT
Received: (from mcelrath@localhost)
 by mcelrath.org (8.14.4/8.14.4/Submit) id 035EHHFD004280;
 Sun, 5 Apr 2020 14:17:17 GMT
X-Authentication-Warning: mcelrath.org: mcelrath set sender to
 bob@mcelrath.org using -f
Date: Sun, 5 Apr 2020 14:17:17 +0000
From: Bob McElrath <bob@mcelrath.org>
To: Nadav Kohen <nadav@suredbits.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200405141717.GN28113@mcelrath.org>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp"
Content-Disposition: inline
In-Reply-To: <CALGTLwOu+R6ZmzYb4ESc9kjgrpspmmdWogF_Z=msQB8dTqD0xQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Tom Trevethan <tom@commerceblock.com>
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: Sun, 05 Apr 2020 14:17:21 -0000


--cvVnyQ+4j833TQvp
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Note that this attack requires collaboration with the current UTXO owner.
Generally if there's some form of address/payment request, the current hold=
er 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 collude
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 recei=
ver.
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 MITM on=
 the
transfer.  Various improvements including blind signing, a SE-federation, e=
tc
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 be both ope=
rator
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 use=
r 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" c=
ome
in. Each SE transfer can involve an "opening" of a seal, followed by a "clo=
se"
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 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 implementati=
on.
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,
>=20
> So my main concern with the proposal as written is that the Statechain En=
tity
> (SE) can untraceably=A0scam its users with the following attack:
>=20
> 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 a=
nd it=A0
> knows the full private key, x, from when it owned the UTXO (and had both
> shards), and so it can compute x/s_n =3D 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.
>=20
> 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 consid=
ered
> 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 tha=
t have
> been stolen.
>=20
> Best,
> Nadav
>=20
> On Thu, Apr 2, 2020 at 7:22 PM Tom Trevethan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>     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=A0DoS, as suggested.=A0
>     I have started a more detailed document specifying the proposed proto=
col in
>     more detail:=A0https://github.com/commerceblock/mercury/blob/master/
>     statechains.md=A0which includes improvements to the transfer=A0mechan=
ism (and
>     an explanation of how this can be used to transfer/novate positions in
>     DLCs). Always happy to get more feedback or PRs.=A0
>=20
>     Tom
>=20
>     On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com>
>     wrote:
>=20
>         Hi David,
>=20
>         Just for clarity, I left nChain over 2 years ago (having worked t=
here
>         since 2016). While there, I (along with other researchers) were g=
iven
>         free rein to work on any ideas we wanted to. I had been intereste=
d in
>         the scaling of Bitcoin off-chain, and this was one of several thi=
ngs I
>         spent time on (including things like sidechains,=A0pegs and thres=
hold
>         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 deman=
d for
>         this type of system.=A0
>=20
>         Although I think the existence of this application is something t=
o be
>         mindful of, there are several important things to note:
>=20
>         1. Although there are similarities, the current ideas are signifi=
cantly
>         different to those in the application.=A0
>         2. The key transfer protocol as described in the application is n=
ot
>         secure (for several reasons, including as discussed above, by Alb=
ert
>         and Bob etc.) - and a different mechanism is required.=A0
>         3. Decrementing timelocks (as suggested in the application) are p=
rior
>         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.=A0
>         4. The patent application has not been granted (it was made in May
>         2017) and the international search report rejected it on the grou=
nds of
>         prior art.=A0
>=20
>         Tom
>=20
>         On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <dave@dtrt.org>
>         wrote:
>=20
>             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 statech=
ains
>             concept (
>             > https://medium.com/@RubenSomsen/
>             statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a=
4a39),
>             >
>             > [...]
>             > There are two main modifications we are looking at:
>             > [...]
>             >
>             > 2. Replacing the 2-of-2 multisig output (paying to statecha=
in
>             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.
>=20
>             Dr. Trevethan,
>=20
>             Would you be able to explain how your proposal to use statech=
ains
>             with
>             2P-ECDSA relates to your patent assigned to nChain Holdings f=
or
>             "Secure
>             off-chain blockchain transactions"?[1]=A0
>=20
>             =A0 =A0 [1] https://patents.google.com/patent/US20200074464A1
>=20
>             Here are some excerpts from the application that caught my
>             attention in
>             the context of statechains in general and your proposal to th=
is
>             list in
>             particular:
>=20
>             > an exchange platform that is trusted to implement and opera=
te the
>             > transaction protocol, without requiring an on-chain transac=
tion.
>             The
>             > off-chain transactions enable one computer system to genera=
te
>             multiple
>             > transactions that are recordable to a blockchain in differe=
nt
>             > 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 loos=
ing
>             key
>             > shares).
>             >
>             > [...]
>             >
>             > there may be provided a computer readable storage medium
>             including a
>             > two-party elliptic curve digital signature algorithm (two-p=
arty
>             ECDSA)
>             > script comprising computer executable instructions which, w=
hen
>             > 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 ex=
change
>             and
>             > depositor keys or collusion with previous legitimate owners=
 of
>             funds,
>             > the opportunities for a malicious attacker to compromise the
>             exchange
>             > platform are limited.
>=20
>             Thank you,
>=20
>             -Dave
>=20
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
> !DSPAM:5e87670a231323960034969!

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

--
Cheers, Bob McElrath

"For every complex problem, there is a solution that is simple, neat, and w=
rong."
    -- H. L. Mencken=20


--cvVnyQ+4j833TQvp
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAl6J6GwACgkQjwioWRGe9K3AVQCgmH8qqCgz9jY+As2YyUs0cFcx
y6QAoPL8jVmWzuYMDMhpUDVQFtRcdBsi
=5Pzp
-----END PGP SIGNATURE-----

--cvVnyQ+4j833TQvp--