path: root/c2/70d86fb7499a5d11fda5f1bde41403fbffd731

Return-Path: <nicholas.w.farrow@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4012AC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Aug 2023 19:33:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 19CED40A5E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Aug 2023 19:33:42 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 19CED40A5E
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=KuGt1SYz
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.602
X-Spam-Level: 
X-Spam-Status: No, score=0.602 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 05EJzErwGrjM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Aug 2023 19:33:40 +0000 (UTC)
Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com
 [IPv6:2607:f8b0:4864:20::112f])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 87BFB40A5B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Aug 2023 19:33:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 87BFB40A5B
Received: by mail-yw1-x112f.google.com with SMTP id
 00721157ae682-594ebdf7bceso25352237b3.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Aug 2023 12:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1693251219; x=1693856019;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=FPPn9WDKnkHwGKgVhcaW4vE3H0GSx+jPlIj7HMJjMq0=;
 b=KuGt1SYzfYqvCwL7fRCIPUbRCeU2rD9B1rbP6R0kj32n0aymnNEP+4vo2zewlVncd6
 6AaKyWhzJ6XSfyZVXZZMbxQ2cwiTY2SWAWMzVeqwdWy6oPw+KRkNZB5ST1BTq5tuKTl8
 CuLJ+fUCb0sAAH8Vr3/3UUI+d+bdYwVhbbk5zn5tapd7VIf0DfTl/eV//mlpvbzFchYM
 ZDD51/WJu7ms9bql3d6ssKwqM03Q1FESp0bXXxzAJuSoeTXB8c1m4EmkO3aAjmfmh/ij
 GkJmyYOgbe5hogSlAhuM4S5kDE0Jcead2oP5dNGas/27BlXfYuRDjEyPrh742VsZi1yR
 lPoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1693251219; x=1693856019;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=FPPn9WDKnkHwGKgVhcaW4vE3H0GSx+jPlIj7HMJjMq0=;
 b=VkWLBlyXWjXPCoUqgIKsB1p7HOgn0igE5CtDX4/0g75Msw6xpykPztxzW2PcC9cMKI
 nSaRv7GQDyc6GthiZX4nFK7tXKfmc5f20p2QWTlTZL3+K0yTSHPxkPCedVJ9b44WYg6x
 JuxUX/WCQkV179nzg3K8uYaDyTAmsAfHS322hXYTyuSTAzAHXfsgW57aH0N8AbJHxrWt
 7CyqRHjRA1U3FEw6yxqR1tiZ+qjGjWJgTOPuI06sCpCxZ20GxCu7mABkcYsbWxwrvLty
 +GkYZTyJQiHpHEKiMqBsmvNmqZffhduUIAArYigsRz/Qe1YY7rlM0TZ0Jk9w8a1d8cye
 byYg==
X-Gm-Message-State: AOJu0Yyz2eH/VmcGgPDZftARoWelY/mZ/6bb4do5vuNXJaRyQU/PYtxT
 uj5PTqoxF9VAXlefWt77/4POYVZww7D9nJtOHvSCj6WhkVmx56a3
X-Google-Smtp-Source: AGHT+IGSPquDyrFndvkp5ccRVAOmKUF/rizTvyfgw3vjn4nS+p1wUz+nyUZ3CZGVNf7mVdjrGpWs2gWZL12YJdqFZB4=
X-Received: by 2002:a0d:d654:0:b0:576:9d2e:ef2b with SMTP id
 y81-20020a0dd654000000b005769d2eef2bmr24965176ywd.10.1693251219074; Mon, 28
 Aug 2023 12:33:39 -0700 (PDT)
MIME-Version: 1.0
From: Nick Farrow <nicholas.w.farrow@gmail.com>
Date: Mon, 28 Aug 2023 21:35:22 +0200
Message-ID: <CAO1LTYWK=3hft6_UwWiUrjRF-=Xp4asE7X1bRt6kksPqmth_MA@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="0000000000006db55f060400c5b0"
X-Mailman-Approved-At: Mon, 28 Aug 2023 19:41:51 +0000
Subject: [bitcoin-dev] Private Collaborative Custody with FROST
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: Mon, 28 Aug 2023 19:33:42 -0000

--0000000000006db55f060400c5b0
Content-Type: text/plain; charset="UTF-8"

Hello all,

Some thoughts on private collaborative custody services for Bitcoin.

With multiparty computation multisignatures like FROST [0], it is possible
to build a collaborative custodian service that is extremely private for
users.

Today's collaborative custodians can see your entire wallet history even if
you never require them to help sign a transaction, and they have full
liberty to censor any signature requests they deem inappropriate or are
coerced into censoring.

With FROST, a private collaborative custodian can hold a key to a multisig
while remaining unaware of the public key (and wallet) which they help
control. By hiding this public key, we solve the issue of existing
collaborative custodians who learn of all wallet transactions even if you
never use them.

Further, in the scenario that we do call upon a private collaborative
custodian to help sign a transaction, this transaction could be signed
**blindly**. Being blind to the transaction request itself and unknowing of
past onchain behavior, these custodians have no practical information to
enact censorship requests or non-cooperation. A stark contrast to today's
non-private collaborative custodians who could very easily be coerced into
not collaborating with users.


Enrolling a Private Collaborative Custodian

Each signer in a FROST multisig controls a point belonging to a joint
polynomial at some participant index.

Participants in an existing multisig can collaborate in an enrollment
protocol (Section 4.1.3 of [1], [2]) to securely generate a new point on
this shared polynomial and verifiably communicate it to a new participant,
in this case a collaborative custodian.

The newly enrolled custodian should end by sharing their own *public* point
so that all other parties can verify it does in-fact lie on the image of
the joint polynomial at their index (i.e. belong to the FROST key). (The
custodian themselves is unable to verify this, since we want to hide our
public key we do not share the image of our joint polynomial with them).


Blind Collaborative Signing

Once the collaborative custodian controls a point belonging to this FROST
key, we can now get their help to sign messages.

We believe it to be possible for a signing server to follow a scheme
similar to that of regular blind Schnorr signatures, while making the
produced signature compatible with the partial signatures from other FROST
participants.

We can achieve this compatibility by having the server sign under a single
nonce (not a binding nonce-pair like usual FROST), which is later blinded
by the nonce contributions from other signers. The challenge also can be
blinded with a factor that includes the necessary Lagrange coefficient so
that this partial signature correctly combines with the other FROST
signatures from the signing quorum.

As an overview, we give a 3rd party a secret share belonging to our FROST
key. When we need their help to sign something, we ask them to send us
(FROST coordinator) a public nonce, then we create a challenge for them to
sign with a blind Schnorr scheme. They sign this challenge, send it back,
and we then combine it with the other partial signatures from FROST to form
a complete Schnorr signature that is valid under the multisignature's
public key.

During this process the collaborative custodian has been unknowing of our
public key, and unknowing as to the contents of the challenge which we have
requested them to sign. The collaborative signer doesn't even need to know
that they are participating in FROST whatsoever.


Unknowing Signing Isn't So Scary

A server that signs arbitrary challenges sounds scary, but each secret
share is unique to a particular FROST key. The collaborative custodian
should protect this service well with some policy, e.g. user
authentication, perhaps involving cooperation from a number of other
parties (< threshold) within the multisig. This could help prevent parties
from abusing the service to "get another vote" towards the multisig
threshold.

Unknowingly collaborating in the signing of bitcoin transactions could be a
legal gray area, but it also places you in a realm of extreme privacy that
may alleviate you from regulatory and legal demands that are now impossible
for you to enforce (like seen with Mullvad VPN [3]). Censorship requests
made from past onchain behavior such as coinjoins becomes impossible, as
does the enforcement of address or UTXO blocklists.

By having the collaborative custodian sign under some form of blind
Schnorr, the server is not contributing any nonce with binding value for
the aggregate nonce. Naively this could open up some form of Drijvers
attacks which may allow for forgeries (see FROST paper [0]), but I think we
can eliminate given the right approach.

Blind Schnorr schemes also introduce attack vectors with
multiple concurrent signing requests [4], one idea to prevent this is to
disallow simultaneous signing operations at the collaborative custodian.
Even though Bitcoin transactions can require multiple signatures, these
signatures could be made sequentially with a rejection of any signature
request that uses anything other than the latest nonce.

Risks may differ depending on whether the service is emergency-only or for
whether it is frequently a participant in signing operations.

-------

Thanks to @LLFOURN for ongoing thoughts, awareness of enrollment protocols,
and observation that this can all fall back into a standard Schnorr
signature.

Curious for any thoughts, flaws or expansions upon this idea,

Gist of this post, which I may keep updated and add equations:
https://gist.github.com/nickfarrow/4be776782bce0c12cca523cbc203fb9d/

Nick

-------

References

* [0] FROST: https://eprint.iacr.org/2020/852.pdf
* [1] A Survey and Refinement of Repairable Threshold Schemes (Enrollment:
Section 4.3): https://eprint.iacr.org/2017/1155.pdf
* [2] Modifying FROST Threshold and Signers:
https://gist.github.com/nickfarrow/64c2e65191cde6a1a47bbd4572bf8cf8/
* [3] Mullvad VPN was subject to a search warrant. Customer data not
compromised:
https://mullvad.net/en/blog/2023/4/20/mullvad-vpn-was-subject-to-a-search-warrant-customer-data-not-compromised/
* [4] Blind Schnorr Signatures and Signed ElGamal Encryption in the
Algebraic Group Model: https://eprint.iacr.org/2019/877.pdf
* [5] FROST in secp256kfun:
https://docs.rs/schnorr_fun/latest/schnorr_fun/frost/index.html

--0000000000006db55f060400c5b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hello all,<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Some thoughts on private collaborative custod=
y services for Bitcoin. <br></div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">With
 multiparty computation multisignatures like FROST [0], it is possible=20
to build a collaborative custodian service that is extremely private for
 users.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Today&#39;s=
=20
collaborative custodians can see your entire wallet history even if you=20
never require them to help sign a transaction, and they have full=20
liberty to censor any signature requests they deem inappropriate or are=20
coerced into censoring.<br></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">With
 FROST, a private collaborative custodian can hold a key to a multisig=20
while remaining unaware of the public key (and wallet) which they help=20
control. By hiding this public key, we solve the issue of existing=20
collaborative custodians who learn of all wallet transactions even if=20
you never use them.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Further,
 in the scenario that we do call upon a private collaborative custodian=20
to help sign a transaction, this transaction could be signed=20
**blindly**. Being blind to the transaction request itself and unknowing
 of past onchain behavior, these custodians have no practical=20
information to enact censorship requests or non-cooperation. A stark=20
contrast to today&#39;s non-private collaborative custodians who could very=
=20
easily be coerced into not collaborating with users.<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Enrolling a Pr=
ivate Collaborative Custodian<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Each signer in a FROST multisig controls a point belonging to a j=
oint polynomial at some participant index.=C2=A0<br></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">Participants
 in an existing multisig can collaborate in an enrollment protocol=20
(Section 4.1.3 of [1], [2]) to securely generate a new point on this=20
shared polynomial and verifiably communicate it to a new participant, in
 this case a collaborative custodian.<br></div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">The
 newly enrolled custodian should end by sharing their own *public* point
 so that all other parties can verify it does in-fact lie on the image=20
of the joint polynomial at their index (i.e. belong to the FROST key).=20
(The custodian themselves is unable to verify this, since we want to=20
hide our public key we do not share the image of our joint polynomial=20
with them).<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Blind Collaborative Signing<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Once the collaborative custodian controls a poi=
nt belonging to this FROST key, we can now get their help to sign messages.=
<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">We
 believe it to be possible for a signing server to follow a scheme=20
similar to that of regular blind Schnorr signatures, while making the=20
produced signature compatible with the partial signatures from other=20
FROST participants.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
We
 can achieve this compatibility by having the server sign under a single
 nonce (not a binding nonce-pair like usual FROST), which is later=20
blinded by the nonce contributions from other signers. The challenge=20
also can be blinded with a factor that includes the necessary Lagrange=20
coefficient so that this partial signature correctly combines with the=20
other FROST signatures from the signing quorum.<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">As
 an overview, we give a 3rd party a secret share belonging to our FROST=20
key. When we need their help to sign something, we ask them to send us=20
(FROST coordinator) a public nonce, then we create a challenge for them=20
to sign with a blind Schnorr scheme. They sign this challenge, send it=20
back, and we then combine it with the other partial signatures from=20
FROST to form a complete Schnorr signature that is valid under the=20
multisignature&#39;s public key.<br></div><div dir=3D"auto"><br></div><div =
dir=3D"auto">During
 this process the collaborative custodian has been unknowing of our=20
public key, and unknowing as to the contents of the challenge which we=20
have requested them to sign. The collaborative signer doesn&#39;t even need=
=20
to know that they are participating in FROST whatsoever.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Unknowing=
 Signing Isn&#39;t So Scary<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">A
 server that signs arbitrary challenges sounds scary, but each secret=20
share is unique to a particular FROST key. The collaborative custodian=20
should protect this service well with some policy, e.g. user=20
authentication, perhaps involving cooperation from a number of other=20
parties  (&lt; threshold) within the multisig. This could help prevent=20
parties from abusing the service to &quot;get another vote&quot; towards th=
e=20
multisig threshold.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Unknowingly
 collaborating in the signing of bitcoin transactions could be a legal=20
gray area, but it also places you in a realm of extreme privacy that may
 alleviate you from regulatory and legal demands that are now impossible
 for you to enforce (like seen with Mullvad VPN [3]). Censorship=20
requests made from past onchain behavior such as coinjoins becomes=20
impossible, as does the enforcement of address or UTXO blocklists.<br></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">By
 having the collaborative custodian sign under some form of blind=20
Schnorr, the server is not contributing  any nonce with binding value=20
for the aggregate nonce. Naively this could open up some form of=20
Drijvers attacks which may allow for forgeries (see FROST paper [0]),=20
but I think we can eliminate given the right approach.<br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">Blind
 Schnorr schemes also introduce attack vectors with multiple=C2=A0concurren=
t=20
signing requests [4], one idea to prevent this is to disallow=20
simultaneous signing operations at the collaborative custodian. Even=20
though Bitcoin transactions can require multiple signatures, these=20
signatures could be made sequentially with a rejection of any signature=20
request that uses anything other than the latest nonce.<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Risks
 may differ depending on whether the service is emergency-only or for=20
whether it is frequently a participant in signing operations.<br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">-------<br></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Thanks
 to @LLFOURN for ongoing thoughts, awareness of enrollment protocols,=20
and observation that this can all fall back into a standard Schnorr=20
signature.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Curious f=
or any thoughts, flaws or expansions upon this idea,</div><div dir=3D"auto"=
><br></div><div>Gist of this post, which I may keep updated and add equatio=
ns:<br></div><div><a href=3D"https://gist.github.com/nickfarrow/4be776782bc=
e0c12cca523cbc203fb9d/" target=3D"_blank">https://gist.github.com/nickfarro=
w/4be776782bce0c12cca523cbc203fb9d/</a></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Nick<br></div><div><div dir=3D"auto"><br></div></div><div d=
ir=3D"auto">-------<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
References<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">* [0] FRO=
ST: <a href=3D"https://eprint.iacr.org/2020/852.pdf" target=3D"_blank">http=
s://eprint.iacr.org/2020/852.pdf</a><br></div><div dir=3D"auto">* [1] A Sur=
vey and Refinement of Repairable Threshold Schemes (Enrollment: Section 4.3=
): <a href=3D"https://eprint.iacr.org/2017/1155.pdf" target=3D"_blank">http=
s://eprint.iacr.org/2017/1155.pdf</a><br></div><div dir=3D"auto">* [2] Modi=
fying FROST Threshold and Signers: <a href=3D"https://gist.github.com/nickf=
arrow/64c2e65191cde6a1a47bbd4572bf8cf8/" target=3D"_blank">https://gist.git=
hub.com/nickfarrow/64c2e65191cde6a1a47bbd4572bf8cf8/</a><br></div><div dir=
=3D"auto">* [3] Mullvad VPN was subject to a search warrant. Customer data =
not compromised: <a href=3D"https://mullvad.net/en/blog/2023/4/20/mullvad-v=
pn-was-subject-to-a-search-warrant-customer-data-not-compromised/" target=
=3D"_blank">https://mullvad.net/en/blog/2023/4/20/mullvad-vpn-was-subject-t=
o-a-search-warrant-customer-data-not-compromised/</a><br></div><div dir=3D"=
auto">* [4] Blind Schnorr Signatures and Signed ElGamal Encryption in the A=
lgebraic Group Model: <a href=3D"https://eprint.iacr.org/2019/877.pdf" targ=
et=3D"_blank">https://eprint.iacr.org/2019/877.pdf</a><br></div><div dir=3D=
"auto">* [5] FROST in secp256kfun: <a href=3D"https://docs.rs/schnorr_fun/l=
atest/schnorr_fun/frost/index.html" target=3D"_blank">https://docs.rs/schno=
rr_fun/latest/schnorr_fun/frost/index.html</a></div></div></div>

--0000000000006db55f060400c5b0--