BIP 89: Chain Code Delegation for Private Collaborative Custody

[jurvis]

We propose a new BIP for Chain Code Delegation, a collaborative custody technique that involves privileged participants (delegatee) withholding BIP32 chain codes at key setup time from a delegator, and sharing only enough information for non‑privileged participants to provide their signature.

For non-blinded signing, the delegatee derives a per‑spend scalar tweak t from the (withheld) chain code, the delegator computes the child key (x+t, P+tG), and produces a standard signature over the transaction’s sighash. For blind signing, the nonce and challenge are blinded so the delegator returns a blind Schnorr signature that the counterparty unblinds; thanks to Schnorr’s linearity, the same tweak is incorporated without revealing the final message or linkable details (optionally with predicate proofs for policy).

This enables participants like collaborative custodians to co‑sign when needed, while avoiding the broad visibility that comes with holding an xpub.

More background and discussions can be found: https://delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837.

This is joint work with @jesseposner. Feedback appreciated!

[jonatack]

Looks complete, labelling as needing number assignment.

[jurvis]

@arminsabouri @jonatack thank you for taking the time to review! I've gone ahead and addressed your comments in
9a47c29

[jonatack]

Assigned 89.

Please update the file names and BIP draft headers, including "Created: 2025-12-03" for the date of assignment, and add an entry to the README.

[jurvis]

thanks @jonatack! i think i got everything!

[jonatack]

Thanks for updating.

Final verdict: 95 % LLM-generated or LLM-heavy, with ~5 % human origination of the core idea and final review.

@jurvis can you help me out, please: Is this accurate? I'm trying to adapt our process and understanding.

[jurvis]

hi @jonatack, happy to help. does the scan run through the sample code as well? the sample code contains a lot of boilerplate that we leveraged LLMs to help us with, and may be the reason why it registers high.

However, the contents of the mediawiki itself should be ~90% original. We leaned on LLM use in the mediawiki mostly to ensure that our formatting was aligned with existing conventions (heavily referencing BIP 340, BIP 352, BIP 32, and BIP 3), and to convert it from Markdown, which we had originally used to write our draft.

For example, we wrote out our original one of the algorithms in the following format originally:

Signing
======
When the counterparty requests that the collaborative custodian sign a transaction, it derives the BIP32 scalar tweak from the xpub (i.e. the value `parse_256(I_L)` from BIP32) and provides it to the custodian:

# Inputs:
#   chain_code : 32-byte chain code (hidden from custodian)
#   P_par      : custodian’s parent public key (compressed)
#   i          : child index for spending

I   = HMAC-SHA512(key = chain_code,
                 data = serP(P_par) || ser32(i))
I_L = I[0:32]            # left half
t_i = parse256(I_L)      # scalar tweak mod n
# (I_R would be the child chain code—discarded here.)

# Counterparty → Custodian: send t_i

Which we got ultimately turned into this, to align with how BIP 32 reads:

=== 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<sub>d+1</sub>, …, i<sub>n</sub>) with each i<sub>k</sub> < 2<sup>31</sup>.

<div>
Algorithm ''ComputeBIP32Tweak(P, I)'':
* Inputs:
** ''P'': base public key at depth ''d''
** ''I = (i<sub>d+1</sub>, …, i<sub>n</sub>)'': ordered sequence of non-hardened child indices
* Let ''t = 0'' and ''E = P''.
* For each index ''i'' in ''I'' (from left to right):
** Run the BIP32 non-hardened derivation ''CKDpub'' on ''E'' with child index ''i'', yielding the child extended key ''P<sub>child</sub>'' and its scalar tweak ''δ'' (the parse<sub>256</sub>(''I<sub>L</sub>'') term from BIP32).
** Let ''t = (t + δ) mod n''.
** Let ''E = P<sub>child</sub>''.
* If ''I'' is empty, let ''P′ = P''; otherwise let ''P′ = P<sub>child</sub>'' from the final iteration.
* Return ''(t, P′)''.
</div>

Hope that helps.

[jonatack]

hi @jonatack, happy to help. does the scan run through the sample code as well?

Gave it the BIP draft only.

[jurvis]

hi @jonatack just following up to see if there's anything I can do here to move things along. thanks!

[real-or-random]

The inclusion of major parts of secp256k1lab in this form violates the (only) requirement in the MIT license under which secp256k1lab is distributed, see its COPYING file.

[real-or-random]

A related editorial question is whether it's a good idea to include distributions of secp256k1lab in the BIPs repo. This question is relevant not only for this BIP draft but also for #2070 and for the ChillDKG draft BIP (no PR yet).

We had raised that question in the context of ChillDKG over a year ago on the mailing list, specifically hoping to hear the opinion of the BIPs editors, but noone has commented so far: https://groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ (This post refers to the library as "secp256k1proto". This was our working title before we switched to "secp256k1lab" when publishing the code in a separate repo.)

[murchandamus]

I gave the proposal draft a first read. I find myself somewhat confused as to the terms “Delegator and Delegatee”. The scenario I envisioned was one Delegatee and one or multiple Delegators, but at times it seems that maybe multiple Delegatees are in play. If that’s the case, it could perhaps be clarified what scenarios are covered and how multiple Delegatees would collaborate.
I skipped some of the paragraphs of the Blinded Signing section.

[murchandamus]

I found the terminology confusing here, because the privileged user delegates a co-signing duty, so I initially assumed the term “Delegator” would apply to the privileged user, contrary to how it is defined here.

[murchandamus]

Wouldn’t the receiver of a delegation simply be a “Delegate”?

Suggested change

	* A "Delegatee" is a participant who retains a BIP32 chain code for another participant's base public key and computes derivation tweaks for that participant.
	* A "Delegate" is a participant who retains a BIP32 chain code for another participant's base public key and computes derivation tweaks for that participant.

[murchandamus]

Just checking my understanding: conventionally “quorum” refers to the minimum necessary members of a body to be able to proceed, so I would understand it as referring to only the active participants of a signing rather than the full set of signers, however, this seems potentially contradictory to “any key holder” which makes me wonder whether the full body of key holders is meant instead.

[murchandamus]

It’s not clear to me what “beyond” means here. Is hardened derivation completely forbidden, or just forbidden in the range covering the delegator’s tweak?

[murchandamus]

It’s not clear to me how a Delegator would create a (sighash-default) signature for the transaction without knowing all outputs. Is a sighash/message provided per input? Is this part of the “tweak”?

[murchandamus]

Ah, here is the expected message. Shouldn’t it then be part of the “Delegation Bundle” above then?

[murchandamus]

“Caller” is previously not introduced. Is this a synonym for the Delegatee?

[murchandamus]

“A complete specification of this variant is outside the scope”[…] followed by a fairly detailed description seems a bit contradictory. Either the following sections could be dropped, or this sentence should perhaps be amended to better explain what to expect in the following paragraphs.

[murchandamus]

I thought the Delegatee is the primary owner of the wallet, so wouldn’t it be:

Suggested change

	* Delegatees MUST ensure every delegated path remains non-hardened and that ''ComputeBIP32Tweak'' yields the correct tweak <code>t</code>; incorrect scalars can render funds unspendable by the delegator.
	* Delegatees MUST ensure every delegated path remains non-hardened and that ''ComputeBIP32Tweak'' yields the correct tweak <code>t</code>; incorrect scalars could render the delegator incapable of producing a signature.

[murchandamus]

The Delegator is the privileged user, right? So wouldn’t they be the one that creates the transaction? Why would they need to verify change outputs? Are we talking about multiple delegators?

[murchandamus]

We had raised that question in the context of ChillDKG over a year ago on the mailing list, specifically hoping to hear the opinion of the BIPs editors, but noone has commented so far: https://groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ (This post refers to the library as "secp256k1proto". This was our working title before we switched to "secp256k1lab" when publishing the code in a separate repo.)

@real-or-random: TBH, I don’t think I fully understand the trade-offs of the approaches you proposed. I would prefer that any software with on-going development were maintained outside of the BIPs repository, but maybe we could chat some time so that I better understand the situation.

[real-or-random]

We had raised that question in the context of ChillDKG over a year ago on the mailing list, specifically hoping to hear the opinion of the BIPs editors, but noone has commented so far: groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ (This post refers to the library as "secp256k1proto". This was our working title before we switched to "secp256k1lab" when publishing the code in a separate repo.)

@real-or-random: TBH, I don’t think I fully understand the trade-offs of the approaches you proposed. I would prefer that any software with on-going development were maintained outside of the BIPs repository, but maybe we could chat some time so that I better understand the situation.

Let me try to simplify the discussion: If the BIP editors are okay with integrating a snapshot of secp256klab as a subtree in each bip-xxxx folder of a BIP whose code uses secp256k1lab (as currently proposed in this PR and in #2070), then I'm happy with that. I think it's the best solution.

"Snapshot" means that it is a static thing, and maintenance of secp256k1lab will, of course, happen in its repo. I guess the only reason to ever touch a snapshot subtree in the BIPs repo is to fix a secp256k1 bug that specifically affects the BIP code that uses the library (and even in that case, other ways to resolve the overall issue could be considered).

[murchandamus]

We had raised that question in the context of ChillDKG over a year ago on the mailing list, specifically hoping to hear the opinion of the BIPs editors, but noone has commented so far: groups.google.com/g/bitcoindev/c/HE3HSnGTpoQ/m/Y2VhaMCrCAAJ (This post refers to the library as "secp256k1proto". This was our working title before we switched to "secp256k1lab" when publishing the code in a separate repo.)

@real-or-random: TBH, I don’t think I fully understand the trade-offs of the approaches you proposed. I would prefer that any software with on-going development were maintained outside of the BIPs repository, but maybe we could chat some time so that I better understand the situation.

Let me try to simplify the discussion: If the BIP editors are okay with integrating a snapshot of secp256klab as a subtree in each bip-xxxx folder of a BIP whose code uses secp256k1lab (as currently proposed in this PR and in #2070), then I'm happy with that. I think it's the best solution.

"Snapshot" means that it is a static thing, and maintenance of secp256k1lab will, of course, happen in its repo. I guess the only reason to ever touch a snapshot subtree in the BIPs repo is to fix a secp256k1 bug that specifically affects the BIP code that uses the library (and even in that case, other ways to resolve the overall issue could be considered).

That seems reasonable to me, as it ensures that a functional reference implementation is retained in the context of the BIPs. The only concern that comes to mind would be that we might get more pull requests by LLM-commit farmers on those, but I guess we’d just have to filter those.