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 15BE1C016F for ; Fri, 12 Jun 2020 20:35:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 049C68882D for ; Fri, 12 Jun 2020 20:35:53 +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 oZ2TtT38f7jj for ; Fri, 12 Jun 2020 20:35:51 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by whitealder.osuosl.org (Postfix) with ESMTPS id 7622F88767 for ; Fri, 12 Jun 2020 20:35:51 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id d15so7324577edm.10 for ; Fri, 12 Jun 2020 13:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1vXu2mu+KCr1JeJJMF4wi1e6Y/wgA1p22mXilMWp0N4=; b=cn59d+4lIRCOkm8vu0iNoal6x5ipSTQQFPFb+/XShX62i4MdJvjJv/mxyMaO6gqSw/ UKNlictbS4Y/TrSBG0xwSDS3PRKBVXjkZjQNQpAmhtd3hpncK073rKsTRb6kMzqY94bd YpeeR9+UQc8NDDyal1JiWhDAOHY9pKwoWn4sF1DH8wRsN07jqAv2UklEc254vblSmJYq 2naHzefU5Wtaa0GCD9JYm/7cawFkHgrZku41knP6cNgMYrBtDjvMnhgyiRp/vJbyO/iT FzAj72AcOnrclO9TDMFoaBeiM+tLS9RJMy7dSEiAVLQUimwk5G90tyCsKtIe0pMr5PPi njvg== 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=1vXu2mu+KCr1JeJJMF4wi1e6Y/wgA1p22mXilMWp0N4=; b=FvcGZaPCWzIxY3anEbvO+KYM9SBWk7xVnQg3A3JLls+dgHQeFvq/ej0gURnwGLx3GP /TdF9sLiWvl7u1N3YXGxkx/EV5P+DfiPh0EyXK63oP6PkpnJAqYLAXQNBcZ4SUM2KOp9 Qw8OACx+bQxL/KZ4kR5q8eiZAYRZvik7IzG+dI2C2riujQyxSYLdb/WhG3HNXd0HPGQR xYRzKfGWfGzG8atozvi1IqdwLbwG0kXVLloEjLwrDiJW8flkpzXVIwKCODEgTsochuzp YCRExjjjodQSRdWNH5VfMyOK443sh/1/T+OlXAe4UtgohWO+UlIHoyeySQmFQTIxDwd4 e8Gw== X-Gm-Message-State: AOAM532qWQoaHNMAnehsngnKBp7mKgbHd5fA6bi09C7eM/sDQzFoVFcP aPcuO+tNb0Kp2ndz7XwCL7c1d379u+GazHCYVJYaHZNFGe0= X-Google-Smtp-Source: ABdhPJxKwUTtl6TkAd0WVgnlNiDqhg6Ov4/six0/9Gdd9s58N37CROdmmGJvZiUGeVQraHZHTxN4FT5CpOPMNAN9aBU= X-Received: by 2002:aa7:d9d6:: with SMTP id v22mr13963509eds.66.1591994149746; Fri, 12 Jun 2020 13:35:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ruben Somsen Date: Fri, 12 Jun 2020 22:35:37 +0200 Message-ID: To: Tom Trevethan , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000c7bc8105a7e9057e" X-Mailman-Approved-At: Fri, 12 Jun 2020 20:44:05 +0000 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: Fri, 12 Jun 2020 20:35:53 -0000 --000000000000c7bc8105a7e9057e Content-Type: text/plain; charset="UTF-8" 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 > --000000000000c7bc8105a7e9057e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 t= he 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 t= o steal the UTXO. This may end up making wallets more bloated and clunky, g= iven that ownership of a UTXO could change hands thousands of times off-cha= in.

Users would have to validate the history of th= e chain regardless, even if it wasn't blind, to verify whether the stat= echain 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 se= rve blind signatures, and any new owner would download and unblind/verify t= hem using the transitory key (no extensive peer-to-peer transfer needed). I= t's possible to make the off-chain transactions themselves deterministi= c, 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 statechai= n, tweaked with the transitory key via Diffie-Hellman (to ensure it's n= ot linkable if it goes on-chain).

The general down= side of this method is that all transactions are exposed to anyone who lear= ns the transitory key -- not just for the current transactions (which can a= lways be leaked no matter what you do), but also all future transactions in= that particular statechain. However, I should note there doesn't actua= lly seem to be much to learn, because the history of each statechain is act= ually quite uninformative. The money just goes from one pseudonymous owner = to the next.

Of course you now have=C2= =A0scheme that changes the transitory key with each step, so I instead sugg= est you introduce a secondary "blinding key" to achieve what I de= scribed.

I'm not sure whether this can also ap= ply to 2P-ECDSA, but with Schnorr the statechain entity wouldn't even l= earn the address for the funding transaction, so it wouldn't be able to= tell which UTXO it controls by watching the blockchain. Ideally, this func= tionality would be preserved to ensure the statechain entity can't be a= ware of the funds it's holding.

Another thing = to note is that you won't know when a statechain has been pegged out, s= o pruning will be impossible. You may wish to consider some kind of livenes= s 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, Ju= n 12, 2020 at 9:23 PM Tom Trevethan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org= > wrote:
=
Hello,

A statechain implementation and service co-s= igns 'backup' (off-chain) transactions to transfer ownership of a U= TXO from one owner to the next. A suggested here https://medium.com/@RubenSomsen/statechains-non-= custodial-off-chain-bitcoin-transfer-1ae4845a4a39 , this service (the s= tatechain entity or SE) can be engineered to be 'blind' to the tran= sactions 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. I= t would enable more private off-chain coin-swaps, and make collusion more d= ifficult.

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 ba= ckup transactions to make sure that no previous owner has asked the SE to s= ign a transaction that could be used to steal the UTXO. This may end up mak= ing wallets more bloated and clunky, given that ownership of a UTXO could c= hange 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 (becaus= e there is no Schnorr yet, and in any case ECDSA will give a much bigger an= onymity 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/ma= ster/doc/blind_2p_ecdsa.md based on Lindell 2017 https://eprint.iacr.org/2017/552 ).

Any comments on any of this gratefully received.

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