Chain Code Delegation 2-of-3 Multisig Example

Example code for BIP 89: Chain Code Delegation.

Why Chain Code Delegation?

In most multisig wallets, the easiest way to coordinate is to share descriptors and/or extended public keys (xpubs). An xpub isn't just a spending key, but a deterministic way of mapping out a wallet: it lets you derive wallet addresses, and scan the chain to reconstruct transaction history and balances.

That's great when all signers are the same entity, but it's a leaky default when the signers are different parties or roles, because cosigning comes with the ability to monitor entire wallets. Chain Code Delegation (CCD) allows non-privileged participants to keep the signing role, while tightening that information boundary.

Instead of giving a signer an xpub (public key + BIP 32 chain code), a delegatee withholds the chain code, and hands the delegator only a plain keypair. When a specific input needs a signature, the delegatee computes and sends a per-input scalar tweak (effectively the remaining non-hardened BIP 32 derivation delta along the path), so the delegator can derive the exact child signing key needed for only that spend and produce a valid signature.

The privacy win is straightforward: the delegator learns only what’s implied by the particular transaction they’re asked to approve, not the wallet’s broader derivation tree, address set, or unrelated activity. At the same time, CCD can still support policy checks by including enough script/descriptor context for the delegator to verify “this key belongs to our policy” (and optionally validate change outputs to reason about net outflow).

That’s why CCD is a natural fit for collaborative custody, cross-entity quorums, and any “least-privilege” multisig design where signature authority shouldn’t automatically grant audit-style visibility.

What's In Here

There are a few critical pieces demonstrated here:

1. Key data, and their corresponding derivations needed by the collaborative custodian on onboarding.
2. Per-input tweak calculation by the App.
3. The tweaks would then be used by the Server to (1) tweak its base private key for signing (2) tweak the HW and App's base public key for validating that the witness script matches what is expected.

Usage

• Run just start to start requisite bitcoind container.
• Run cargo run to execute the sample.

Relevant Links

Chain Code Delegation: Private Access Control for Bitcoin Keys: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837