From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23E66C0037 for ; 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 ; 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 ; 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 ; 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 ; 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 Date: Tue, 16 Jan 2024 00:18:26 -0800 Message-ID: To: Ava Chow , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
On Mon, Jan 15, 2024 at 4:28=E2=80=AFPM A= va 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 recen= tly came up in a conversation that I didn't completely understand. It s= ounds like it may be related to this issue with MuSig2.

What are the=C2=A0gotcha'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.

Thanks!<= /div>

-- Christopher Allen

--00000000000084a5d0060f0bc8ba--