Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 19FD3C013A for ; 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 ; 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 ; 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 ; 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 ; Sun, 10 Jan 2021 14:39:27 -0500 Received: by mail-io1-f54.google.com with SMTP id d9so15584410iob.6 for ; 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 Date: Sun, 10 Jan 2021 11:39:15 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 PSBT_IN_PARTIAL_SIG = 0x02 ** Key: The public key which corresponds to this signature. *** {0x02}|{public key} ** Value: The signature as would be pushed to the stack from a scriptSig or witness. *** {signature} * Type: Sighash Type PSBT_IN_SIGHASH_TYPE = 0x03 ** Key: None. The key must only contain the 1 byte type. *** {0x03} ** 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. *** {sighash type} ``` *# Motivation*: As An example where it may be relevant to cleanly support this, consider the script: `2 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 --00000000000077f22c05b890f2f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
  • # The Issue:
  • Currently the PSBT BIP has a slight "conceptual gap" w= here it is possible to both:

  • 1) Have a PSBT which obta= ins multiple signatures per-input with any set of SIGHASH Flags
    • 2) Have a PSBT which obtains multiple signatures per-input with a fixed Si= gHash type applying to all signatures.

  • But not possibl= e to:
    • 3) Have a PSBT= which obtains multiple signatures per-input with a fixed sighash type appl= ying to a specific key's signature
    4) Gracefully handle a PSBT with multiple uses of the same key, but di= fferent code-separators.

    To solve this we should introduce a ne= w key type compatible with the existing PSBT Spec (no V2 Requirement).
    <= /div>

    (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 o= f the same key with different codeseps should happen from the same field.)<= br>

    Excerpted relevant BIP text:
    ```
    * Type: Partial Signature <=
tt>PSBT_IN_PARTIAL_SIG =3D 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 =3D 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 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.
*** <tt>{sighash type}</tt>
    ```

    # Motivatio= n:
    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 All= owed to Spend> 2 CHECKMULTI`
    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.

    (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)

    # A Soluti= on
    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.

    <= 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>
    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's m= atch it).

    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 '_EXTRA must specify a codeseparator. Thus= , as long as no repeated key/codeseparators are used, the new PSBT remains = fully backwards compatible.

    --00000000000077f22c05b890f2f4--