path: root/0e/d2f30a55f655255bc1ad1323c5579b6bfc685c

Return-Path: <jlrubin@mit.edu>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 19FD3C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 10 Jan 2021 19:39:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 0155785A37
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 10 Jan 2021 19:39:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wohasVfHzXYZ
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 10 Jan 2021 19:39:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id B1E3A8593F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 10 Jan 2021 19:39:28 +0000 (UTC)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com
 [209.85.166.54]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10AJdQd2011969
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Sun, 10 Jan 2021 14:39:27 -0500
Received: by mail-io1-f54.google.com with SMTP id d9so15584410iob.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 10 Jan 2021 11:39:27 -0800 (PST)
X-Gm-Message-State: AOAM531/4DhbHH2G5a9lONHJoeSQiyNHpqpILkg5OKBJ9Zqt4XDzRQzO
 SS9k5n+SnPzTfw73Y8gBFFYLgGfOFcq7YhUgvmY=
X-Google-Smtp-Source: ABdhPJwj6Olcqz562x/YE8skylbL0HrEzWirVFxOBz5UnB7j7nMdZshRm0Xv6b6LvlxbFP16lcXCkrFa0rzeE9Rx5Is=
X-Received: by 2002:a6b:3b92:: with SMTP id i140mr12350004ioa.49.1610307566299; 
 Sun, 10 Jan 2021 11:39:26 -0800 (PST)
MIME-Version: 1.0
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 10 Jan 2021 11:39:15 -0800
X-Gmail-Original-Message-ID: <CAD5xwhg-+QLrXFRLXyPoYRRE6dDLzXVhzbqP2iwc6MHq3j=Pag@mail.gmail.com>
Message-ID: <CAD5xwhg-+QLrXFRLXyPoYRRE6dDLzXVhzbqP2iwc6MHq3j=Pag@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000077f22c05b890f2f4"
Subject: [bitcoin-dev] Extension to BIP Format for Multiple Required SigHash
	Flags
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: Sun, 10 Jan 2021 19:39:30 -0000

--00000000000077f22c05b890f2f4
Content-Type: text/plain; charset="UTF-8"

- *# The Issue:*
- Currently the PSBT BIP has a slight "conceptual gap" where it is possible
to both:
-
- 1) Have a PSBT which obtains multiple signatures per-input with any set
of SIGHASH Flags
- 2) Have a PSBT which obtains multiple signatures per-input with a fixed
SigHash type applying to all signatures.
-
- But not possible to:
3) Have a PSBT which obtains multiple signatures per-input with a fixed
sighash type applying to a specific key's signature
4) Gracefully handle a PSBT with multiple uses of the same key, but
different code-separators.

To solve this we should introduce a new key type compatible with the
existing PSBT Spec (no V2 Requirement).

(I'm not convinced that 4 needs to be fully supported, but I believe that
it makes sense to lay the groundwork for it to be supported as the handling
of different requests for sighash flags and multiple uses of the same key
with different codeseps should happen from the same field.)

Excerpted relevant BIP text:
```

* Type: Partial Signature <tt>PSBT_IN_PARTIAL_SIG = 0x02</tt>
** Key: The public key which corresponds to this signature.
*** <tt>{0x02}|{public key}</tt>
** Value: The signature as would be pushed to the stack from a
scriptSig or witness.
*** <tt>{signature}</tt>

* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt>
** Key: None. The key must only contain the 1 byte type.
*** <tt>{0x03}</tt>
** Value: The 32-bit unsigned integer specifying the sighash type to
be used for this input. Signatures for this input must use the sighash
type, finalizers must fail to finalize inputs which have signatures
that do not match the specified sighash type. Signers who cannot
produce signatures with the sighash type must not provide a signature.
*** <tt>{sighash type}</tt>

```

*# Motivation*:
As An example where it may be relevant to cleanly support this, consider
the script:

`2 <Key 1 Checks Approved Output Addresses> <Key 2 Checks Input Allowed to
Spend> 2 CHECKMULTI`

Under such a script, we might have 2 HSMs operating each key. Key 2 is used
first which verifies internal business logic only about the permissibility
of spending an output, but does not sign off on any other logic. Key 1 is
used last which checks that transaction sends only to the currently allowed
addresses and is signed by Key 1. In such an example (discussion of this
particular application is off topic, this is a contrived example to
demonstrate the technical issue), it is not possible to express that Key 1
will sign with SIGHASH_ALL | ANYONECANPAY and Key 2 will sign with
SIGHASH_NONE | ANYONECANPAY. It would be impossible to finalize a PSBT with
SigHash type set, because the sighashes conflict. And while it is possible
to not have any Sighash type set and successfully finalize, this fails to
capture the relevant information around which sighash types are supposed to
be used.

(why the example is contrived: one could argue that you should just have
such business logic *always* use SIGHASH_ALL for such business logic
servers, but there are technical reasons (e.g., adding a change input or
output dynamically with SIGHASH_SINGLES) that you might have to do post-hoc)

*# A Solution*
To address this I propose to add a new key type
PSBT_IN_SIGHASH_PER_KEY_TYPE (e.g., 0x0e) which is followed by a public
key, a 8-bit bool (must be 0 or 1) if the next field will be a sighash
flag, optionally a 32-bit unsigned integer representing the sighash type,
and a compact size integer representing the codeseparator position + 1 (so
that 0 may represent no codeseparator) in the scriptpubkey. If a
codeseparator is set, the redeem script (+ witness script if witness) must
be present.

Finalizers should verify that each requested signature is available.

PSBT_IN_SIGHASH_PER_KEY_TYPE is fully compatible with existing PSBT as long
as PSBT_IN_SIGHASH_TYPE is not set (or, trivially, if it is set and all
PSBT_IN_SIGHASH_PER_KEY_TYPE's match it).

Finalizers could deduce which codeseparator was used if multiple
PSBT_IN_PARTIAL_SIGS are delivered by process of elimination, thus a new
PSBT_IN_PARTIAL_SIG type to specify codeseparator is not required. However,
in the case of multiple signatures, PSBT_IN_PARTIAL_SIG would lead to a
duplicated key-pair specification error so we should also introduce the
type PSBT_IN_PARTIAL_SIG_EXTRA which has a key of a public key followed by
a compact size integer code separator (n.b. no +1 value to exclude the
default!), and a signature as a value. Finalizers shall check that the
PSBT_IN_PARTIAL_SIG_EXTRA values match the corresponding
PSBT_IN_SIGHASH_PER_KEY_TYPE requests. Compatibility: PSBT_IN_PARTIAL_SIG
does not overlap with PSBT_IN_PARTIAL_SIG_EXTRA as '_EXTRA must specify a
codeseparator. Thus, as long as no repeated key/codeseparators are used,
the new PSBT remains fully backwards compatible.

--
@JeremyRubin <https://twitter.com/JeremyRubin>

--00000000000077f22c05b890f2f4
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"><li><b># The Issue:</b><b=
r></li><li>Currently the PSBT BIP has a slight &quot;conceptual gap&quot; w=
here it is possible to both:</li><li><br></li><li>1) Have a PSBT which obta=
ins multiple signatures per-input with any set of SIGHASH Flags<br></li><li=
>2) Have a PSBT which obtains multiple signatures per-input with a fixed Si=
gHash type applying to all signatures.</li><li><br></li><li>But not possibl=
e to:<br></li></div><div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">3) Have a PSBT=
 which obtains multiple signatures per-input with a fixed sighash type appl=
ying to a specific key&#39;s signature</div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult">4) Gracefully handle a PSBT with multiple uses of the same key, but di=
fferent code-separators.</div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)" class=3D"gmail_default">To solve this we should introduce a ne=
w key type compatible with the existing PSBT Spec (no V2 Requirement).<br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default">(I&#39;m not convinced that 4 needs to be fully supported, but =
I believe that it makes sense to lay the groundwork for it to be supported =
as the handling of different requests for sighash flags and multiple uses o=
f the same key with different codeseps should happen from the same field.)<=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><br></div></div><div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default">Excerpted relevant BIP text:</div></div><div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)" class=3D"gmail_default">```<br><pre>* Type: Partial Signature &lt;=
tt&gt;PSBT_IN_PARTIAL_SIG =3D 0x02&lt;/tt&gt;
** Key: The public key which corresponds to this signature.
*** &lt;tt&gt;{0x02}|{public key}&lt;/tt&gt;
** Value: The signature as would be pushed to the stack from a scriptSig or=
 witness.
*** &lt;tt&gt;{signature}&lt;/tt&gt;

* Type: Sighash Type &lt;tt&gt;PSBT_IN_SIGHASH_TYPE =3D 0x03&lt;/tt&gt;
** Key: None. The key must only contain the 1 byte type.
*** &lt;tt&gt;{0x03}&lt;/tt&gt;
** Value: The 32-bit unsigned integer specifying the sighash type to be use=
d for this input. Signatures for this input must use the sighash type, fina=
lizers must fail to finalize inputs which have signatures that do not match=
 the specified sighash type. Signers who cannot produce signatures with the=
 sighash type must not provide a signature.
*** &lt;tt&gt;{sighash type}&lt;/tt&gt;</pre>```</div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b># Motivatio=
n</b>:<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default">As An example where it =
may be relevant to cleanly support this, consider the script:</div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">`=
2 &lt;Key 1 Checks Approved Output Addresses&gt; &lt;Key 2 Checks Input All=
owed to Spend&gt; 2 CHECKMULTI`</div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)" class=3D"gmail_default">Under such a script, we might h=
ave 2 HSMs operating each key. Key 2 is used first which verifies internal =
business logic only about the permissibility of spending an output, but doe=
s not sign off on any other logic. Key 1 is used last which checks that tra=
nsaction sends only to the currently allowed addresses and is signed by Key=
 1. In such an example (discussion of this particular application is off to=
pic, this is a contrived example to demonstrate the technical issue), it is=
 not possible to express that Key 1 will sign with SIGHASH_ALL | ANYONECANP=
AY and Key 2 will sign with SIGHASH_NONE | ANYONECANPAY. It would be imposs=
ible to finalize a PSBT with SigHash type set, because the sighashes confli=
ct. And while it is possible to not have any Sighash type set and successfu=
lly finalize, this fails to capture the relevant information around which s=
ighash types are supposed to be used.<br></div><div style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_d=
efault"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)" class=3D"gmail_default">(why the example is c=
ontrived: one could argue that you should just have such business logic *al=
ways* use SIGHASH_ALL for such business logic servers, but there are techni=
cal reasons (e.g., adding a change input or output dynamically with SIGHASH=
_SINGLES) that you might have to do post-hoc)<br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b># A Soluti=
on</b><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default">To address this I propo=
se to add a new key type PSBT_IN_SIGHASH_PER_KEY_TYPE (e.g., 0x0e) which is=
 followed by a public key, a 8-bit bool (must be 0 or 1) if the next field =
will be a sighash flag, optionally a 32-bit unsigned integer representing t=
he sighash type, and a compact size integer representing the codeseparator =
position + 1 (so that 0 may represent no codeseparator) in the scriptpubkey=
. If a codeseparator is set, the redeem script (+ witness script if witness=
) must be present.<br></div><div style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)" class=3D"gmail_default">Finalizers should verify that each reque=
sted signature is available.</div><div style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default">PSBT_IN_SIGHASH_PER_KEY_TYPE is fu=
lly compatible with existing PSBT as long as PSBT_IN_SIGHASH_TYPE is not se=
t (or, trivially, if it is set and all PSBT_IN_SIGHASH_PER_KEY_TYPE&#39;s m=
atch it).</div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cl=
ass=3D"gmail_default">Finalizers could deduce which codeseparator was used =
if multiple PSBT_IN_PARTIAL_SIGS are delivered by process of elimination, t=
hus a new PSBT_IN_PARTIAL_SIG type to specify codeseparator is not required=
. However, in the case of multiple signatures, PSBT_IN_PARTIAL_SIG would le=
ad to a duplicated key-pair specification error so we should also introduce=
 the type PSBT_IN_PARTIAL_SIG_EXTRA which has a key of a public key followe=
d by a compact size integer code separator (n.b. no +1 value to exclude the=
 default!), and a signature as a value. Finalizers shall check that the PSB=
T_IN_PARTIAL_SIG_EXTRA values match the corresponding PSBT_IN_SIGHASH_PER_K=
EY_TYPE requests. Compatibility: PSBT_IN_PARTIAL_SIG does not overlap with =
PSBT_IN_PARTIAL_SIG_EXTRA as &#39;_EXTRA must specify a codeseparator. Thus=
, as long as no repeated key/codeseparators are used, the new PSBT remains =
fully backwards compatible.<br></div></div><br clear=3D"all"><div><div dir=
=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_bl=
ank">@JeremyRubin</a></div></div></div></div>

--00000000000077f22c05b890f2f4--