Home › Browse › BIP 392

BIP 392: Silent Payment Output Script Descriptors

In plain English: Defines an 'sp()' descriptor for Silent Payment wallets, describing the keys needed to detect and spend payments sent to a reusable Silent Payment address. This lets such wallets be backed up and restored using the same standard descriptor tools as other wallets.

Status
Draft
Type
Specification
Layer
Applications
Authors
Craig Raw
Assigned
Last changed
Requires
BIP 341, BIP 350, BIP 352, BIP 380
Topics
Wallets, Payments
Source
bip-0392.mediawiki on GitHub · Markdown

Abstract

This document specifies sp() output script descriptors for silent payments. sp() descriptors take silent payment key material and describe P2TR outputs when combined with sender input public keys as defined in BIP352.

This BIP is licensed under the BSD 2-clause license.

Motivation

BIP352 defines silent payments, a protocol for static payment addresses without on-chain linkability. This descriptor provides a standardized way to represent silent payment outputs within the output descriptor framework, enabling wallet interoperability and backup/recovery using existing descriptor-based infrastructure.

Specification

A new top level script expression is defined: sp().

Key Expressions

Two new key expression types are defined for use with sp() descriptors:

spscan

The spscan key expression encodes the scan private key and spend public key. It is a Bech32m encoding of:

  • The human-readable part "spscan" for mainnet, "tspscan" for testnets
  • The data-part values:
    • The character "q", to represent silent payments version 0
    • The payload: ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>P</sub>(B<sub>spend</sub>)

spspend

The spspend key expression encodes both the scan and spend private keys. It is a Bech32m encoding of:

  • The human-readable part "spspend" for mainnet, "tspspend" for testnets
  • The data-part values:
    • The character "q", to represent silent payments version 0
    • The payload: ser<sub>256</sub>(b<sub>scan</sub>) || ser<sub>256</sub>(b<sub>spend</sub>)

Note: The serialization of ser<sub>256</sub>(p) and ser<sub>P</sub>(P) follows the definition in BIP352.

sp()

The sp(KEY) or sp(KEY,KEY) expression can only be used as a top level descriptor.

sp(KEY) takes a single key expression as an argument, which must be either an spscan or spspend encoded key, optionally with key origin information. If included, the key origin information specifies the fingerprint and derivation path to the depth from which the scan and spend keys are derived using the child paths recommended in BIP352 (1h/0 for scan, 0h/0 for spend).

sp(KEY,KEY) takes two key expressions. The first key expression represents the scan key and must be a single private key (e.g. a WIF compressed private key or xprv extended private key). The second key expression represents the spend key and may be any key expression as defined in BIP380 or other key expression BIPs (e.g. musig() as defined in BIP390) that represents a single key, public or private. Note however that uncompressed keys are not allowed under any sp() expression, as BIP352 only permits compressed public keys.

When combined with sender input public keys, the descriptor produces P2TR output scripts describing silent payments made to wallets represented by the key expression(s).

The output scripts produced are BIP341 taproot outputs as specified in BIP352.

Examples

Valid descriptors:

  • sp(spscan1q...) - Using spscan encoded key (watch-only)
  • sp([deadbeef/352h/0h/0h]spscan1q...) - With key origin
  • sp(spspend1q...) - Using spspend encoded key (full wallet)
  • sp(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1,0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600) - WIF scan key with compressed public spend key (watch-only)
  • sp([deadbeef/352h/0h/0h]xprv.../0h,xpub.../0h) - Extended private scan key with extended public spend key (watch-only)
  • sp([deadbeef/352h/0h/0h]xprv.../0h,xprv.../0h) - Extended private keys for both scan and spend (full wallet)
  • sp(L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1,musig(03dff1d77f2a671c5f36183726db2341be58feae1da2deced843240f7b502ba659,023590a94e768f8e1815c2f24b4d80a8e3149316c3518ce7b7ad338368d038ca66)) - WIF scan key with MuSig2 aggregate spend key (watch-only)

Invalid descriptors:

  • sp() requires at least one key expression
  • sp(xpub...) single argument form requires spscan or spspend encoded key
  • sp(xpub...,xpub...) two argument form requires private scan key (e.g. WIF or xprv)
  • sp(spscan1q...,spscan1q...) two argument form requires single key expressions
  • sp(5KYZdUEo39z3FPrtuX2QbbwGnNP5zTd7yyr2SC1j299sBCnWjss,0260b2003c386519fc9eadf2b5cf124dd8eea4c4e68d5e154050a9346ea98ce600) uncompressed private key
  • sh(sp(spscan1q...)) sp() is top level only
  • wsh(sp(spscan1q...)) sp() is top level only

Usage Notes

For watch-only wallets, use spscan encoding or the two argument form with a public spend key. For full wallets that can both scan and spend, use spspend encoding or the two argument form with a private spend key.

When using the two argument form, the scan key must be private (e.g. WIF or xprv) since scanning requires the private scan key.

Backwards Compatibility

sp() descriptors use the format and general operation specified in BIP380. As this is a wholly new descriptor, it is not compatible with any prior implementation. The scripts produced are BIP341 taproot outputs, making them indistinguishable from other taproot outputs on-chain.

Reference Implementation

TBD

Test Vectors

TBD

Related proposals

  • BIP 20: URI Scheme: Closed. An early proposal for "bitcoin:" links that bundle an address and amount, so clicking or scanning one opens a wallet ready to pay. It was superseded by BIP 21.
  • BIP 21: URI Scheme: Closed. Defines the "bitcoin:" link format that packages an address, amount, label and message into one string, often shown as a QR code. Wallets read these links to fill in payment details automatically,…
  • BIP 32: Hierarchical Deterministic Wallets: Deployed. Defines hierarchical deterministic (HD) wallets, in which a single seed generates a whole tree of keys. Users can back up a wallet once and share watch-only parts, for example with a shop or…
  • BIP 39: Mnemonic code for generating deterministic keys: Deployed. Defines the recovery phrase: a list of 12 to 24 common words that encodes a wallet's master secret. Users can write the words down to back up and later restore a wallet, a format now widely used…
  • BIP 43: Purpose Field for Deterministic Wallets: Deployed. Reserves the first level of an HD wallet's key tree for a "purpose" number that says which layout the rest of the tree follows. This lets different wallet standards coexist and helps software…
  • BIP 44: Multi-Account Hierarchy for Deterministic Wallets: Deployed. Defines a standard layout for HD wallets that organizes keys by coin type, account, and receiving versus change addresses. Because wallets share this layout, a recovery phrase from one wallet can…