path: root/8e/f8f70e7e37953ec23957b06db0c9d713b629bc

Return-Path: <rsomsen@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 15BE1C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 12 Jun 2020 20:35:51 +0000 (UTC)
Received: by mail-ed1-f41.google.com with SMTP id d15so7324577edm.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAJvkSsewzYTAsm0tneu6-9MT0a-CcYvJBcSmhzCUkmAJ95=T3A@mail.gmail.com>
In-Reply-To: <CAJvkSsewzYTAsm0tneu6-9MT0a-CcYvJBcSmhzCUkmAJ95=T3A@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Fri, 12 Jun 2020 22:35:37 +0200
Message-ID: <CAPv7TjZ_MBCmWZ5CnUk0G0MhHL65cpGyt_dMDONDTzJBHpVUQg@mail.gmail.com>
To: Tom Trevethan <tom@commerceblock.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"ltr">Hi Tom,<div><br></div><div>Blind signatures are certainly =
a nice feature, great to see that you&#39;re considering it.</div><div><br>=
</div><div>&gt;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.</div><div><br></div><div>Users would have to validate the history of th=
e chain regardless, even if it wasn&#39;t blind, to verify whether the stat=
echain entity hasn&#39;t been cheating, so the main difference would be in =
unblinding the data.</div><div><br></div><div>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&#39;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&#39;s n=
ot linkable if it goes on-chain).</div><div><br></div><div>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&#39;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.</div><div></div><div><br></div><div>Of course you now have=C2=
=A0scheme that changes the transitory key with each step, so I instead sugg=
est you introduce a secondary &quot;blinding key&quot; to achieve what I de=
scribed.</div><div><br></div><div>I&#39;m not sure whether this can also ap=
ply to 2P-ECDSA, but with Schnorr the statechain entity wouldn&#39;t even l=
earn the address for the funding transaction, so it wouldn&#39;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&#39;t be a=
ware of the funds it&#39;s holding.</div><div><br></div><div>Another thing =
to note is that you won&#39;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&#39;re just forced on-chain, which is not terrible,=
 in any case.</div><div><br></div><div>Hope this helps!</div><div><br></div=
><div>Cheers,</div><div>Ruben</div><div><br></div><div><br></div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Ju=
n 12, 2020 at 9:23 PM Tom Trevethan via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
<div dir=3D"ltr">Hello,<br><br>A statechain implementation and service co-s=
igns &#39;backup&#39; (off-chain) transactions to transfer ownership of a U=
TXO from one owner to the next. A suggested here <a href=3D"https://medium.=
com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae48=
45a4a39" target=3D"_blank">https://medium.com/@RubenSomsen/statechains-non-=
custodial-off-chain-bitcoin-transfer-1ae4845a4a39</a> , this service (the s=
tatechain entity or SE) can be engineered to be &#39;blind&#39; 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. <br><br>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. <br><br>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 <a =
href=3D"https://github.com/commerceblock/mercury/blob/master/doc/blind_2p_e=
cdsa.md" target=3D"_blank">https://github.com/commerceblock/mercury/blob/ma=
ster/doc/blind_2p_ecdsa.md</a> based on Lindell 2017 <a href=3D"https://epr=
int.iacr.org/2017/552" target=3D"_blank">https://eprint.iacr.org/2017/552</=
a> ). <br><br>Any comments on any of this gratefully received. <br><br>Tom<=
br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c7bc8105a7e9057e--