Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B65C3C000E for ; Thu, 8 Jul 2021 20:06:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A407841617 for ; Thu, 8 Jul 2021 20:06:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rygUrW0cW_Th for ; Thu, 8 Jul 2021 20:06:24 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id 6BE8641616 for ; Thu, 8 Jul 2021 20:06:23 +0000 (UTC) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 168K6J5c021156 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 8 Jul 2021 16:06:20 -0400 Received: by mail-il1-f177.google.com with SMTP id g3so7883778ilj.7 for ; Thu, 08 Jul 2021 13:06:20 -0700 (PDT) X-Gm-Message-State: AOAM531pxT3avMv45UyuOODOWU3Zsw3SI94qHiUaQMpabjTLfLhnofBC +vhIYUFMPCsfTDUPxVaBiCCyzjADYgFaQ4KupNE= X-Google-Smtp-Source: ABdhPJyAu0fS7LLp3IvCPbLSq5pv5mcZCgL1fB4QIrBfc9JXxHwVXG7/QKUWcnU3ABZOJK8CH/agTy65CkLLwtntQVU= X-Received: by 2002:a92:d652:: with SMTP id x18mr23071140ilp.90.1625774779467; Thu, 08 Jul 2021 13:06:19 -0700 (PDT) MIME-Version: 1.0 References: <795f917b-3883-1827-f39b-35123b500f36@achow101.com> <912b172b-009d-9d5f-32d8-189e7fbe7646@achow101.com> In-Reply-To: From: Jeremy Date: Thu, 8 Jul 2021 13:06:08 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Salvatore Ingala , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000370fe905c6a2305d" Subject: Re: [bitcoin-dev] Taproot Fields for PSBT 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: Thu, 08 Jul 2021 20:06:25 -0000 --000000000000370fe905c6a2305d Content-Type: text/plain; charset="UTF-8" Suggestion: It should be allowed that different keys can specify different sighash flags. As an example, if chaperone signatures were desired with anyprevout, it would be required to specify that the anyprevout key sign with APO and the chaperone sign with ALL. As another example, Sapio emulator oracles sign with SIGHASH_ALL whereas other signatories might be instructed to sign with a different flag. The current sighashtype key is per-input: - If a sighash type is provided, the signer must check that the sighash is acceptable. If unacceptable, they must fail. - If a sighash type is not provided, the signer should sign using SIGHASH_ALL, but may use any sighash type they wish. So a new per-key mapping can be added safely. I have no strong opinions on the format for said per-key sighash hints. Why do this now? Well, I requested it when spec'ing V2 as well, but it would be nice to get it spec'd and implemented. -- @JeremyRubin On Mon, Jun 28, 2021 at 1:32 PM Salvatore Ingala via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Andrew, > > Thanks for the clarification, I was indeed reading it under the mistaken > assumption that only one leaf would be added to the PSBT. > > En passant, for the less experienced readers, it might be helpful if the > key types that are possibly present multiple times (with different keydata) > were somehow labeled in the tables. > > Best, > Salvatore Ingala > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000370fe905c6a2305d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Suggestion:

It shou= ld be allowed that different keys can specify different sighash flags.

As an example, if chaperone signatures were desired with anyprevout, it w= ould be required to specify that the anyprevout key sign with APO and the c= haperone sign with ALL. As another example, Sapio emulator oracles sign wit= h SIGHASH_ALL whereas other signatories might be instructed to sign with a = different flag.

The current sighashtype key is per-input:
- If a sigh= ash type is provided, the signer must check that the sighash is acceptable.= If unacceptable, they must fail.
- If a sighash type is not provided, t= he signer should sign using SIGHASH_ALL, but may use any sighash type they = wish.

So a new per-key mapping can be added safely.

I have no strong opinions o= n the format for said per-key sighash hints.

Why do this now? Well, I request= ed it when spec'ing V2 as well, but it would be nice to get it spec'= ;d and implemented.


--
<= div dir=3D"ltr">@JeremyRubin


On Mon, Jun 28, 2021 at 1:32 PM Salvatore I= ngala via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi Andrew,

Thank= s for the clarification, I was indeed reading it under the mistaken assumpt= ion that only one leaf would be added to the PSBT.

En passant, for the less experienced readers, it might be helpful if the k= ey types that are possibly present multiple times (with different keydata) = were somehow labeled in the tables.

Best,
Salvatore= Ingala
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000370fe905c6a2305d--