path: root/dc/ee4675dea0877de2a56877c06483ff7de18704

Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B65C3C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>; Thu, 8 Jul 2021 16:06:20 -0400
Received: by mail-il1-f177.google.com with SMTP id g3so7883778ilj.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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>
 <CAMhCMoF7N4BuXDz1cSDBLi5zH8c06uZ3T3gc750azFH3JagcNw@mail.gmail.com>
 <912b172b-009d-9d5f-32d8-189e7fbe7646@achow101.com>
 <CAMhCMoFD+W-13JFKuF5GnbO2V6htNM3U-rs1ELqEEeV5jF_VpQ@mail.gmail.com>
In-Reply-To: <CAMhCMoFD+W-13JFKuF5GnbO2V6htNM3U-rs1ELqEEeV5jF_VpQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 8 Jul 2021 13:06:08 -0700
X-Gmail-Original-Message-ID: <CAD5xwhjrdijV0Qozb67_3YiAfzu5BYrP7nY9xxcWV7gXG_8nxw@mail.gmail.com>
Message-ID: <CAD5xwhjrdijV0Qozb67_3YiAfzu5BYrP7nY9xxcWV7gXG_8nxw@mail.gmail.com>
To: Salvatore Ingala <salvatore.ingala@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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 <https://twitter.com/JeremyRubin>
<https://twitter.com/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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Suggestion:</div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It shou=
ld be allowed that different keys can specify different sighash flags.</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">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.</div><div class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div class=
=3D"gmail_default">The current sighashtype key is per-input:<br>- If a sigh=
ash type is provided, the signer must check that the sighash is acceptable.=
 If unacceptable, they must fail.<br>- If a sighash type is not provided, t=
he signer should sign using SIGHASH_ALL, but may use any sighash type they =
wish.</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_defau=
lt">So a new per-key mapping can be added safely.</div><div class=3D"gmail_=
default"><br></div><div class=3D"gmail_default">I have no strong opinions o=
n the format for said per-key sighash hints.</div><div class=3D"gmail_defau=
lt"><br></div><div class=3D"gmail_default">Why do this now? Well, I request=
ed it when spec&#39;ing V2 as well, but it would be nice to get it spec&#39=
;d and implemented.<br><br><br><span style=3D"color:rgb(34,34,34);font-fami=
ly:Arial,Helvetica,sans-serif;font-size:small">--</span><br></div><div><div=
 dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><=
div dir=3D"ltr"><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blan=
k">@JeremyRubin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_b=
lank"></a></div></div></div><br></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Mon, Jun 28, 2021 at 1:32 PM Salvatore I=
ngala via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>Hi Andrew,</div><div><br></div><div>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.</div><div><br></div><div=
>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.</div><br><div>Best,</div><div>Salvatore=
 Ingala<br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000370fe905c6a2305d--