--- bip: 89 title: "Chain Code Delegation" status: Deployed type: Specification layer: "Applications" authors: ["Jesse Posner","Jurvis Tan"] assigned: 2025-12-03 last_modified: 2026-09-15 requires: [32,340,341] topics: ["wallets","signatures","transactions"] license: "BSD-3-Clause" url: https://bipexplorer.com/bip/89 source: https://github.com/bitcoin/bips/blob/master/bip-0089.mediawiki --- # BIP 89: Chain Code Delegation > **In plain English:** Describes a technique for multisignature wallets in which one main participant keeps certain key-derivation information to themselves and gives co-signers only what they need for each signature. Co-signers, such as a backup service, can still approve transactions without learning the wallet's full balance or history, improving privacy. ## 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](https://www.secg.org/sec2-v2.pdf). 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 _y2 = x3 + 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](https://en.wikipedia.org/wiki/Elliptic_curve#The_group_law). - [Multiplication (⋅) of an integer and a point](https://en.wikipedia.org/wiki/Elliptic_curve_point_multiplication) 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..2256\-1_, returns the point _P_ for which _x(P) = x_ Given a candidate X coordinate _x_ in the range _0..p-1_, there exist either exactly two or exactly zero valid Y coordinates. If no valid Y coordinate exists, then _x_ is not a valid X coordinate either, i.e., no point _P_ exists for which _x(P) = x_. The valid Y coordinates for a given candidate _x_ are the square roots of _c = x3 + 7 mod p_ and they can be computed as _y = ±c(p+1)/4 mod p_ (see [Quadratic residue](https://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus)) if they exist, which can be checked by squaring and comparing with _c_. 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 = x3 + 7 mod p_. - Let _y' = c(p+1)/4 mod p_. - Fail if _c ≠ y'2 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 _hash256tag(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 _hash512tag(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 = (id+1, …, in) with each ik < 231. Algorithm _ComputeBIP32Tweak(P, I)_: - Inputs: - _P_: base public key at depth _d_ - _I = (id+1, …, in)_: 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 _Pchild_ and its scalar tweak _δ_ (the parse256(_IL_) term from BIP32). - Let _t = (t + δ) mod n_. - Let _E = Pchild_. - If _I_ is empty, let _P′ = P_; otherwise let _P′ = Pchild_ from the final iteration. - Return _(t, P′)_. Any attempt to apply a hardened derivation (index ≥ 231) 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 (Pi, ti) where Pi is the participant's base public key disclosed to the delegator and ti is the aggregated tweak returned by _ComputeBIP32Tweak_. The scalar ti 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. Algorithm _InputVerification(D, W, T)_: - Inputs: - _D_: wallet policy or descriptor template expressed in terms of the untweaked participant keys _Pi_ - _W_: witness script disclosed for the input under review - _T_: mapping from each _Pi_ to a 32-byte big-endian tweak scalar _ti_ - For each participant key _Pi_ referenced in _D_: - Retrieve _ti_ from _T_; fail if the entry is missing or malformed. - If the verifier controls the corresponding private key _di_, let _d′i = (di + ti) mod n_ and _P′i = d′i · G_; otherwise let _P′i = Pi + ti · G_. - Let _D′_ be the descriptor formed by substituting every occurrence of _Pi_ in _D_ with _P′i_. - Derive the witness script _W′_ from _D′_. - Return `true` if _W′ = W_, otherwise `false`. 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: Algorithm _ChangeOutputVerification(D, W, T)_: - Inputs: - _D_: wallet policy or descriptor template expressed in terms of the untweaked participant keys _Pi_ - _W_: witness script disclosed for the change output - _T_: mapping from each _Pi_ to a 32-byte big-endian tweak scalar _ti_ - For each participant key _Pi_ referenced in _T_: - Retrieve _ti_ from _T_; fail if the entry is missing or malformed. - If the verifier controls the corresponding private key _di_, let _d′i = (di + ti) mod n_ and _P′i = d′i · G_; otherwise let _P′i = Pi + ti · G_. - Let _D′_ be the descriptor formed by substituting every occurrence of _Pi_ in _D_ with _P′i_. - Derive the witness script _W′_ from _D′_. - Return `true` if _W′ = W_, otherwise `false`. 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 additional application-specific verification on the transaction (e.g., recipient addresses, amounts, compliance checks) using the message _m_. In the concurrently secure blinded mode, such policies can be enforced via zero-knowledge proofs that encode predicates about _m_. Specification of such policies is outside the scope of this BIP. ##### Delegator Signing A delegator that holds only its base secret key `x` and public key `P` uses the delegated tweak bundle to derive per-input signing keys. The delegator MAY first call _InputVerification_ and _ChangeOutputVerification_ on any input and change output that provides a tweak in order to confirm outflow or policy requirements before signing. Algorithm _DelegatorSign(t, x, m)_: - Inputs: - _t_: aggregated tweak for the signing context (scalar mod _n_) - _x_: delegator base secret key - _m_: message to be signed (for example, a transaction digest under the desired SIGHASH policy) - Let _x′ = (x + t) mod n_. - Use secret key _x′_ to produce the required signature _σ_ under the indicated policy. - Return _σ_. The delegatee is responsible for inserting _σ_ into the surrounding protocol (e.g., a PSBT, transaction witness, or adaptor signature exchange). #### Blinded Signing The delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'. This blind‑signing protocol specifies how a delegator can produce a blind partial Schnorr signature that a delegatee can unblind into a standard [BIP340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) signature under a possibly tweaked X‑only public key. The notation, algorithmic patterns, and test‑vector style are adapted from \[BIP‑327 (MuSig2)\] and from the [FROST Signing BIP](https://github.com/siv2r/bip-frost-signing). The design follows the “plain” blind Schnorr flow described in Concurrently Secure Blind Schnorr Signatures ([ePrint 2022/1676](https://eprint.iacr.org/2022/1676)), but without the concurrency hardening from that work. 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 [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki). The delegator learns neither the message, the challenge, or the public key used in the BIP340 signature, only a blinded challenge e'. 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. To obtain concurrency security as in ([ePrint 2022/1676](https://eprint.iacr.org/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. The following sections fully specify the non-concurrent blind signing protocol. ##### Overview - **Round 1 (blind nonce).** The delegator runs _BlindNonceGen_ to produce _blindsecnonce_ and _blindpubnonce_ and sends _blindpubnonce_ to the delegatee. - **Round 2 (challenge).** The delegatee runs _BlindChallengeGen_ using the message _m_, _blindpubnonce_, the base public key _pk_, and a list of ordinary and X-only tweaks, to produce a _session context_ (kept locally for unblinding), a _blindchallenge_, and two booleans _pk\_parity_ and _nonce\_parity_. The delegatee sends _blindchallenge_, _pk\_parity_, and _nonce\_parity_ to the signer. - **Round 3 (blind signature).** The delegator runs _BlindSign_ with _sk_, _blindchallenge_, _blindsecnonce_, _pk\_parity_, and _nonce\_parity_ and returns _blindsignature_. The delegatee completes by calling _UnblindSignature_ with the stored session context and _blindsignature_ to obtain the final BIP340 signature _sig_. _BlindSign_ **MUST NOT** be executed twice with the same _blindsecnonce_. As a defense, implementations **SHOULD** overwrite the first 64 bytes of _blindsecnonce_ with zeros after they have been read by _BlindSign_. ##### Key Tweaking ###### Tweak Context The Tweak Context is a data structure consisting of the following elements: - The point _Q_ representing the potentially tweaked public key: an elliptic curve point - The accumulated tweak _tacc_: an integer with _0 ≤ tacc < n_ - The value _gacc_ : 1 or -1 mod n We write "Let _(Q, gacc, tacc) = tweak\_ctx_" to assign names to the elements of a Tweak Context. Algorithm _TweakCtxInit(pk)_: - Input: - The base public key pk: a 33-byte array - Let _Q = cpoint(pk)_ - Fail if _is\_infinite(Q)_ - Let _gacc = 1_ - Let _tacc = 0_ - Return _tweak\_ctx = (Q, gacc, tacc)_ Algorithm _ApplyTweak(tweak\_ctx, tweak, is\_xonly\_t)_: - Inputs: - The _tweak\_ctx_: a [Tweak Context](#tweak-context) data structure - The _tweak_: a 32-byte array - The tweak mode _is\_xonly\_t_: a boolean - Let _(Q, gacc, tacc) = tweak\_ctx_ - If _is\_xonly\_t_ and _not has\_even\_y(Q)_: - Let _g = -1 mod n_ - Else: - Let _g = 1_ - Let _t = int(tweak)_; fail if _t ≥ n_ - Let _Q' = g⋅Q + t⋅G_ - Fail if _is\_infinite(Q')_ - Let _gacc' = g⋅gacc mod n_ - Let _tacc' = t + g⋅tacc mod n_ - Return _tweak\_ctx' = (Q', gacc', tacc')_ ##### Blind Nonce Generation Algorithm _BlindNonceGen(sk, pk, aggpk, m, extra\_in)_: - Inputs: - The base secret signing key _sk_: a 32-byte array (optional argument) - The base public key _pk_: a 33-byte array (optional argument) - The auxiliary input _extra\_in_: a byte array with _0 ≤ len(extra\_in) ≤ 232\-1_ (optional argument) - Let _rand'_ be a 32-byte array freshly drawn uniformly at random - If the optional argument _sk_ is present: - Let _rand_ be the byte-wise xor of _sk_ and _hash256CCD/aux(rand')_[1] - Else: - Let _rand = rand'_ - If the optional argument _extra\_in_ is not present: - Let _extra\_in = empty\_bytestring_ - Let _k' = int(hash256CCD/blindnonce(rand || bytes(1, len(pk)) || pk || bytes(4, len(extra\_in)) || extra\_in )) mod n_ - Fail if _k' = 0_ - Let _R' = k'⋅G_ - Let _blindpubnonce = cbytes(R')_ - Let _blindsecnonce = bytes(32, k' || pk)_The algorithms as specified here assume that the _blindsecnonce_ is stored as a 65-byte array using the serialization _blindsecnonce = bytes(32, k') || pk_. The same format is used in the reference implementation and in the test vectors. However, since the _blindsecnonce_ is not meant to be sent over the wire, compatibility between implementations is not a concern, and this method of storing the _blindsecnonce_ is merely a suggestion. The _blindsecnonce_ is effectively a local data structure of the signer which comprises the value double _(k', pk)_, and implementations may choose any suitable method to carry it from _BlindNonceGen_ (first communication round) to _BlindSign_ (third communication round). In particular, implementations may choose to hide the _blindsecnonce_ in internal state without exposing it in an API explicitly, e.g., in an effort to prevent callers from reusing a _blindsecnonce_ accidentally. - Return _(secnonce, pubnonce)_ ##### Session Context The Session Context is a data structure consisting of the following elements: - The base public key _pk_: a 33-byte array - The blind factor _blindfactor_: a 32-byte array - The challenge hash _challenge_: a 32-byte array - The public nonce _pubnonce_: a 33-byte array - The number _v_ of tweaks with _0 ≤ v < 2^32_ - The tweaks _tweak1..v_: _v_ 32-byte arrays - The tweak modes _is\_xonly\_t1..v_ : _v_ booleans We write "Let _(pk, blindfactor, challenge, pubnonce, v, tweak1..v, is\_xonly\_t1..v) = session\_ctx_" to assign names to the elements of a Session Context. Algorithm _GetSessionValues(session\_ctx)_: - Let _(pk, blindfactor, challenge, pubnonce, v, tweak1..v, is\_xonly\_t1..v) = session\_ctx_ - Let _tweak\_ctx0 = TweakCtxInit(pk)_; fail if that fails - For _i = 1 .. v_: - Let _tweak\_ctxi = ApplyTweak(tweak\_ctxi-1, tweaki, is\_xonly\_ti)_; fail if that fails - Let _(Q, gacc, tacc) = tweak\_ctxv_ - Let _a = int(blindfactor)_; fail if _a ≥ n_ - Let _b = int(blindfactor)_; fail if _b ≥ n_ - Let _e = int(challenge)_; fail if _e ≥ n_ - Let _R = cpoint(pubnonce)_; fail if that fails - Return _(Q, gacc, tacc, a, e, R)_ ##### Blind Challenge Generation Algorithm _BlindChallengeGen(m, blindpubnonce, pk, tweak1..v, is\_xonly1..v, extra\_in)_: - Inputs: - The message _m_: a byte array - The blind public nonce _blindpubnonce_: a 33-byte array - The base public key _pk_: a 33-byte array - The tweaks _tweak1..v_: _v_ 32-byte arrays - The tweak modes _is\_xonly1..v_: _v_ booleans - The auxiliary input _extra\_in_: a byte array with _0 ≤ len(extra\_in) ≤ 232\-1_ (optional argument) - If _extra\_in_ is not present: - Let _extra\_in = empty\_bytestring_ - Let _(Q, gacc, tacc) = TweakCtxInit(pk)_ - For _i = 1 .. v_: - Let _(Q, gacc, tacc) = ApplyTweak((Q, gacc, tacc), tweaki, is\_xonlyi)_; fail if that fails - Let _cpk = cbytes(Q)_ - Draw 32 random bytes _rand_ - Let _z = hash512CCD/blindfactor(rand || bytes(1, len(cpk)) || cpk || bytes(1, len(blindpubnonce)) || blindpubnonce || bytes(8, len(m)) || m || bytes(4, len(extra\_in)) || extra\_in)_ - Let _a' = int(z\[0:32\]) mod n_; fail if _a' = 0_ - Let _b' = int(z\[32:64\]) mod n_; fail if _b' = 0_ - Let _g = 1_ if _has\_even\_y(Q)_, else _g = −1 mod n_ - Let _pk\_parity = (g⋅gacc mod n == 1)_ - Let _X' = cpoint(pk)_; let _X = X'_ if _pk\_parity_ else _−X'_ - Let _R' = cpoint(blindpubnonce)_ - Let _R = R' + a'⋅G + b'⋅X_; fail if _is\_infinite(R)_ - Let _nonce\_parity = has\_even\_y(R)_ - If _nonce\_parity_: - Let _a = a'_ , _b = b'_ - Else: - Let _a = n − a'_ , _b = n − b'_ - Let _e = int(hashBIP0340/challenge(xbytes(R) || xbytes(Q) || m)) mod n_ - Let _e' = (e + b) mod n_ - Let _session\_ctx = (pk, bytes(32, a), bytes(32, e), cbytes(R), tweak1..v, is\_xonly1..v)_ - Return _(session\_ctx, bytes(32, e'), pk\_parity, nonce\_parity)_ ##### Blind Signing Algorithm _BlindSign(sk, blindchallenge, blindsecnonce, pk\_parity, nonce\_parity)_: - Inputs: - The secret key _sk_: a 32-byte array - The blind challenge _blindchallenge_: a 32-byte array _e'_ - The secret nonce _blindsecnonce_: a byte array whose first 32 bytes are _k_ (remaining bytes are implementation-defined) - _pk\_parity_: boolean (from _BlindChallengeGen_) - _nonce\_parity_: boolean (from _BlindChallengeGen_) - Let _d' = int(sk)_; fail if _d' = 0_ or _d' ≥ n_ - Let _P = d'⋅G_; fail if _is\_infinite(P)_ - Let _d = d'_ if _pk\_parity_ else _n − d'_ - Let _e' = int(blindchallenge)_; fail if _e' ≥ n_ - Let _k' = int(blindsecnonce\[0:32\])_; fail if _k' = 0_ or _k' ≥ n_ - Let _k = k'_ if _nonce\_parity_ else _n − k'_ - Overwrite _blindsecnonce\[0:64\]_ with 64 zero bytes[2] - Let _R' = k'⋅G_; fail if _is\_infinite(R')_[3] - Let _s' = (k + e'⋅d) mod n_ - If _VerifyBlindSignature(cbytes(P), cbytes(R'), blindchallenge, bytes(32, s'), pk\_parity, nonce\_parity)_ returns failure, abort - Return _blindsignature = bytes(32, s')_ Algorithm _VerifyBlindSignature(pk, blindpubnonce, blindchallenge, blindsignature, pk\_parity, nonce\_parity)_: - Inputs: - _pk_: a 33-byte compressed public key - _blindpubnonce_: the signer’s 33-byte _R' = k'⋅G_ - _blindchallenge_: 32-byte _e'_ - _blindsignature_: 32-byte _s'_ - _pk\_parity, nonce\_parity_: booleans - Let _P' ' = cpoint(pk)_; let _P = P'_ if _pk\_parity_ else _−P'_ ; fail if _is\_infinite(P)_ - Let _R' ' = cpoint(blindpubnonce)_; let _R = R'_ if _nonce\_parity_ else _−R'_ - Let _e' = int(blindchallenge)_, _s' = int(blindsignature)_ - Return success iff _s'⋅G == R + e'⋅P_ ##### Unblinding Algorithm _UnblindSignature(session\_ctx, blindsignature)_: - Inputs: - _session\_ctx_: as defined above - _blindsignature_: the 32-byte _s'_ returned by the signer - Let _(Q, gacc, tacc, a, e, R) = GetSessionValues(session\_ctx)_; fail if that fails - Let _g = 1_ if _has\_even\_y(Q)_, else _g = −1 mod n_ - Let _s' = int(blindsignature)_; fail if _s' ≥ n_ - Let _s = (s' + a + e⋅g⋅tacc) mod n_ - Return the BIP340 signature _sig = xbytes(R) || bytes(32, s)_ ## Security Considerations - Exposure of any delegated tweak scalar `t` enables signing only for the specific child key(s) that scalar was derived for, and is typically short-lived if disclosed immediately before spending. - Delegatees MUST ensure every delegated path remains non-hardened and that _ComputeBIP32Tweak_ yields the correct tweak `t`; incorrect scalars could render the delegator incapable of producing a signature. - Delegators MUST verify change outputs when tweak data is provided (for example via _ChangeOutputVerification_) to avoid authorizing unexpected scripts. - Reusing the same k' (first 32 bytes in blindsecnonce) across two BlindSign calls allows recovery of the base secret key. - 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). ## Test Vectors A [collection of JSON test vectors](https://github.com/bitcoin/bips/blob/master/bip-0089/vectors) are provided, along with a [python reference implementation](https://github.com/bitcoin/bips/blob/master/bip-0089/reference.py). It uses a vendored copy of the [secp256k1lab](https://github.com/secp256k1lab/secp256k1lab/) library (commit [a265da139aea27386085a2a8760f8698e1bda64e](https://github.com/secp256k1lab/secp256k1lab/commit/a265da139aea27386085a2a8760f8698e1bda64e)). You may also find example code of CCD in action [here](https://github.com/jurvis/chaincode-delegation). ## Changelog - **1.0.0** (2026-08-13): Advance to Deployed. - **0.1.3** (2026-02-02): Upgrade secp256k1lab and add license file; fix type checker and linter issues; clarify Delegator/Delegatee terminology, derivation constraints, signing modes, and verification scope. - **0.1.2** (2025-12-03): Updated to reflect BIP number assignment. - **0.1.1** (2025-11-30): Fix acknowledgments spelling, BIP3 formatting, and use "Chain Code" with a space throughout. - **0.1.0** (2025-10-14): Publication of draft BIP ## Footnotes 1. The random data is hashed (with a unique tag) as a precaution against situations where the randomness may be correlated with the secret signing key itself. It is xored with the secret key (rather than combined with it in a hash) to reduce the number of operations exposed to the actual secret key. 2. This helps prevent accidental nonce reuse. A zeroed _blindsecnonce_ MUST cause subsequent _BlindSign_ calls to fail. 3. This check holds except with negligible probability. ## Acknowledgements - Arik Sosman and Wilmer Paulino for the initial discussions and validation of this idea. - Sanket Kajalkar, Jordan Mecom, Gregory Sanders, ZmnSCPxj, Yuval Kogman, and John Cantrell for code and design review. ## Copyright This BIP is licensed under the BSD 3-Clause license.