path: root/83/9d440424d4a189505257e499621b4f37c5af2b

Return-Path: <nicholas.w.farrow@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 92BB8C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Aug 2023 12:14:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5F3B461039
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Aug 2023 12:14:40 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5F3B461039
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20221208 header.b=fQeWCYxw
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, 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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id A7KU8a-OGBdG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Aug 2023 12:14:38 +0000 (UTC)
Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com
 [IPv6:2607:f8b0:4864:20::b31])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5C0596101B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Aug 2023 12:14:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5C0596101B
Received: by mail-yb1-xb31.google.com with SMTP id
 3f1490d57ef6-d7b91422da8so1163690276.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 30 Aug 2023 05:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20221208; t=1693397677; x=1694002477;
 darn=lists.linuxfoundation.org; 
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=X+efL7XqdBrV9rPL8Vrlq61TEheASMGKWOHnGaChJqQ=;
 b=fQeWCYxwLU7AUQAqjE0zI4zt+Qkbme+RSrQ6vT5Wa0ALhDXQC0tumLTE4T3v2uh6fU
 wUsvuiE77KyXnY2qMtrbhQy0egl1AUDdOoTkNNsfwoBuxcTckweZpzHybTg48x8ox4GM
 tfy6bvVz9dkCNy2Vn4dBGVW8o8GjQlfycAZV5/034kHytPbNy9U46h7B4pr5XblQeZRc
 Lf9rGyysQ5lyLo5copfNa4p+2K42851r/pntQCJQufqZRoWlonGdTRiJOVSw7o27VqBI
 2A+HLbbkBdjmaSWM/ZvXJ3mTwY1ThJxyPy6i3Wd7pggbOn8Hfw5hKryI6UEtcS/nsqHG
 QTyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1693397677; x=1694002477;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=X+efL7XqdBrV9rPL8Vrlq61TEheASMGKWOHnGaChJqQ=;
 b=R+WDprCb/zZ1vxgXDyfT4488nCB9NsHAZjXYPcq4JSkV9hGTgbE3exI7lgkaIdgt6k
 487f+Tizq2QhDeylfiYvE3LoNfwuOIKFcEm+DJX/rpsJOEKOtsGSo2UDpDe6+AT/2Sc+
 gEv2FMOYl57YTO5VyH80fpTojCmNSQB9vQMN3w+3/WsHdO1LEZIQAHETpAIj46p8plwO
 nT/3qybV237SFXESnXAShIYaCzjx9dg5H+YB21MKz8WQccpaNdnF/h8++D2CxHMib2cM
 KpvOAkw6kb+kA34CrmIqzzE+VOKCbDi9Qs9X4DnKu8ytBaEbqsefcKQpUtkCNamPOLrH
 fZkg==
X-Gm-Message-State: AOJu0YzARaLphz1H5UF7mHCfHfOLQZITcvIxO9atsmvyS8Cw6rfnGiAr
 Yyrvneq7U4qJCILtXMxqtl69jKb0Iqwclq11sb54p4bQnsC/WYVwMfU=
X-Google-Smtp-Source: AGHT+IFEkdBuL/AtFQwKyJ+wzVKw4dJgreGuTTB0d8wypoOGs/mz+n2SbmkDEj5weCe3gSUJLSKAcDooR8zEp7xq2qg=
X-Received: by 2002:a25:34c3:0:b0:d47:ba3c:a66c with SMTP id
 b186-20020a2534c3000000b00d47ba3ca66cmr1823144yba.19.1693397677033; Wed, 30
 Aug 2023 05:14:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAO1LTYWK=3hft6_UwWiUrjRF-=Xp4asE7X1bRt6kksPqmth_MA@mail.gmail.com>
 <NBWGXNsLa372udskPbAr7hS9ba_VcKY1Aq4C4QB8Mf0EFc2N8zDD8H6OwOO5_8n-ESgdsQyDQIK0QFVHhCUe0Uc2oFpZ-zv0P7PirCbS5T0=@protonmail.com>
In-Reply-To: <NBWGXNsLa372udskPbAr7hS9ba_VcKY1Aq4C4QB8Mf0EFc2N8zDD8H6OwOO5_8n-ESgdsQyDQIK0QFVHhCUe0Uc2oFpZ-zv0P7PirCbS5T0=@protonmail.com>
From: Nick Farrow <nicholas.w.farrow@gmail.com>
Date: Wed, 30 Aug 2023 14:16:28 +0200
Message-ID: <CAO1LTYX33q979c2QV+4JFJBTZAGZooWVprs6gUNvDUFFjJxY=A@mail.gmail.com>
To: rot13maxi <rot13maxi@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000000ce0f060422dfe0"
X-Mailman-Approved-At: Wed, 30 Aug 2023 15:15:56 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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: Wed, 30 Aug 2023 12:14:40 -0000

--00000000000000ce0f060422dfe0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hey Rijndael,

Here are some rough ideas for a draft scheme that I think will help explain
this better.

We begin by taking a single public nonce `D` from the collaborative signing
server to form a nonce pair for FROST `(D, 0)`.

This is then used to build the aggregate FROST nonce `R` which the signer
set `S` is going to sign under:
```
R_i =3D D_i * (E_i)^=CF=81_i
R =3D Product[R_i, i in S]
```
This aggregate FROST nonce is now blinded by the contributions from other
signers (collaborative custodian doesn't know the other participant's
nonces)

Now with our FROST public key `X`, this aggregate nonce `R`, and a message
`m` corresponding to our planned Bitcoin transaction input, we calculate
the corresponding challenge `c` we need signed.

```
c =3D H(R || X || m)
```

Like regular blind schnorr, we also want to blind this challenge so that
the signing server cannot recognize it onchain.

The challenge can be blinded with a factor that includes the necessary
Lagrange coefficient so that the partial signature correctly combines with
the other FROST signatures from the signing quorum. Using their participant
index `i` and the set of signing parties `S`
```
c' =3D =CE=BB_i_S * c
```

Note: if this `=CE=BB_i_S` is the sole challenge blinding factor, it is
important that we give the collaborative custodian a non-trivial (random)
participant index such that they cannot lookup onchain challenges
multiplied by common Lagrange coefficients to match the challenge they
signed.

Now we have formed the challenge, we get the server to sign under the
regular Schnorr singing equation using their FROST secret share `s_i` and
nonce secret `d_i`:

```
z_i =3D d_i + (e_i * =CF=81_i) + =CE=BB_i * s_i * c # FROST signing equatio=
n
=3D d_i + (0 * =CF=81_i) + s_i * c' # Since we're signing for binonce commi=
tment
(D, 0)
=3D d_i + s_i * c'
```

Once we have this partial signature, we get the other `t-1` participants to
undertake FROST signing. We take the collaborative custodian's signature
and combine it with the other partial signatures to form a complete Schnorr
signature for the message valid under the group's FROST key.

Again, security needs a serious assessment. Especially because we're
dropping the binding factor in the collaborative custodian's nonce. It's
likely crucial that collaborative signing sessions are not done in parallel
and transaction inputs are signed one at a time.

Hope that explains the ideas for blinding and FROST compatibility better!

Nick

On Tue, Aug 29, 2023 at 1:52=E2=80=AFPM rot13maxi <rot13maxi@protonmail.com=
> wrote:

> Good morning Nick,
>
> Love the direction of this.
>
> > 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.
>
> Can you say more about this? It sounds like the blinding is happening
> post-signing? Or is it happening during the normal nonce commitment tradi=
ng?
>
> Rijndael
>
> On Mon, Aug 28, 2023 at 3:35 PM, Nick Farrow via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org
> <On+Mon,+Aug+28,+2023+at+3:35+PM,+Nick+Farrow+via+bitcoin-dev+%3C%3Ca+hre=
f=3D>>
> wrote:
>
> Hello all,
>
> Some thoughts on private collaborative custody services for Bitcoin.
>
> With multiparty computation multisignatures like FROST [0], it is possibl=
e
> 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 multisi=
g
> 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 int=
o
> 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 ima=
ge
> of the joint polynomial at their index (i.e. belong to the FROST key). (T=
he
> 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 FROS=
T
> participants.
>
> We can achieve this compatibility by having the server sign under a singl=
e
> 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 t=
o
> 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 fo=
rm
> 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 ha=
ve
> requested them to sign. The collaborative signer doesn't even need to kno=
w
> 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 partie=
s
> 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]). Censorshi=
p
> 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 thou=
gh
> 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 fo=
r
> 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
>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hey Rijndael,<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Here are some rough ideas for a  draft sch=
eme that I think will help explain this better.<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">We begin by taking  a single public nonce `D` f=
rom the collaborative signing server to form a nonce pair for FROST `(D, 0)=
`.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">This is then used=
 to build the aggregate FROST nonce `R` which the signer set `S` is going t=
o sign under:<br></div><div dir=3D"auto">```<br></div><div dir=3D"auto">R_i=
 =3D D_i * (E_i)^=CF=81_i<br></div><div dir=3D"auto">R =3D Product[R_i, i i=
n S]=C2=A0<br></div><div dir=3D"auto">```<br></div><div dir=3D"auto">This a=
ggregate FROST nonce is now blinded by the contributions from other signers=
 (collaborative custodian doesn&#39;t know the other participant&#39;s nonc=
es)<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Now with our FRO=
ST public key `X`, this aggregate nonce `R`, and a message `m` correspondin=
g to our planned Bitcoin transaction input, we calculate the corresponding =
challenge `c` we need signed.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">```<br></div><div dir=3D"auto">c =3D H(R || X || m)<br></div><div=
 dir=3D"auto">```<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Li=
ke regular blind schnorr, we also want to blind this challenge so that the =
signing server cannot recognize it onchain.<br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">The challenge can be blinded with a factor that inc=
ludes the necessary Lagrange coefficient so that the partial signature corr=
ectly combines with the other FROST signatures from the signing quorum. Usi=
ng their participant index `i` and the set of signing parties `S`<br></div>=
<div dir=3D"auto">```<br></div><div dir=3D"auto">c&#39; =3D =CE=BB_i_S * c<=
br></div><div dir=3D"auto">```<br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">Note: if this `=CE=BB_i_S` is the sole challenge blinding factor=
, it is important that we give the collaborative custodian a non-trivial (r=
andom) participant index such that they cannot lookup onchain challenges mu=
ltiplied by common Lagrange coefficients to match the challenge they signed=
.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Now we have formed=
 the challenge, we get the server to sign under the regular Schnorr singing=
 equation using their FROST secret share `s_i` and nonce secret `d_i`:<br><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">```<br></div><div dir=3D=
"auto">z_i 	=3D d_i + (e_i * =CF=81_i) + =CE=BB_i * s_i * c	# FROST signing=
 equation<br></div><div dir=3D"auto">=3D d_i + (0 * =CF=81_i) + s_i * c&#39=
;		# Since we&#39;re signing for binonce commitment (D, 0)<br></div><div di=
r=3D"auto">=3D d_i + s_i * c&#39;<br></div><div dir=3D"auto">```<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Once we have this partial sign=
ature, we get the other `t-1` participants to undertake FROST signing. We t=
ake the collaborative custodian&#39;s signature and combine it with the oth=
er partial signatures to form a complete Schnorr signature for the message =
valid under the group&#39;s FROST key.<br></div><div dir=3D"auto"><br></div=
><div dir=3D"auto">Again, security needs a serious assessment. Especially b=
ecause we&#39;re dropping the binding factor in the collaborative custodian=
&#39;s nonce. It&#39;s likely crucial that collaborative signing sessions a=
re not done in parallel and transaction inputs are signed one at a time.<br=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">Hope that explains the=
 ideas for blinding and FROST compatibility  better!<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Nick<br></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Aug 29, 2023 at 1:52=
=E2=80=AFPM rot13maxi &lt;<a href=3D"mailto:rot13maxi@protonmail.com">rot13=
maxi@protonmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div>   <div dir=3D"auto">Good morning Nick,</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Love the direction of this.=C2=A0</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt;=C2=A0<span style=3D"=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
white-space:normal;word-spacing:0px;text-decoration:none;float:none;display=
:inline">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.<span dir=3D"auto">=
=C2=A0</span></span></div><div dir=3D"auto"><span style=3D"letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;text-decoration:none;float:none;display:inline" dir=3D"=
auto"><span dir=3D"auto"><br></span></span></div>Can you say more about thi=
s? It sounds like the blinding is happening post-signing? Or is it happenin=
g during the normal nonce commitment trading?<div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Rijndael=C2=A0<u></u><u></u><br> <div id=3D"m_-445489479681=
3609752protonmail_mobile_signature_block"><div dir=3D"auto"><br></div></div=
>On Mon, Aug 28, 2023 at 3:35 PM, Nick Farrow via bitcoin-dev &lt;<a href=
=3D"mailto:On+Mon,+Aug+28,+2023+at+3:35+PM,+Nick+Farrow+via+bitcoin-dev+%3C=
%3Ca+href=3D" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t; wrote:<blockquote type=3D"cite">  <div dir=3D"ltr"><div dir=3D"ltr"><div=
>Hello all,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Some tho=
ughts on private collaborative custody services for Bitcoin. <br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">With
 multiparty computation multisignatures like FROST [0], it is possible
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
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.<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
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.<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
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&#39;s non-private collaborative custodians who could very
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. <br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">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.<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
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).<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
similar to that of regular blind Schnorr signatures, while making the
produced signature compatible with the partial signatures from other
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
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.<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
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&#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
public key, and unknowing as to the contents of the challenge which we
have requested them to sign. The collaborative signer doesn&#39;t even need
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
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  (&lt; threshold) within the multisig. This could help prevent
parties from abusing the service to &quot;get another vote&quot; towards th=
e
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
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.<br></div=
><div dir=3D"auto"><br></div><div dir=3D"auto">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.<br></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">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.<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
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,
and observation that this can all fall back into a standard Schnorr
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>
</blockquote></div></div></blockquote></div></div>

--00000000000000ce0f060422dfe0--