Chain Code Delegation

  BIP: 89
  Layer: Applications
  Title: Chain Code Delegation
  Authors: Jesse Posner 
           Jurvis Tan 
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0089
  Status: Draft
  Type: Specification
  Assigned: 2025-12-03
  License: BSD-3-Clause
  Discussion: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837
  Requires: 32, 340, 341

Abstract

Chain Code Delegation (CCD) is a method for multi-signature wallets in which a privileged participant withholds BIP32 chain codes from one or more non-privileged participants, and supplies per-input scalar tweaks at signing time. This allows non-privileged participants to co-sign transactions without learning wallet-wide derivations, balances, or signing activity from other spending combinations. CCD defines the tweak exchange needed for verification and signing behavior when the signer does not possess a chain code.

Motivation

In multisig deployments, sharing extended public keys (xpubs) or descriptors enables all participants to scan the chain and infer counterparties' activity. CCD limits that visibility by ensuring non-privileged participants only ever hold a non-extended keypair and only receive the minimum per-spend data needed to sign. The procedure keeps policy enforcement feasible for the non-privileged signer while preserving balance privacy, which is particularly useful in collaborative custody arrangements where the wallet owner wants balance privacy from their custodian.

Terminology

In CCD, the chain code is the object of delegation—not signing authority. A participant who gives up their chain code delegates it to another.

• A "Delegator" is a participant who delegates their chain code to another party. They hold only a non-extended keypair and receive scalar tweaks from the delegatee when asked to sign.
• A "Delegatee" is a participant who receives and retains a delegated chain code for another participant's public key, and computes derivation tweaks for that participant.
• A "Participant" is any key holder that can co-sign for UTXOs in the wallet (including delegators and delegatees).
• A "Non-hardened derivation" is a BIP32 child derivation where index < 2^31.

Overview

CCD operates by having Delegatees deprive Delegators of BIP32 chain codes during setup and later conveying the aggregated scalar tweak computed as the sum of non-hardened derivation tweaks along the remaining path to the child key used by a given input or change output. A Delegator uses the tweak to compute the child keys for verification and signing without being able to derive or recognize keys for other paths.

Specification

Key material and setup

• Delegator key: Each delegator generates a standard (non-extended) secp256k1 keypair and provides the public key to the counterparties. A delegator MUST NOT retain or be provided a chain code for this key.
• Delegated chain code: A designated delegatee computes and retains a BIP32 chain code bound to the delegator's public key, forming an xpub that MUST NOT be disclosed to the delegator. The delegatee MAY share this xpub with other delegatees.
• Other participants: Non-delegator participants use conventional extended keys and share the public half as appropriate for the wallet descriptor.
• Derivation constraints: The delegatee holds an extended public key for the delegator. All derivation from this extended key MUST be non-hardened, as hardened derivation requires the private key, which the delegatee does not possess.

Notation

The following conventions are used, with constants as defined for secp256k1. We note that adapting this proposal to other elliptic curves is not straightforward and can result in an insecure scheme.

• Lowercase variables represent integers or byte arrays.

** The constant p refers to the field size, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F. ** The constant n refers to the curve order, 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.

• Uppercase variables refer to points on the curve with equation y² = x³ + 7 over the integers modulo p.

** is_infinite(P) returns whether P is the point at infinity. ** x(P) and y(P) are integers in the range 0..p-1 and refer to the X and Y coordinates of a point P (assuming it is not infinity). ** The constant G refers to the base point, for which x(G) = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 and y(G) = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8. ** Addition of points refers to the usual elliptic curve group operation. ** Multiplication (⋅) of an integer and a point refers to the repeated application of the group operation.

• Functions and operations:

** || refers to byte array concatenation. ** The function x[i:j], where x is a byte array and i, j ≥ 0, returns a (j - i)-byte array with a copy of the i-th byte (inclusive) to the j-th byte (exclusive) of x. ** The function bytes(n, x), where x is an integer, returns the n-byte encoding of x, most significant byte first. ** The constant empty_bytestring refers to the empty byte array. It holds that len(empty_bytestring) = 0. ** The function xbytes(P), where P is a point for which not is_infinite(P), returns bytes(32, x(P)). ** The function len(x) where x is a byte array returns the length of the array. ** The function has_even_y(P), where P is a point for which not is_infinite(P), returns y(P) mod 2 == 0. ** The function with_even_y(P), where P is a point, returns P if is_infinite(P) or has_even_y(P). Otherwise, with_even_y(P) returns -P. ** The function cbytes(P), where P is a point for which not is_infinite(P), returns a || xbytes(P) where a is a byte that is 2 if has_even_y(P) and 3 otherwise. ** The function int(x), where x is a 32-byte array, returns the 256-bit unsigned integer whose most significant byte first encoding is x. ** The function lift_x(x), where x is an integer in range 0..2²⁵⁶-1, returns the point P for which x(P) = x and has_even_y(P), or fails if x is greater than p-1 or no such point exists. The function lift_x(x) is equivalent to the following pseudocode: *** Fail if x > p-1. *** Let c = x³ + 7 mod p. *** Let y' = c^(p+1)/4 mod p. *** Fail if c ≠ y'² mod p. *** Let y = y' if y' mod 2 = 0, otherwise let y = p - y' . *** Return the unique point P such that x(P) = x and y(P) = y. ** The function cpoint(x), where x is a 33-byte array (compressed serialization), sets P = lift_x(int(x[1:33])) and fails if that fails. If x[0] = 2 it returns P and if x[0] = 3 it returns -P. Otherwise, it fails. ** The function hash256_tag(x) where tag is a UTF-8 encoded tag name and x is a byte array returns the 32-byte hash SHA256(SHA256(tag) || SHA256(tag) || x). ** The function hash512_tag(x) where tag is a UTF-8 encoded tag name and x is a byte array returns the 64-byte hash SHA512(SHA512(tag) || SHA512(tag) || x).

• Other:

** Tuples are written by listing the elements within parentheses and separated by commas. For example, (2, 3, 1) is a tuple.

Tweak Calculation

To produce CCD tweak data, a delegatee computes a per-participant scalar that aggregates the non-hardened derivation tweaks along the remaining path. Let the extended key retained by the delegatee be P at depth d, and let the target index vector be I = (i_d+1, …, i_n) with each i_k < 2³¹.

Any attempt to apply a hardened derivation (index ≥ 2³¹) MUST fail. Delegatees MAY discard P′ after extracting t if it is not otherwise required.

Delegation Bundle

CCD requires the delegatee to provide per-participant tweaks for inputs and (optionally) change outputs. Tweaks for change outputs are only required if a delegator wants to be able to compute the amount of bitcoin they are spending.

A delegatee MUST provide each delegator with, for every signing context, a collection of tuples (P_i, t_i) where P_i is the participant's base public key disclosed to the delegator and t_i is the aggregated tweak returned by ComputeBIP32Tweak. The scalar t_i MUST be encoded as a 32-byte big-endian integer.

The transport that carries this bundle is out of scope for this proposal; implementers MAY use PSBT proprietary keys, RPC payloads, or bespoke messages as long as the delegator can authenticate the origin of the data. Delegatees SHOULD attach the witness script (or sufficient script template information) built with the tweaked keys when the delegator is expected to verify the input or enforce spending policy on change outputs.

Delegators use the supplied CCD tweak bundle during verification (see Delegator input and change verification) and signature generation (see DelegatorSign). The message to be signed is provided separately as part of the standard signing protocol and is not part of the CCD-specific bundle.

Signing Modes

This BIP supports two modes:

• Non‑blinded. The delegator receives the tweak for the child public key and the message. The delegator learns only about the specific child keys and transactions it signs for; it does not learn the wider address space.
• Blinded. The delegator receives only a blinded challenge and parity bits. The delegator learns nothing about the message or child key for which it produces a signature.

Both modes produce valid BIP340 signatures.

Non-Blinded Signing

For non-blinded signing, the delegator can produce signatures as usual using the tweaked key.

=Delegator input and change verification (Optional)

= A delegator MAY validate the data it receives before producing signatures.

For example, input verification reassures the delegator that every tweaked key they are asked to sign for corresponds to a wallet input they recognise. Change verification lets them establish the net outflow and enforce spending policy.

Both checks rely on the same delegated tweak bundle described above.

=Input verification

= For each input, the delegatee SHOULD disclose the descriptor template, the untweaked participant keys, the input witness script, and the per-participant tweaks. The delegator then applies the following procedure.

Successful verification of an input confirms that the delegator is signing for a script that belongs to the wallet and that the aggregate tweak values align with the expected policy.

=Change-output verification

= When change outputs are disclosed, the delegator can perform an analogous check to ensure the destination script matches their policy template and to calculate outflows. Let D be the descriptor expressed in untweaked keys, W the provided witness script, and T the tweak mapping:

Successful verification ensures the change output commits to the tweaked participant keys implied by the CCD tweaks, preserving the intended policy.

The delegator may perform addition