path: root/88/407797a8351782e0a0068dd4a4e8f3fa991ef8

Return-Path: <christophera@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 23E66C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 16 Jan 2024 08:19:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id E06F76104E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 16 Jan 2024 08:19:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org E06F76104E
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail-com.20230601.gappssmtp.com
 header.i=@gmail-com.20230601.gappssmtp.com header.a=rsa-sha256
 header.s=20230601 header.b=y5C4NH/p
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=no 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 wRpYucPXZDVv
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 16 Jan 2024 08:19:05 +0000 (UTC)
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com
 [IPv6:2607:f8b0:4864:20::1136])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 01C0761031
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 16 Jan 2024 08:19:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 01C0761031
Received: by mail-yw1-x1136.google.com with SMTP id
 00721157ae682-5ff45dc44d1so8371917b3.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 16 Jan 2024 00:19:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1705393143; x=1705997943;
 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=wU63NvJU1zyW2HThYpmV5o9+wQv4PrTZ1xFWldKygc8=;
 b=y5C4NH/pxJIzD1KFZ/Qr9y5MgWk42HXJxd8lV5rxFd7EJ//Y31ci8+YxXaKSGTE0nG
 +x5l4aRZFTyWkiaxJB7qoUiLpDEJon3jgNA1xNT7wp5meIIyFdlYMYXlx1G3wllfjeKX
 I/77BmKpKD2rLypEFpON9/Bk0k1Q8byF22egXVrAFME/AZihkLMxDGFqUQjZvxvB0Aax
 b/VohgT5nPIIDbZsWI4LN5A5CZErndquGO1Y+qPd6hcH3szqacHGp+HWYBTnN6ESfZt4
 cenqp/HcQrXq1ZZFJQugdkmo/Sn2eob+5Sjmjwauw1E5sbQ9Md1RSy+74V2TaNhgwK+q
 OJXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1705393143; x=1705997943;
 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=wU63NvJU1zyW2HThYpmV5o9+wQv4PrTZ1xFWldKygc8=;
 b=ALv9J/tB+aE90N6+kXzKlfghfGR+EyFDjZOAsFKNtlSl9FnmM8IQwRIb3Wnw85CtHx
 HIfSE+m4M9Nm1cuK69+muiWZdPXpBKYRXbA7qyHfYGH1kKcz25TScDHmLrPU6cnEKDks
 gpVEvDuvSUjysd/yyak2SZFT5k49dvPqeTA3NB1nAAZj/Jgpxlz5O+Y+ZAcY+tgYOnwG
 TdsyJR7dMvhUASGfB7kSWGXD0dgp4h3THC1cgoEOgljQHzPf4+s/xFYlJoBvTLV6sBD8
 66sXIOnDRiqLiELqLApYuVGc3yVsfbQJX1yTXHaEjogDeHco9yHpOihWsNB5HQQGuZp6
 F61w==
X-Gm-Message-State: AOJu0Yy7KY82phDtWXS1icJO+EAz9ANUbGrHNhHPDo6eK6GyRuw9oz77
 LfVeJch3VFilcMWP8QBpZVqALM0NvYDCUkuLnts=
X-Google-Smtp-Source: AGHT+IGA8cz/O56p0A20YQdH0BvCLpDEVu6aX/pfF9RLRulC2p1xhAz8aiPxMocnadXRmNybjQChYRe0UjMAdLLhmiA=
X-Received: by 2002:a05:6902:2687:b0:dbe:9c84:691 with SMTP id
 dx7-20020a056902268700b00dbe9c840691mr3620373ybb.62.1705393143456; Tue, 16
 Jan 2024 00:19:03 -0800 (PST)
MIME-Version: 1.0
References: <5d299fc4-8809-4f32-a9b8-17e353d6ff30@achow101.com>
In-Reply-To: <5d299fc4-8809-4f32-a9b8-17e353d6ff30@achow101.com>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Tue, 16 Jan 2024 00:18:26 -0800
Message-ID: <CACrqygDY0p-trbHGyhg0_uyViyryyJqO-CkOS6+tknTUG05Wew@mail.gmail.com>
To: Ava Chow <lists@achow101.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000084a5d0060f0bc8ba"
X-Mailman-Approved-At: Tue, 16 Jan 2024 10:52:42 +0000
Cc: bitcoindev@groups.io
Subject: Re: [bitcoin-dev] MuSig2 derivation, descriptor, and PSBT field BIPs
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: Tue, 16 Jan 2024 08:19:06 -0000

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

On Mon, Jan 15, 2024 at 4:28=E2=80=AFPM Ava Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I've also made a change to the PSBT fields BIP where the aggregate
> pubkey is included as a plain pubkey rather than as xonly. I think this
> change is necessary for to make discovering derived keys easier. The
> derivation paths for derived keys contain the fingerprint of the parent
> (i.e. the aggregate pubkey) and the fingerprint requires the evenness
> bit to be serialized. So the aggregate pubkey in the PSBT fields need to
> contain that evenness information in order for something looking at only
> the PSBT to be able to determine whether a key is derived from an
> aggregate pubkey also specified in the PSBT.
>

The topic of some challenges in using x-only pubkeys with FROST recently
came up in a conversation that I didn't completely understand. It sounds
like it may be related to this issue with MuSig2.

What are the gotcha's in x-only keys with these multisig protocols? Can you
explain a little more? Any other particular things do we need to be careful
about with x-only pubkeys? I had mistakenly assumed the technique was just
a useful trick, not that it might cause some problems in higher level
protocols.

Thanks!

-- Christopher Allen

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

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jan 15, 2024 at 4:28=E2=80=AFPM A=
va Chow via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><di=
v class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-=
color:rgb(204,204,204);padding-left:1ex">I&#39;ve also made a change to the=
 PSBT fields BIP where the aggregate <br>
pubkey is included as a plain pubkey rather than as xonly. I think this <br=
>
change is necessary for to make discovering derived keys easier. The <br>
derivation paths for derived keys contain the fingerprint of the parent <br=
>
(i.e. the aggregate pubkey) and the fingerprint requires the evenness <br>
bit to be serialized. So the aggregate pubkey in the PSBT fields need to <b=
r>
contain that evenness information in order for something looking at only <b=
r>
the PSBT to be able to determine whether a key is derived from an <br>
aggregate pubkey also specified in the PSBT.<br></blockquote><div><br></div=
><div>The topic of some challenges in using x-only pubkeys with FROST recen=
tly came up in a conversation that I didn&#39;t completely understand. It s=
ounds like it may be related to this issue with MuSig2.</div><div><br></div=
><div>What are the=C2=A0gotcha&#39;s=C2=A0in x-only keys with these multisi=
g protocols? Can you explain a little more? Any other particular things do =
we=C2=A0need to be careful about with x-only pubkeys? I had mistakenly assu=
med the=C2=A0technique was just a useful trick, not that it might cause som=
e problems in higher level protocols.<br></div><div><br></div><div>Thanks!<=
/div><div><br></div><div>-- Christopher Allen</div><div><br></div></div></d=
iv>

--00000000000084a5d0060f0bc8ba--