BIP 89: Chain Code Delegation for Private Collaborative Custody

jurvis commented at 3:28 am on October 15, 2025: none

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!

Add Chaincode Delegation BIP 4283e3ec57

Update license to BSD-3-Clause and expand blinded signing documentation edb4360fa7

jonatack added the label New BIP on Oct 15, 2025

in bip-chaincode-delegation.mediawiki:391 in edb4360fa7

386+
387+* '''0.1.0''' (2025-10-14): Publication of draft BIP
388+
389+== Acknowledgements ==
390+* Arik Sosman and Wilmer Paulino for the initial discussions and validation of this idea.  
391+* Sanket Kajalkar, Jordan Mecom, Gregory Sanders, ZmnSCPxj, Yuval Krogman, and John Cantrell for code and design review.

arminsabouri commented at 12:44 pm on November 12, 2025:

0* Sanket Kajalkar, Jordan Mecom, Gregory Sanders, ZmnSCPxj, Yuval Kogman, and John Cantrell for code and design review.

in bip-0089.mediawiki:9 in edb4360fa7 outdated

0@@ -0,0 +1,394 @@
1+<pre>
2+BIP: ???? 
3+Layer: Applications
4+Title: Chain Code Delegation
5+Author: Jesse Posner <jesse@vora.io>, Jurvis Tan <jurvis@block.xyz>
6+Status: Draft
7+Type: Standards Track
8+Created: 2025-10-14
9+License: BSD-3-Clause

jonatack commented at 7:23 pm on November 25, 2025:

Suggested header additions (Version is BIP3 only, so only add it if BIP3 is activated:

0Post-History: delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837.
1Version: 0.1.0
2Requires: 32, 340, 341

in bip-chaincode-delegation.mediawiki:385 in edb4360fa7

380+
381+To help implementers understand updates to this document, we attach a version number that resembles ''semantic versioning'' (<code>MAJOR.MINOR.PATCH</code>).
382+The <code>MAJOR</code> version is incremented if changes to the BIP are introduced that are incompatible with prior versions.
383+An exception to this rule is <code>MAJOR</code> version zero (0.y.z) which is for development and does not need to be incremented if backwards incompatible changes are introduced.
384+The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added.
385+The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.).

jonatack commented at 7:41 pm on November 25, 2025:

nit, can probably drop this explanatory text. BIP3 includes a similar explanation for all BIPs, and until then, semver is assumed.

in bip-chaincode-delegation.mediawiki:379 in edb4360fa7

374+== Test Vectors ==
375+A [[bip-chaincode-delegation/vectors|collection of JSON test vectors]] are provided, along with a [[bip-chaincode-delegation/reference.py|python reference implementation]].
376+
377+You may also find example code of CCD in action [https://github.com/jurvis/chaincode-delegation here].
378+
379+== Change Log ==

jonatack commented at 7:42 pm on November 25, 2025:

nit, BIP3 standardizes this title

0== Changelog ==

in bip-chaincode-delegation.mediawiki:375 in edb4360fa7

370+* Delegators MUST verify change outputs when tweak data is provided (for example via ''ChangeOutputVerification'') to avoid authorizing unexpected scripts.
371+* Reusing the same k' (first 32 bytes in blindsecnonce) across two BlindSign calls allows recovery of the base secret key.
372+* When using blinded signing, opening multiple sessions concurrently against the same signer can allow an attacker to learn the base secret key. If concurrency is required, use the concurrently secure variant (encryption + ZK) instead (not specified in this BIP).
373+
374+== Test Vectors ==
375+A [[bip-chaincode-delegation/vectors|collection of JSON test vectors]] are provided, along with a [[bip-chaincode-delegation/reference.py|python reference implementation]].

jonatack commented at 7:43 pm on November 25, 2025:

nit, file naming throughout would be clearer as “chain code” (instead of “chaincode”), per BIP32 usage

0A [[bip-chain-code-delegation/vectors|collection of JSON test vectors]] are provided, along with a [[bip-chaincode-delegation/reference.py|python reference implementation]].

jonatack commented at 7:51 pm on November 25, 2025: member

Looks complete, labelling as needing number assignment.

jonatack added the label Needs number assignment on Nov 25, 2025

Address initial PR comments 9a47c29dd9

jurvis commented at 11:39 pm on November 30, 2025: none

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

in bip-chaincode-delegation.mediawiki:10 in 9a47c29dd9

 5+Author: Jesse Posner <jesse@vora.io>, Jurvis Tan <jurvis@block.xyz>
 6+Status: Draft
 7+Type: Standards Track
 8+Created: 2025-10-14
 9+License: BSD-3-Clause
10+Post-History: delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837.

jonatack commented at 8:36 pm on December 3, 2025:

0Post-History: delvingbitcoin.org/t/chain-code-delegation-private-access-control-for-bitcoin-keys/1837

in bip-0089.mediawiki:387 in 9a47c29dd9 outdated

382+== Changelog ==
383+
384+To help implementers understand updates to this document, we attach a version number that resembles ''semantic versioning'' (<code>MAJOR.MINOR.PATCH</code>).
385+
386+* '''0.1.0''' (2025-10-14): Publication of draft BIP
387+* '''0.1.1''' (2025-11-30): Fix acknowledgments spelling, BIP3 formatting, and use "Chain Code" with a space throughout.

jonatack commented at 8:39 pm on December 3, 2025:

BIP 3: “Changelog section sorted by most recent version first”

jonatack commented at 8:45 pm on December 3, 2025: member

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.

jonatack removed the label Needs number assignment on Dec 3, 2025

jonatack renamed this:
~~BIP: Chain Code Delegation for Private Collaborative Custody~~
BIP 89: Chain Code Delegation for Private Collaborative Custody
on Dec 3, 2025

jurvis force-pushed on Dec 3, 2025

Update with BIP number assignment c5aac26a86

jurvis force-pushed on Dec 3, 2025

jurvis commented at 10:48 pm on December 3, 2025: none

thanks @jonatack! i think i got everything!

jonatack commented at 5:57 pm on December 6, 2025: member

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 commented at 6:11 pm on December 6, 2025: none

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:

 0Signing
 1======
 2When 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:
 3
 4# Inputs:
 5#   chain_code : 32-byte chain code (hidden from custodian)
 6#   P_par      : custodian’s parent public key (compressed)
 7#   i          : child index for spending
 8
 9I   = HMAC-SHA512(key = chain_code,
10                 data = serP(P_par) || ser32(i))
11I_L = I[0:32]            # left half
12t_i = parse256(I_L)      # scalar tweak mod n
13# (I_R would be the child chain code—discarded here.)
14
15# Counterparty → Custodian: send t_i

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

 0=== Tweak Calculation ===
 1To 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>.
 2
 3<div>
 4Algorithm ''ComputeBIP32Tweak(P, I)'':
 5* Inputs:
 6** ''P'': base public key at depth ''d''
 7** ''I = (i<sub>d+1</sub>, …, i<sub>n</sub>)'': ordered sequence of non-hardened child indices
 8* Let ''t = 0'' and ''E = P''.
 9* For each index ''i'' in ''I'' (from left to right):
10** 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).
11** Let ''t = (t + δ) mod n''.
12** Let ''E = P<sub>child</sub>''.
13* If ''I'' is empty, let ''P′ = P''; otherwise let ''P′ = P<sub>child</sub>'' from the final iteration.
14* Return ''(t, P′)''.
15</div>

Hope that helps.

jonatack commented at 6:15 pm on December 6, 2025: member

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

Gave it the BIP draft only.

jurvis commented at 10:33 pm on December 18, 2025: none

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

real-or-random commented at 3:00 pm on January 5, 2026: contributor

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 commented at 4:17 pm on January 5, 2026: contributor

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.)

in bip-0089.mediawiki:25 in c5aac26a86

20+== Motivation ==
21+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.
22+
23+== Terminology ==
24+* 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.
25+* A "Delegator" is a participant who holds only a non-extended keypair and receives scalar tweaks from a delegatee when asked to sign.

murchandamus commented at 11:05 pm on January 5, 2026:

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.

jesseposner commented at 7:23 pm on January 7, 2026:

In the context of chain code delegation, the thing that is being delegated is the chain code itself, and typically the chain code “belongs” to the entity that generated it. So the co-signer is delegating its chain code to the privileged user.

But totally understand why that might be confusing, we can either clarify that in the BIP or switch to different terms if there’s something better.

in bip-0089.mediawiki:24 in c5aac26a86

19+
20+== Motivation ==
21+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.
22+
23+== Terminology ==
24+* 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.

murchandamus commented at 11:12 pm on January 5, 2026:

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

0* 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.

jesseposner commented at 7:28 pm on January 7, 2026:

A delegate is a representative. The term delegatee is more specific, it means the recipient of a delegation, and is the counterpart to a delegator. Delegator/delegatee pair each other more precisely than delegator/delegate.

Also, delegate has an ambiguity between its noun/verb forms.

in bip-0089.mediawiki:26 in c5aac26a86

21+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.
22+
23+== Terminology ==
24+* 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.
25+* A "Delegator" is a participant who holds only a non-extended keypair and receives scalar tweaks from a delegatee when asked to sign.
26+* A "Participant" is any key holder in the wallet quorum (including delegators and delegatees).

murchandamus commented at 11:19 pm on January 5, 2026:

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.

jesseposner commented at 7:32 pm on January 7, 2026:

Good point, quorum isn’t the right term here.

0* A "Participant" is any key holder that can co-sign for UTXOs in the wallet (including delegators and delegatees).

in bip-0089.mediawiki:38 in c5aac26a86

33+
34+=== Key material and setup ===
35+* '''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.
36+* '''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.
37+* '''Other participants:''' Non-delegator participants use conventional extended keys and share the public half as appropriate for the wallet descriptor.
38+* '''Derivation constraints:''' All key paths used with CCD MUST be non-hardened beyond the depth visible to the delegator. Hardened steps prevent computation of the needed tweak and are therefore NOT supported.

murchandamus commented at 11:25 pm on January 5, 2026:

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?

jesseposner commented at 7:35 pm on January 7, 2026:

Just forbidden in the range covering the delegator’s tweek, which is a better way of putting it.

in bip-0089.mediawiki:98 in c5aac26a86

93+Any attempt to apply a hardened derivation (index ≥ 2<sup>31</sup>) MUST fail. Delegatees MAY discard P′ after extracting t if it is not otherwise required.
94+
95+=== Delegation Bundle ===
96+CCD requires the delegatee to provide per-participant tweaks for inputs and (optionally) change outputs. Change outputs are only required if a delegator wants to be able to compute the amount of bitcoin they are spending. 
97+
98+A delegatee MUST provide each delegator with, for every signing context, a collection of tuples (P<sub>i</sub>, t<sub>i</sub>) where P<sub>i</sub> is the participant's base public key disclosed to the delegator and t<sub>i</sub> is the aggregated tweak returned by ''ComputeBIP32Tweak''. The scalar t<sub>i</sub> MUST be encoded as a 32-byte big-endian integer.

murchandamus commented at 0:01 am on January 6, 2026:

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”?

jesseposner commented at 7:38 pm on January 7, 2026:

This is meant to be referring to the tweak for the change output not the output itself:

0CCD 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. 
1
2A delegatee MUST provide each delegator with, for every signing context, a collection of tuples (P<sub>i</sub>, t<sub>i</sub>) where P<sub>i</sub> is the participant's base public key disclosed to the delegator and t<sub>i</sub> is the aggregated tweak returned by ''ComputeBIP32Tweak''. The scalar t<sub>i</sub> MUST be encoded as a 32-byte big-endian integer.

in bip-0089.mediawiki:104 in c5aac26a86

 99+
100+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.
101+
102+Delegators use the supplied CCD tweak bundle during verification (see ''Delegator input and change verification'') and signature generation (see ''DelegatorSign'').
103+
104+=== Delegatee Signing ===

murchandamus commented at 0:06 am on January 6, 2026:

0=== Delegator Signing ===

The Delegatee has all data anyway, shouldn’t this be “Delegator Signing”? We are talking about the non-privileged user, right?

in bip-0089.mediawiki:112 in c5aac26a86

107+* '''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.
108+
109+Both modes produce valid BIP340 signatures.
110+
111+====Non-Blinded Signing====
112+For non-blinded signing, the delegatee can apply the signatures as usual.

murchandamus commented at 0:17 am on January 6, 2026:

I’m a little lost. Who is signing now? I would expect that only the delegator needs special treatment?

0For non-blinded signing, the delegator can apply the signatures as usual.

If I’m not the only one that is confused regarding Delegator and Delegatee, maybe terms that are more distinct would help?

in bip-0089.mediawiki:157 in c5aac26a86

152+* Let ''D′'' be the descriptor formed by substituting every occurrence of ''P<sub>i</sub>'' in ''D'' with ''P′<sub>i</sub>''.
153+* Derive the witness script ''W′'' from ''D′''.
154+* Return <code>true</code> if ''W′ = W'', otherwise <code>false</code>.
155+</div>
156+
157+Successful verification ensures the change output commits to the tweaked participant keys implied by the CCD tweaks, preserving the intended policy.

murchandamus commented at 0:20 am on January 6, 2026:

Wouldn’t the Delegator also need the recipient output? Otherwise the remainder of the funds could be sent to fees?

in bip-0089.mediawiki:167 in c5aac26a86

162+<div>
163+Algorithm ''DelegatorSign(t, x, m)'':
164+* Inputs:
165+** ''t'': aggregated tweak for the signing context (scalar mod ''n'')
166+** ''x'': delegator base secret key
167+** ''m'': message to be signed (for example, a transaction digest under the desired SIGHASH policy)

murchandamus commented at 0:23 am on January 6, 2026:

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

in bip-0089.mediawiki:173 in c5aac26a86

168+* Let ''x′ = (x + t) mod n''.
169+* Use secret key ''x′'' to produce the required signature ''σ'' under the indicated policy.
170+* Return ''σ''.
171+</div>
172+
173+The caller is responsible for inserting ''σ'' into the surrounding protocol (e.g., a PSBT, transaction witness, or adaptor signature exchange).

murchandamus commented at 0:25 am on January 6, 2026:

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

in bip-0089.mediawiki:184 in c5aac26a86

179+
180+The output signature is a BIP340 Schnorr signature valid under an X‑only key obtained by applying a sequence of plain (e.g. BIP32) and X‑only (e.g. Tapscript) tweaks to the signer’s plain public key. Consequently the protocol is compatible with [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341]. The delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'.
181+
182+The plain protocol here is '''not''' concurrently secure. A signer '''MUST NOT''' run multiple blind signing sessions in parallel or interleave state across sessions. A signer '''MUST''' refuse any new blind‑nonce requests while a previous blind‑signature request is outstanding, or '''MUST''' irrevocably discard (and never reuse) any in‑flight blind nonce commitments that have not resulted in a signature, before accepting new ones.
183+
184+To obtain concurrency security as in ([https://eprint.iacr.org/2022/1676 ePrint 2022/1676]), the delegatee first sends an encryption of (m, a, b) before the signer commits to the blind nonce; later, the delegatee includes a zero‑knowledge proof binding the produced challenge to that encrypted tuple. That proof can additionally encode policy predicates about m (spend limits, velocity controls, etc.). A complete specification of this variant is outside the scope of this BIP.

murchandamus commented at 0:31 am on January 6, 2026:

“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.

jesseposner commented at 7:49 pm on January 7, 2026:

I’ll make this more clear, but the idea is that the variant (i.e. concurrently secure) is outside the scope of the BIP. The scheme that is not concurrently secure is very much within the scope of the BIP, and that’s what is described in the following sections.

in bip-0089.mediawiki:374 in c5aac26a86

369+* Return the BIP340 signature ''sig = xbytes(R) || bytes(32, s)''
370+</div>
371+
372+== Security Considerations ==
373+* Exposure of any delegated tweak scalar <code>t</code> enables signing only for the specific child key(s) that scalar was derived for, and is typically short-lived if disclosed immediately before spending.
374+* 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.

murchandamus commented at 0:33 am on January 6, 2026:

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

0* 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.

in bip-0089.mediawiki:375 in c5aac26a86

370+</div>
371+
372+== Security Considerations ==
373+* Exposure of any delegated tweak scalar <code>t</code> enables signing only for the specific child key(s) that scalar was derived for, and is typically short-lived if disclosed immediately before spending.
374+* 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.
375+* Delegators MUST verify change outputs when tweak data is provided (for example via ''ChangeOutputVerification'') to avoid authorizing unexpected scripts.

murchandamus commented at 0:34 am on January 6, 2026:

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 commented at 0:38 am on January 6, 2026: contributor

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 commented at 0:44 am on January 6, 2026: contributor

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 commented at 7:36 am on January 6, 2026: contributor

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 commented at 10:15 pm on January 6, 2026: contributor

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.

jesseposner commented at 7:52 pm on January 7, 2026: none

@murchandamus Thanks for the detailed review, I will revise accordingly. I agree that delegatee/delgator is confusing, but I’m not sure what the better terminology is. @real-or-random I’ll make sure to include the copyright and permission notice which I believe will satisfy the license requirements for secp256k1lab.

real-or-random commented at 1:10 pm on January 8, 2026: contributor

@real-or-random I’ll make sure to include the copyright and permission notice which I believe will satisfy the license requirements for secp256k1lab.

Yep, thanks, and no offense, by the way. :) I just think it’s good practice to keep licenses with the code. It helps everyone later on. I suggest just including the existing COPYING file. And I think it would also be very useful to future readers of the BIP to note somewhere from which commit the files are taken, (e.g., have a sentence in the BIP, in some README file, or added to the top of the COPYING file) such as The contents of this directory are taken from https://github.com/secp256k1lab/secp256k1lab commit id 01234567890abcdef....

murchandamus added the label PR Author action required on Jan 8, 2026

murchandamus commented at 8:48 pm on January 8, 2026: contributor

Hopefully the last comment on the secp-library discussion in your PR: Let’s continue that conversation in https://github.com/bitcoin/bips/pull/1855

BIP 89: Chain Code Delegation for Private Collaborative Custody #2004