[prev in list] [next in list] [prev in thread] [next in thread]
List: bitcoin-dev
Subject: Re: [bitcoin-dev] Taproot Fields for PSBT
From: Jeremy via bitcoin-dev <bitcoin-dev () lists ! linuxfoundation ! org>
Date: 2021-07-08 20:06:08
Message-ID: CAD5xwhjrdijV0Qozb67_3YiAfzu5BYrP7nY9xxcWV7gXG_8nxw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
>
[Attachment #5 (text/html)]
<div dir="ltr"><div class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Suggestion:</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">It \
should be allowed that different keys can specify different sighash flags.</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">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.</div><div \
class="gmail_default" \
style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><div \
class="gmail_default">The current sighashtype key is per-input:<br>- If a sighash \
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, the signer \
should sign using SIGHASH_ALL, but may use any sighash type they wish.</div><div \
class="gmail_default"><br></div><div class="gmail_default">So a new per-key mapping \
can be added safely.</div><div class="gmail_default"><br></div><div \
class="gmail_default">I have no strong opinions on the format for said per-key \
sighash hints.</div><div class="gmail_default"><br></div><div \
class="gmail_default">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.<br><br><br><span \
style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">--</span><br></div><div><div \
dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><a \
href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a \
href="https://twitter.com/JeremyRubin" \
target="_blank"></a></div></div></div><br></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Mon, Jun 28, 2021 at 1:32 PM Salvatore Ingala via \
bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>Hi Andrew,</div><div><br></div><div>Thanks for the clarification, I \
was indeed reading it under the mistaken assumption 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 key 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="mailto:bitcoin-dev@lists.linuxfoundation.org" \
target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> <a \
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" \
rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic