path: root/c4/44f5e93ef4a479f0cdc1db5b6a09eb7a938e4c

Return-Path: <tom@commerceblock.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5E6A3C016E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 14 Jun 2020 22:30:42 +0000 (UTC)
Received: by mail-ej1-f42.google.com with SMTP id q19so15387611eja.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAJvkSsewzYTAsm0tneu6-9MT0a-CcYvJBcSmhzCUkmAJ95=T3A@mail.gmail.com>
 <CAPv7TjZ_MBCmWZ5CnUk0G0MhHL65cpGyt_dMDONDTzJBHpVUQg@mail.gmail.com>
In-Reply-To: <CAPv7TjZ_MBCmWZ5CnUk0G0MhHL65cpGyt_dMDONDTzJBHpVUQg@mail.gmail.com>
From: Tom Trevethan <tom@commerceblock.com>
Date: Sun, 14 Jun 2020 23:24:47 +0100
Message-ID: <CAJvkSsdpf1QJkFETeLQXfTM8AutgthiwG2m=THJnHS+d5JcH+Q@mail.gmail.com>
To: Ruben Somsen <rsomsen@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000cbfa6d05a812c781"
X-Mailman-Approved-At: Sun, 14 Jun 2020 22:33:05 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: 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 <rsomsen@gmail.com> 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

<div dir=3D"ltr">Hi=C2=A0Ruben,<div><br></div><div>Thanks for the comments.=
=C2=A0</div><div><br></div><div>&gt; Users would have to validate the histo=
ry of the chain regardless, even if it wasn&#39;t blind, to verify whether =
the statechain entity hasn&#39;t been cheating, so the main difference woul=
d be in unblinding the data.<br></div><div><br></div><div>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 &#39;theft&#39; 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&#39;t know about.=C2=A0</div><div><br></div><div>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</div><div><br></div><div>Yes, the SE can store all of these transaction=
s, encrypted with the current owners key, to make the UX easier.=C2=A0</div=
><div><br></div><div>&gt; I&#39;m not sure whether this can also apply to 2=
P-ECDSA, but with Schnorr the statechain entity wouldn&#39;t even learn the=
 address for the funding transaction, so it wouldn&#39;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&#39;t be aware of =
the funds it&#39;s holding.</div><div><br></div><div>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</div><div><br></div><div>&gt; Another thing to note is=
 that you won&#39;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&#39;re just forced on-chain, which is not terrible, in any ca=
se.=C2=A0<br></div><div><br></div><div>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</div><div><br></div><div>Cheers,<=
/div><div><br></div><div>Tom</div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 12, 2020 at 9:35 PM Ruben Som=
sen &lt;<a href=3D"mailto:rsomsen@gmail.com">rsomsen@gmail.com</a>&gt; wrot=
e:<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"l=
tr">Hi Tom,<div><br></div><div>Blind signatures are certainly a nice featur=
e, great to see that you&#39;re considering it.</div><div><br></div><div>&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.</div><div=
><br></div><div>Users would have to validate the history of the chain regar=
dless, even if it wasn&#39;t blind, to verify whether the statechain entity=
 hasn&#39;t been cheating, so the main difference would be in unblinding th=
e data.</div><div><br></div><div>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&#39;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&#39;s not linkable i=
f it goes on-chain).</div><div><br></div><div>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&#39;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><div></div><div><br></div><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 &quot;blinding key&quot; to achieve what I described.</div>=
<div><br></div><div>I&#39;m not sure whether this can also apply to 2P-ECDS=
A, but with Schnorr the statechain entity wouldn&#39;t even learn the addre=
ss for the funding transaction, so it wouldn&#39;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&#39;t be aware of the fu=
nds it&#39;s holding.</div><div><br></div><div>Another thing to note is tha=
t you won&#39;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&#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, Jun 12, 2020 at =
9:23 PM Tom Trevethan via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr">Hello,<br><br>A statechain implementation and service =
co-signs &#39;backup&#39; (off-chain) transactions to transfer ownership of=
 a UTXO from one owner to the next. A suggested here <a href=3D"https://med=
ium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1=
ae4845a4a39" target=3D"_blank">https://medium.com/@RubenSomsen/statechains-=
non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39</a> , this service (t=
he statechain entity or SE) can be engineered to be &#39;blind&#39; 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. <br><br>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. <br><br>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=
 <a href=3D"https://github.com/commerceblock/mercury/blob/master/doc/blind_=
2p_ecdsa.md" target=3D"_blank">https://github.com/commerceblock/mercury/blo=
b/master/doc/blind_2p_ecdsa.md</a> based on Lindell 2017 <a href=3D"https:/=
/eprint.iacr.org/2017/552" target=3D"_blank">https://eprint.iacr.org/2017/5=
52</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>
</blockquote></div>

--000000000000cbfa6d05a812c781--