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 9E66DC0177 for ; 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 ; 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 ; 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 ; 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 To: Nadav Kohen , Bitcoin Protocol Discussion Message-ID: <20200405141717.GN28113@mcelrath.org> References: <20200331103508.asvxujkhtifj6n7i@ganymede> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cvVnyQ+4j833TQvp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Tom Trevethan 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 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 > 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 > 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--