Skip to content

Latest commit

 

History

History
189 lines (122 loc) · 15.7 KB

slip-0019.md

File metadata and controls

189 lines (122 loc) · 15.7 KB
Raw

SLIP-0019 : Proof of Ownership

Number:  SLIP-0019
Title:   Proof of Ownership
Type:    Standard
Status:  Draft
Authors: Andrew Kozlik <andrew.kozlik@satoshilabs.com>
         Stepan Snigirev <stepan@cryptoadvance.io>
         Ondrej Vejpustek <ondrej.vejpustek@satoshilabs.com>
         Pavol Rusnak <stick@satoshilabs.com>
Created: 2019-04-25

Abstract

This specification defines the format for a proof of ownership which can be passed to a hierarchical deterministic wallet together with each input of an unsigned transaction. This proof allows the wallet to determine whether it is able to spend the given input or not. It also allows third parties to verify that a user has the ability to spend the input.

Motivation

In certain applications like CoinJoin and Lightning, a wallet has to sign transactions containing external inputs. To calculate the actual amount the user is spending, the wallet needs to reliably determine for each input whether it belongs to the wallet or not. Without such a mechanism an attacker can deceive the wallet into displaying incorrect information about the amount being spent, which can result in theft of user funds. This was first recognized in a bitcoin-dev mailing list discussion.

For example, in a CoinJoin transaction an attacker can construct a transaction with inputs in1 and in2 of identical value belonging to the user and two outputs of identical value, user_out belonging to the user and attacker_out belonging to the attacker. If such a transaction is sent to a hardware wallet twice with in1 marked as external the first time and in2 marked as external the second time, then the hardware wallet will display two signing requests to the user with a spending amount of in2 - user_out and in1 - user_out, respectively. The user will think that they are signing two different CoinJoin transactions and spending in1 + in2 - 2*user_out for the fees, while in reality they are signing two different inputs to a single transaction and sending half of the amount to the attacker.

To mitigate such an attack, the hardware wallet needs to ascertain non-ownership of all inputs which are claimed to be external. In case of hierarchical deterministic wallets it is generally not feasible to ascertain this solely based on the scriptPubKey of the UTXO, because it would require searching through billions of BIP32 derivation paths. Furthermore, even though CoinJoin transactions currently work only with P2WPKH addresses, other applications may require more complicated inputs including multi-signature and Schnorr multi-signature in the future.

A CoinJoin coordinator can also benefit from such a proof to verify that the CoinJoin participant is able and willing to sign the input. This verification helps to mitigate denial-of-service attacks as the attacker has to use a limited UTXO set that they control and in case of misbehavior this UTXO set gets banned.

Proof of ownership format

A proof of ownership consists of a proof body and a signature. The proof body contains one or more ownership identifiers which allow a wallet to efficiently determine whether or not it is able to spend a UTXO having a given scriptPubKey. The proof signature affirms that the proof body can be trusted to have been generated by the true owner of the UTXO.

proofOfOwnership = proofBody || proofSignature

Ownership identifier

Let k be a secret ownership identification key derived from the wallet's master secret using the SLIP-0021 method for hierarchical derivation of symmetric keys as:

k = Key(m/"SLIP-0019"/"Ownership identification key")

The ownership identifier for a scriptPubKey is computed as:

id = HMAC-SHA256(key = k, msg = scriptPubKey)

In case of m-of-n multi-signature scriptPubKeys the proof of ownership SHOULD contain the ownership identifiers of all n co-owners of that scriptPubKey. See Identifier inclusion for further details.

A wallet MUST NOT produce and reveal an ownership identifier for a scriptPubKey which it does not control. Such a fake ownership identifier can be used to mount a denial-of-service attack.

Proof body

The proofBody is a concatenation of the following fields:

  • versionMagic (4 bytes): b"\x53\x4c\x00\x19" (this is "SL" followed by 0019 in compressed numeric form as an abbreviation for "SLIP-0019").
  • flags (1 byte, bit 0 is the least significant bit):
    • Bit 0: User confirmation
      • 0 means the proof was generated without user confirmation.
      • 1 means the user confirmed the generation of the proof.
    • Bits 1 to 7: Reserved for future use (all must be 0).
  • n (VarInt): the number of ownership identifiers which follow.
  • id1 || id2 || ... || idn (32 bytes each): concatenation of the ownership identifiers for the given scriptPubKey, one for each co-owner, see Identifier inclusion for further details.

Proof footer

The proofFooter is a concatenation of the following fields:

  • scriptPubKey (length-prefixed string).
  • commitmentData (length-prefixed string), any additional data to which the proof should commit, see below.

The proof footer is included only in the sighash computation. It is not part of the proof of ownership, because the verifier of the proof should obtain these fields externally based on the context in which the proof is provided. Namely the scriptPubKey should be obtained by looking up the output being spent and the commitmentData is given by the application context. Variable-length fields are encoded the same way as in Bitcoin transactions, as a length-prefixed string, where the length is encoded as a variable-length integer (VarInt).

Proof signature

The proofSignature is the SignatureProof container defined in BIP-0322 using the sighash computed as:

sighash = SHA-256(proofBody || proofFooter)

Additional commitment data

The content of the commitmentData field is application-specific. If an application does not define the content of this field, then a zero-length string should be used by default.

In case of CoinJoin transactions the commitmentData SHOULD contain a globally unique PSBT identifier (psbtId). The purpose of such an identifier is to prevent an attacker from causing denial of service by registering an input into a different CoinJoin transaction than the one for which the input was intended. The user should explicitly confirm the generation of the proof and the commitmentData value to affirm their intent to participate in the given CoinJoin transaction.

The psbtId is not to be confused with TXID, which is the hash of a transaction's data. Since the psbtId needs to be known before the transaction is created, it cannot be derived from the transaction data but needs to be generated as a nonce. For example:

  1. The concatenation of a globally unique CoinJoin server identifier (192 bits) with a sequential round identifier (64 bits).
  2. A random 256 bit value.

Proof construction

Single-signature scriptPubKeys

When constructing a proof of ownership for a single-signature scriptPubKey the inputs to the wallet are the flags, scriptPubKey, commitmentData and the BIP32 derivation path. The wallet takes the following steps:

  1. Ensure that bits 1 through 7 of flags are clear.
  2. Ensure that the wallet controls the private key to the provided scriptPubKey. This is typically done by using the provided BIP32 derivation path.
  3. If bit 0 (user confirmation) of flags is set, then prompt the user to confirm generation of the ownership proof with the given commitmentData. If the user does not confirm, then abort.
  4. Compute the ownership identifier for the scriptPubKey.
  5. Compile the proofBody and proofFooter, and generate the proofSignature.
  6. Return the proofBody and proofSignature.

Multi-signature scriptPubKeys

The construction of a proof of ownership for a m-of-n multi-signature scriptPubKey requires a signing coordinator, i.e. a watch-only software wallet. The signing coordinator is assumed to have obtained the ownership identifiers of all n co-owners in advance. These ownership identifiers should generally be produced at the time of the creation of the multi-signature address.

When constructing a proof of ownership, the signing coordinator prepares the proofBody and proofFooter and sends these to each signer together with any other required metadata, such as the BIP32 derivation path for the input. Each of the m signers then takes the following steps:

  1. Parse the proofBody and proofFooter. If versionMagic is not recognized or if any of the bits 1 through 7 of flags is set, then abort.
  2. Derive the ownership identifier using the scriptPubKey provided in the proofFooter.
  3. If the derived ownership identifier is not listed in the proofBody, then abort.
  4. If bit 0 (user confirmation) of flags is set, then prompt the user to confirm generation of the ownership proof with the given commitmentData. If the user does not confirm, then abort.
  5. Return the signature for the provided proofBody and proofFooter.

The signing coordinator collects all the signatures and combines them into a SignatureProof container to finalize the proof.

Proof usage

Verifying non-ownership of transaction inputs

When a wallet is requested to sign a transaction, each external input SHOULD be accompanied with a proof of ownership so that the wallet may ascertain non-ownership of such an input in order to correctly inform the user about the amount they are spending in the transaction. For each external input the wallet takes the following steps:

  1. By reliable means obtain the scriptPubKey of the UTXO being spent by that input. Prior to SegWit version 1 witness programs this step involves acquiring the full transaction being spent and verifying its hash against that which is given in the outpoint.
  2. Parse the proofBody. If versionMagic is not recognized or if any of the bits 1 through 7 of flags is set, then abort.
  3. Verify that the proofSignature is valid in accordance with BIP-0322 using the obtained scriptPubKey and the sighash as defined in the Proof signature section.
  4. Derive the ownership identifier using the wallet's ownership identification key and the obtained scriptPubKey.
  5. Verify that the derived ownership identifier is not included in the proofBody.

Verifying ability and intent to sign an input

Each input which is registered to take part in a CoinJoin transaction should be accompanied with a proof of ownership which affirms the owner's intent to take part, so as to mitigate denial-of-service attacks. The CoinJoin coordinator takes the following steps before registering an input:

  1. By reliable means obtain the scriptPubKey of the UTXO being spent by that input.
  2. Parse the proofBody. If versionMagic is not recognized or if any of the bits 1 through 7 of flags is set, then abort.
  3. Verify that bit 0 (user confirmation) of flags is set.
  4. Verify that the proofSignature is valid using the obtained scriptPubKey.

A proof of ownership commits to a particular scriptPubKey, which means that the proof is replayable for UTXOs with the same address. Nevertheless, freshness of such a proof is guaranteed if a nonce (such as the psbtId) is included in the commitmentData.

PSBT (BIP 174) extension

The following new global field type is added to the BIP-0174 specification:

  • Type: PSBT identifier PSBT_GLOBAL_PSBT_ID = 0x0A
    • Key: None. The key must only contain the 1 byte type.
      • {0x02}
    • Value: A globally unique PSBT identifier. This value should be used as the commitmentData in the proofFooter.
      • {psbtId}

The following new per-input field type is added to the BIP-0174 specification:

  • Type: Proof of ownership PSBT_IN_PROOF_OF_OWNERSHIP = 0x0A
    • Key: None. The key must only contain the 1 byte type.
      • {0x0A}
    • Value: The proofOfOwnership as defined above.
      • {proofOfOwnership}

Implementation considerations

Script evaluation on hardware wallets

Currently most hardware wallets do not support complete Bitcoin script verification, so initial deployment of proofs of ownership can be limited to a set of known scripts. In the future hardware wallets may implement miniscript verification, that will cover most of the use-cases known today.

Identifier inclusion

When generating a proof of ownership for m-of-n multi-signature scriptPubKeys the proof body SHOULD contain the ownership identifiers of all n co-owners of that scriptPubKey. Failing to include all ownership identifiers opens the door to the following attack.

For simplicity consider two equal-valued UTXOs A and B, both of which have the same 1-of-2 multi-signature scriptPubKey controlled by Users 1 and 2. The attacker requests a proof of ownership P1 from User 1 containing only User 1's ownership identifier. Similarly the attacker requests a proof of ownership P2 from User 2 containing only User 2's ownership identifier. The attacker then creates a CoinJoin transaction with inputs A and B and equal-valued outputs out_user and out_attacker, the former of which is a multi-signature scriptPubKey controlled by Users 1 and 2. User 1 is given the transaction to sign with proof P2 for the input spending B, and User 2 is given the same transaction to sign with proof P1 for the input spending A. User 1 perceives B as foreign, assumes they are transferring A to out_user and signs the input spending A. User 2 perceives A as foreign, assumes they are transferring B to out_user and signs the input spending B. As a result half of the amount from A and B is transferred to the attacker. This attack is extendable to more complex m-of-n multi-signatures.

In some cases there are legitimate reasons not to include the ownership identifier of a co-owner:

  1. The excluded co-owner does not support any kind of proof of ownership format and will never take part in a transaction containing external inputs. An example of this would be a cryptocurrency custody service which is included in the multi-signature setup only as a backup in case the key of one of the co-owners is lost.
  2. A co-owner is intentionally excluded to avoid signing failures due to input ownership collisions. Consider a user who is participating in a CoinJoin transaction with their UTXO A. At the same time this user happens to be a co-owner of another UTXO B being spent as an input in the same transaction. The user is not meant to be cosigning B, because this input was registered independently by a group of co-owners who did not expect the user to participate. Thus the user's wallet will recognize B as an input it co-owns, but it will not be able to sign because it was not given the corresponding BIP32 derivation path. Even if the path were to be provided, the user might not be willing to cosign due to confusion at the unexpected presence of the input amount supplied by B. As a result the CoinJoin transaction will fail to complete. Before excluding an ownership identifier on these grounds, the likelihood of this kind of scenario needs to be carefully weighed against the risk of the attack described above.

Test vectors

TODO

References

  • bitcoin-dev: Original mailing list thread
  • BIP-0174: Partially Signed Bitcoin Transaction Format
  • BIP-0322: Generic Signed Message Format