From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5E6A3C016E for ; Sun, 14 Jun 2020 22:30:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 4DA5E869B9 for ; Sun, 14 Jun 2020 22:30:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sR6SfKWRfFT for ; Sun, 14 Jun 2020 22:30:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ej1-f42.google.com (mail-ej1-f42.google.com [209.85.218.42]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 9C935869AB for ; Sun, 14 Jun 2020 22:30:42 +0000 (UTC) Received: by mail-ej1-f42.google.com with SMTP id q19so15387611eja.7 for ; Sun, 14 Jun 2020 15:30:42 -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=BkPtsemFHBLJYcEwBBnvhDQdwN8d7HswhkssOG8E/KU=; b=yMtro2QkfgLu0EV1Fy3DOyF15RUCfYSspvlXk9k8g6KhuB4Rhfi236Fe+eZvdn7aRu KAtjY5spAGWOy9gF4ZOMEWsEtiNp/xaa2zCuhdBKd89TSLBdP4wloT4hg9pL8iIAMSMV Sx5ZZFCBX3fDLHBwMuqU2ZNMUBmqP0TihhAdy3eMaMeb1x/7pWkqWfYh0gYU+7FbX9hf FxIYRytoYulJDJY0KZftdx5m7LUaguvxUg47XqckG4zn4JYx5MHkWuAWXZrInSeio03U YfhmUlggMJArUw5P9r5iAZeTzzBo/ifC4+Tr1mQdp/ozXqarhESGfni2LmmPTt07pLgp F7ug== 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=BkPtsemFHBLJYcEwBBnvhDQdwN8d7HswhkssOG8E/KU=; b=M9Dz97D8bx4iUgwnVJLJtuOwoKR8jCnNMfP9OcWm+NfKg1jKyULLVVbf0vRONi3WGO Ppl/av9/ESZ4e+lDACBtt90VTPz7Suo/WztfAUDBgtX8x07JT03PmA0nvLHV5mjYnByi OmgW/Y6YRRGgWmAtot9Xt2gxG4UKolEfCXltuK86KeQenWZ4nYwHdxhECNrF4tN0tcX4 BAqIJknU+E4jgECjk9U0N9tytB15HnMlpzR2jqePIwWsKeIzgdvU2GShMlauJzNek0zE GRhlQ0+4shZBvevan364C1pwk+T31hDJ8VTeXF7WR71zgQIhLles4Wv2ecFKiI6IYbds K2Xg== X-Gm-Message-State: AOAM532oYFL9woea9s73hNEA7jQ9WEMIamT08UTZDEAIybW4IX8stf4u HWblejZrSPOeHTKFdNAZrsl/PgPjBY9Kspez5UE6VteY4qa1 X-Google-Smtp-Source: ABdhPJxCilamYWWN4qCrF9VwbDxbeXO1eg0P+FovECT8UYmFqDSAlwZDavUMFjJPydwy4P9nw+hmIY1pbGGUYv/lJ5E= X-Received: by 2002:a50:8ad3:: with SMTP id k19mr15974018edk.162.1592173498456; Sun, 14 Jun 2020 15:24:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Trevethan Date: Sun, 14 Jun 2020 23:24:47 +0100 Message-ID: To: Ruben Somsen Content-Type: multipart/alternative; boundary="000000000000cbfa6d05a812c781" X-Mailman-Approved-At: Sun, 14 Jun 2020 22:33:05 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Blind Statechains 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, 14 Jun 2020 22:30:44 -0000 --000000000000cbfa6d05a812c781 Content-Type: text/plain; charset="UTF-8" Hi Ruben, Thanks for the comments. > Users would have to validate the history of the chain regardless, even if it wasn't blind, to verify whether the statechain entity hasn't been cheating, so the main difference would be in unblinding the data. My understanding was that users would need to verify the uniqueness of the ownership of the previous owner, and verify that the ownership had been signed over (which acts as proof of ownership in case the SE steals) but that backup transaction rules would be enforced by the SE (the SE must be trusted to not collude with a previous owner to sign a 'theft' transaction before the UTXO is sold on). Even if a new owner verifying that all of the previous backup transactions are correct does not prove that the SE has not signed anything else we don't know about. In the case of a blinded SE, we were thinking the way it could work is that the SE would still need to be trusted to state how many times it had co-signed. So a new owner would ask the SE how many times it has signed something (e.g. 27) and then the new owner would need to check that there are exactly 27 back up transactions and verify that each one was following the rules. Then when it came to transfer, they would send the 27 + their own backup to the new owner, who would then ask the SE again how many it had signed. Yes, the SE can store all of these transactions, encrypted with the current owners key, to make the UX easier. > I'm not sure whether this can also apply to 2P-ECDSA, but with Schnorr the statechain entity wouldn't even learn the address for the funding transaction, so it wouldn't be able to tell which UTXO it controls by watching the blockchain. Ideally, this functionality would be preserved to ensure the statechain entity can't be aware of the funds it's holding. Yes, that is the aim. Like you mentioned, this may help a lot with legal status of the SE, but also prevent the SE from being able to link swaps (while still performing them atomically). > Another thing to note is that you won't know when a statechain has been pegged out, so pruning will be impossible. You may wish to consider some kind of liveness rule where one statechain transaction needs to be made per year. If they miss the deadline, they're just forced on-chain, which is not terrible, in any case. Interesting point. I guess it is not in the interest of the owner to tell the SE that they have pegged-out a UTXO (as the SE might be able to correlate with on-chain txs). Maybe the user wallet can send the SE a message that the UTXO is pegged out some random interval after it has happened. Cheers, Tom On Fri, Jun 12, 2020 at 9:35 PM Ruben Somsen wrote: > Hi Tom, > > Blind signatures are certainly a nice feature, great to see that you're > considering it. > > >So each new owner of a UTXO must receive, store and verify the full > sequence of previous owner backup transactions to make sure that no > previous owner has asked the SE to sign a transaction that could be used to > steal the UTXO. This may end up making wallets more bloated and clunky, > given that ownership of a UTXO could change hands thousands of times > off-chain. > > Users would have to validate the history of the chain regardless, even if > it wasn't blind, to verify whether the statechain entity hasn't been > cheating, so the main difference would be in unblinding the data. > > One of my original ideas was to use the transitory key to derive the > secrets that blind the signatures (basically like an HD wallet). The > statechain entity would then store and serve blind signatures, and any new > owner would download and unblind/verify them using the transitory key (no > extensive peer-to-peer transfer needed). It's possible to make the > off-chain transactions themselves deterministic, so they can just be > generated by the client without any additional data transfer. The only > potentially unique thing in a transaction is the refund address, but this > can be the same key as the ownership key on the statechain, tweaked with > the transitory key via Diffie-Hellman (to ensure it's not linkable if it > goes on-chain). > > The general downside of this method is that all transactions are exposed > to anyone who learns the transitory key -- not just for the current > transactions (which can always be leaked no matter what you do), but also > all future transactions in that particular statechain. However, I should > note there doesn't actually seem to be much to learn, because the history > of each statechain is actually quite uninformative. The money just goes > from one pseudonymous owner to the next. > > Of course you now have scheme that changes the transitory key with each > step, so I instead suggest you introduce a secondary "blinding key" to > achieve what I described. > > I'm not sure whether this can also apply to 2P-ECDSA, but with Schnorr the > statechain entity wouldn't even learn the address for the funding > transaction, so it wouldn't be able to tell which UTXO it controls by > watching the blockchain. Ideally, this functionality would be preserved to > ensure the statechain entity can't be aware of the funds it's holding. > > Another thing to note is that you won't know when a statechain has been > pegged out, so pruning will be impossible. You may wish to consider some > kind of liveness rule where one statechain transaction needs to be made per > year. If they miss the deadline, they're just forced on-chain, which is not > terrible, in any case. > > Hope this helps! > > Cheers, > Ruben > > > > On Fri, Jun 12, 2020 at 9:23 PM Tom Trevethan via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Hello, >> >> A statechain implementation and service co-signs 'backup' (off-chain) >> transactions to transfer ownership of a UTXO from one owner to the next. A >> suggested here >> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 >> , this service (the statechain entity or SE) can be engineered to be >> 'blind' to the transactions it is signing (i.e. it does not and cannot know >> the details of the transactions it is signing) which can give significant >> privacy benefits. It would enable more private off-chain coin-swaps, and >> make collusion more difficult. >> >> The only downside of a blind SE is that it can no longer enforce the >> rules governing the sequence of backup transactions it co-signs as owners >> can ask the SE to cosign any transaction. So each new owner of a UTXO must >> receive, store and verify the full sequence of previous owner backup >> transactions to make sure that no previous owner has asked the SE to sign a >> transaction that could be used to steal the UTXO. This may end up making >> wallets more bloated and clunky, given that ownership of a UTXO could >> change hands thousands of times off-chain. >> >> In the case of a multisig, and Schnorr signatures, existing blind Schnorr >> protocols could be used to implement a blind SE, however we are opting to >> use two-party ECDSA (because there is no Schnorr yet, and in any case ECDSA >> will give a much bigger anonymity set). There is no current 2P ECDSA >> protocol that enables one of the two signers to be completely blinded, but >> it seems that this would require only minor modifications to an existing 2P >> ECDSA scheme (outlined here >> https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_ecdsa.md >> based on Lindell 2017 https://eprint.iacr.org/2017/552 ). >> >> Any comments on any of this gratefully received. >> >> Tom >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000cbfa6d05a812c781 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Ruben,

Thanks for the comments.= =C2=A0

> Users would have to validate the histo= ry of the chain regardless, even if it wasn't blind, to verify whether = the statechain entity hasn't been cheating, so the main difference woul= d be in unblinding the data.

My understanding = was that users would need to verify the uniqueness of the ownership of the = previous owner, and verify that the ownership had been signed over (which a= cts as proof of ownership in case the SE steals) but that backup transactio= n rules would be enforced by the SE (the SE must be trusted to not collude = with a previous owner to sign a 'theft' transaction before the UTXO= is sold on). Even if a new owner verifying that all of the previous backup= transactions are correct does not prove that the SE has not signed anythin= g else we don't know about.=C2=A0

In the case = of a blinded SE, we were thinking the way it could=C2=A0work is that the SE= would still need to be trusted to state how many times it had co-signed. S= o a new owner would ask the SE how many times it has signed something (e.g.= 27) and then the new owner would need to check that there are exactly 27 b= ack up transactions and verify that each one was following the rules. Then = when it came to transfer, they would send the 27=C2=A0+ their own backup to= the new owner, who would then ask the SE again how many it had signed.=C2= =A0

Yes, the SE can store all of these transaction= s, encrypted with the current owners key, to make the UX easier.=C2=A0

> I'm not sure whether this can also apply to 2= P-ECDSA, but with Schnorr the statechain entity wouldn't even learn the= address for the funding transaction, so it wouldn't be able to tell wh= ich UTXO it controls by watching the blockchain. Ideally, this functionalit= y would be preserved to ensure the statechain entity can't be aware of = the funds it's holding.

Yes, that is the aim. = Like you mentioned, this may help a lot with legal status of the SE, but al= so prevent the SE from being able to link swaps (while still performing the= m atomically).=C2=A0

> Another thing to note is= that you won't know when a statechain has been pegged out, so pruning = will be impossible. You may wish to consider some kind of liveness rule whe= re one statechain transaction needs to be made per year. If they miss the d= eadline, they're just forced on-chain, which is not terrible, in any ca= se.=C2=A0

Interesting point. I guess it is not= in the interest of the owner to tell the SE that they have pegged-out a UT= XO (as the SE might be able to correlate with on-chain txs). Maybe the user= wallet can send the SE a=C2=A0message that the UTXO is pegged out some ran= dom interval after it has happened.=C2=A0

Cheers,<= /div>

Tom

On Fri, Jun 12, 2020 at 9:35 PM Ruben Som= sen <rsomsen@gmail.com> wrot= e:
Hi Tom,

Blind signatures are certainly a nice featur= e, great to see that you're considering it.

&g= t;So each new owner of a UTXO must receive, store and verify the full seque= nce of previous owner backup transactions to make sure that no previous own= er has asked the SE to sign a transaction that could be used to steal the U= TXO. This may end up making wallets more bloated and clunky, given that own= ership of a UTXO could change hands thousands of times off-chain.

Users would have to validate the history of the chain regar= dless, even if it wasn't blind, to verify whether the statechain entity= hasn't been cheating, so the main difference would be in unblinding th= e data.

One of my original ideas was to use the tr= ansitory key to derive the secrets that blind the signatures (basically lik= e an HD wallet). The statechain entity would then store and serve blind sig= natures, and any new owner would download and unblind/verify them using the= transitory key (no extensive peer-to-peer transfer needed). It's possi= ble to make the off-chain transactions themselves deterministic, so they ca= n just be generated by the client without any additional data transfer. The= only potentially unique thing in a transaction is the refund address, but = this can be the same key as the ownership key on the statechain, tweaked wi= th the transitory key via Diffie-Hellman (to ensure it's not linkable i= f it goes on-chain).

The general downside of this = method is that all transactions are exposed to anyone who learns the transi= tory key -- not just for the current transactions (which can always be leak= ed no matter what you do), but also all future transactions in that particu= lar statechain. However, I should note there doesn't actually seem to b= e much to learn, because the history of each statechain is actually quite u= ninformative. The money just goes from one pseudonymous owner to the next.<= /div>

Of course you now have=C2=A0scheme that= changes the transitory key with each step, so I instead suggest you introd= uce a secondary "blinding key" to achieve what I described.
=

I'm not sure whether this can also apply to 2P-ECDS= A, but with Schnorr the statechain entity wouldn't even learn the addre= ss for the funding transaction, so it wouldn't be able to tell which UT= XO it controls by watching the blockchain. Ideally, this functionality woul= d be preserved to ensure the statechain entity can't be aware of the fu= nds it's holding.

Another thing to note is tha= t you won't know when a statechain has been pegged out, so pruning will= be impossible. You may wish to consider some kind of liveness rule where o= ne statechain transaction needs to be made per year. If they miss the deadl= ine, they're just forced on-chain, which is not terrible, in any case.<= /div>

Hope this helps!

Cheers,<= /div>
Ruben



On Fri, Jun 12, 2020 at = 9:23 PM Tom Trevethan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
Hello,

A statechain implementation and service = co-signs 'backup' (off-chain) transactions to transfer ownership of= a UTXO from one owner to the next. A suggested here https://medium.com/@RubenSomsen/statechains-= non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39 , this service (t= he statechain entity or SE) can be engineered to be 'blind' to the = transactions it is signing (i.e. it does not and cannot know the details of= the transactions it is signing) which can give significant privacy benefit= s. It would enable more private off-chain coin-swaps, and make collusion mo= re difficult.

The only downside of a blind SE is that it can no lon= ger enforce the rules governing the sequence of backup transactions it co-s= igns as owners can ask the SE to cosign any transaction. So each new owner = of a UTXO must receive, store and verify the full sequence of previous owne= r backup transactions to make sure that no previous owner has asked the SE = to sign a transaction that could be used to steal the UTXO. This may end up= making wallets more bloated and clunky, given that ownership of a UTXO cou= ld change hands thousands of times off-chain.

In the case of a mult= isig, and Schnorr signatures, existing blind Schnorr protocols could be use= d to implement a blind SE, however we are opting to use two-party ECDSA (be= cause there is no Schnorr yet, and in any case ECDSA will give a much bigge= r anonymity set). There is no current 2P ECDSA protocol that enables one of= the two signers to be completely blinded, but it seems that this would req= uire only minor modifications to an existing 2P ECDSA scheme (outlined here= https://github.com/commerceblock/mercury/blo= b/master/doc/blind_2p_ecdsa.md based on Lindell 2017 https://eprint.iacr.org/2017/5= 52 ).

Any comments on any of this gratefully received.

= Tom
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000cbfa6d05a812c781--