SIGHASH_ANYPREVOUT for Taproot Scripts

  BIP: 118
  Layer: Consensus (soft fork)
  Title: SIGHASH_ANYPREVOUT for Taproot Scripts
  Authors: Christian Decker 
           Anthony Towns 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0118
  Status: Draft
  Type: Specification
  Assigned: 2017-02-28
  License: BSD-3-Clause
  Requires: 340, 341, 342

Introduction

Abstract

This BIP describes a new type of public key for tapscript (BIP 342) transactions. It allows signatures for these public keys to not commit to the exact UTXO being spent. This enables dynamic binding of transactions to different UTXOs, provided they have compatible scripts.

Copyright

This document is licensed under the 3-clause BSD license.

Motivation

Off-chain protocols make use of transactions that are not yet broadcast to the Bitcoin network in order to renegotiate the final state that should be settled on-chain. In a number of cases it is desirable to respond to a given transaction being seen on-chain with a predetermined reaction in the form of another transaction. Often the same reaction is desired for a variety of different transactions that may be seen on-chain, but because the input signatures in the response transaction commit to the exact transaction that is being reacted to, this means a new signature must be created for every possible transaction one wishes to be able to react to.

This proposal introduces a new public key type that modifies the behavior of the transaction digest algorithm used in the signature creation and verification, by excluding the commitment to the previous output (and, optionally, the witness script and value ). Removing this commitment allows dynamic rebinding of a signed transaction to another previous output that requires authorisation by the same key.

The dynamic rebinding is opt-in due to using a separate public key type, and the breadth of transactions the signature can be rebound to can be further restricted by using different keys, committing to the script being spent in the signature, using different amounts between UTXOs, using different nSequence values in the spending transaction, or using the codeseparator opcode to commit to the position in the script.

Specification

This BIP modifies the behaviour of the BIP 342 signature opcodes (CHECKSIG, CHECKSIGVERIFY, and CHECKSIGADD) for public keys that have a length of 33 bytes and a first byte of 0x01 or the public key which is precisely the single byte vector 0x01. These keys are termed BIP 118 public keys.

Rules for signature opcodes

The BIP 342 rules for signature opcodes are modified by removing keys with the first byte 0x01 and length of either 1-byte or 33-bytes from the list of unknown public key types, and adding the following rule prior to the handling of unknown public key types:

• If the public key is the single byte 0x01, or if the public key is 33 bytes and the first byte of the public key is 0x01, it is considered to be a BIP 118 public key:

** If the signature is not the empty vector, the signature is validated according to the BIP 341 signing validation rules with the public key, allowable hash_type values, and transaction digest modified as defined below.

Public key

To convert the 1-byte BIP 118 public key for use with BIP 340, use the 32-byte taproot internal key, p, as defined in BIP 341.

To convert a 33-byte BIP 118 public key for use with BIP 340, remove the 0x01 prefix and use the remaining 32 bytes.

Signature message

We define the functions Msg118(hash_type) and Ext118(hash_type) which compute the message being signed as a byte array.

The parameter hash_type is an 8-bit unsigned value, reusing values defined in BIP 341, with the addition that the values 0x41, 0x42, 0x43, 0xc1, 0xc2, and 0xc3 are also valid for BIP 118 public keys.

We define the following constants using bits 6 and 7 of hash_type:

• SIGHASH_ANYPREVOUT = 0x40
• SIGHASH_ANYPREVOUTANYSCRIPT = 0xc0

The following restrictions apply and cause validation failure if violated:

• Using any undefined hash_type (not 0x00, 0x01, 0x02, 0x03, 0x41, 0x42, 0x43, 0x81, 0x82, 0x83, 0xc1, 0xc2, or 0xc3).
• Using SIGHASH_SINGLE without a "corresponding output" (an output with the same index as the input being verified).

If these restrictions are not violated, Msg118(hash_type) evaluates as follows.

If hash_type & 0x40 == 0, then Msg118(hash_type) = SigMsg(hash_type, 1), where SigMsg is as defined in BIP 341.

If hash_type & 0x40 != 0, then Msg118(hash_type) is the concatenation of the following data, in order (with byte size of each item listed in parentheses). Numerical values in 2, 4, or 8-byte items are encoded in little-endian.

• Control:

** hash_type (1).

• Transaction data:

** nVersion (4): the nVersion of the transaction. ** nLockTime (4): the nLockTime of the transaction. ** If hash_type & 3 does not equal SIGHASH_NONE or SIGHASH_SINGLE: *** sha_outputs (32): the SHA256 of the serialization of all outputs in CTxOut format.

• Data about this input:

** spend_type (1): equal to 2 if no annex is present, or 3 otherwise (the original witness stack has two or more witness elements, and the first byte of the last element is 0x50) ** If hash_type & 0xc0 is SIGHASH_ANYPREVOUT: *** amount (8): value of the previous output spent by this input. *** scriptPubKey (35): scriptPubKey of the previous output spent by this input, serialized as script inside CTxOut. Its size is always 35 bytes. ** nSequence (4): nSequence of this input. ** If an annex is present (the lowest bit of spend_type is set): *** sha_annex (32): the SHA256 of (compact_size(size of annex) || annex), where annex includes the mandatory 0x50 prefix.

• Data about this output:

** If hash_type & 3 equals SIGHASH_SINGLE: *** sha_single_output (32): the SHA256 of the corresponding output in CTxOut format.

Similarly, Ext118(hash_type) evaluates to the concatenation of the following data, in order:

• Extension:

** If hash_type & 0xc0 is not SIGHASH_ANYPREVOUTANYSCRIPT: *** tapleaf_hash (32): the tapleaf hash as defined in BIP 341 ** key_version (1): a constant value 0x01 representing that this is a signature for a BIP 118 public key. ** codesep_pos (4): the opcode position of the last executed OP_CODESEPARATOR before the currently executed signature opcode, with the value in little endian (or 0xffffffff if none executed). The first opcode in a script has a position of 0. A multi-byte push opcode is counted as one opcode, regardless of the size of data being pushed.

To verify a signature sig for a BIP 118 public key p:

• If the sig is 64 bytes long, return Verify(p, hash_TapSigHash(0x00 || Msg118(0x00) || Ext118(0x00)), sig)
• If the sig is 65 bytes long, return sig[64] ≠ 0x00 and Verify(p, hash_TapSighash(0x00 || Msg118(sig[64]) || Ext118(sig[64])), sig[0:64]).
• Otherwise, fail.

Verify is as defined in BIP 340.

The key differences from BIP 342 signature verification are:

• In all cases, key_version is set to the constant value 0x01 instead of 0x00.
• If SIGHASH_ANYPREVOUT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint is not included in the digest.
• If SIGHASH_ANYPREVOUTANYSCRIPT is set, the digest is calculated as if SIGHASH_ANYONECANPAY was set, except outpoint, amount, scriptPubKey and tapleaf_hash are not included in the digest.

Security

Signature replay

By design, SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT introduce additional potential for signature replay (that is they allow the same signature to be reused on a different transaction) when compared to SIGHASH_ALL and SIGHASH_ANYONECANPAY signatures.

Both SIGHASH_ALL and SIGHASH_ANYONECANPAY signatures prevent signature replay by committing to one or more inputs, so replay of the signature is only possible if the same input can be spent multiple times, which is not possible on the Bitcoin blockchain (due to enforcement of BIP 30). With SIGHASH_ANYPREVOUT signature replay is possible for different UTXOs with the same scriptPubKey and the same value, while with SIGHASH_ANYPREVOUTANYSCRIPT signature replay is possible for any UTXOs that reuse the same BIP 118 public key in one of their potential scripts.

As a consequence, implementers MUST ensure that BIP 118 public keys are only reused when signature replay cannot cause loss of funds (eg due to other features of the protocol or other constraints on the transaction), or when such a loss of funds is acceptable.

Malleability

Use of SIGHASH_ANYPREVOUT or SIGHASH_ANYPREVOUTANYSCRIPT may introduce additional malleability vectors.

In particular, a transaction authenticated using only ANYPREVOUT signatures is malleable to anyone able to provide an alternate input satisfied by the signature -- an input changed in this way would produce a new, valid transaction paying the same recipient, but with a different txid. Depending on the changes to the inputs, this might conflict with the original transaction (if some inputs remain shared) or might result in a double-payment to the recipient (if they do not).

Further, for a chain of transactions using the same scriptPubKey and value, and only authenticated via ANYPREVOUT signatures (as envisioned in eltoo for failure cases), it may be possible for any third party to malleate the transactions (and their txids) without having access to any of the private keys, particularly by omitting intermediate transactions.

This form of malleation can be dealt with by the child transactions also using ANYPREVOUT signatures -- when a parent transaction is malleated, its children can be adjusted to reference the new txi