--- bip: 461 title: "Deterministic ECDSA Signatures" status: Draft type: Specification layer: "Applications" authors: ["Liam Gilligan"] assigned: 2026-08-12 last_modified: 2026-07-28 topics: ["signatures"] license: "CC0-1.0" url: https://bipexplorer.com/bip/461 source: https://github.com/bitcoin/bips/blob/master/bip-0461.md --- # BIP 461: Deterministic ECDSA Signatures > **In plain English:** Specifies a way of producing ECDSA signatures, Bitcoin's original signature type, where the result depends only on the private key and the message, removing reliance on a good random number source. The method also guarantees slightly shorter signatures, saving a little space and fees. ## Abstract This document specifies an ECDSA signing algorithm whose output is fully determined by the secret key and the message being signed. Its signatures are at most 70 bytes when DER encoded, rather than 72 for an arbitrary valid ECDSA signature. ## Motivation Under current consensus rules, a valid ECDSA signature of any message under any key has two degrees of freedom: the signer's free choice of nonce fixes _r_\[^rchoice\], and two possible values of _s_ follow from a specific _r_. A malicious signer can exploit that freedom to generate signatures that leak key material\[^darkskippy\], but a standardized, deterministic signing algorithm removes that freedom. Signers expected to comply with such an algorithm cannot leak key material without risking detection: a key holder can load the same secret key into two independent signers, sign the same message on both, and compare the results, as any difference reveals that at least one signer is not following this specification. The standardization of the deterministic algorithm is what enables leak detection, as a nonstandard algorithm has no other implementations to cross-check against. ## Definitions - The value _(n - 1) / 2_ is the **half curve order**, where _n_ is the order of the secp256k1 curve. - A given signature _(r, s)_ is considered **low-_r_** when _r < 2255_, and is otherwise considered **high-_r_**. - A given signature _(r, s)_ is considered **low-_s_** when _s_ is less than or equal to the half curve order, and is otherwise considered **high-_s_**. - **Low-_r_ grinding** is the process of regenerating a signature with a new nonce until it is a low-_r_ signature. - **Low-_s_ normalization** is the process of replacing a signature _(r, s)_ with the equivalent signature _(r, n - s)_ if _(r, s)_ is high-_s_.\[^lowsnormalization\] ## Specification ### Notation The following conventions are used, with constants as defined for [secp256k1](https://www.secg.org/sec2-v2.pdf). - Lowercase variables represent integers, byte arrays, or signatures: - The constant _p_ refers to the field size, _0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F_. - The constant _n_ refers to the curve order, _0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141_. - The constant _half\_order_ refers to the half curve order, _(n - 1) / 2_. - The constant _empty\_bytestring_ refers to the byte array of length zero. - An ECDSA signature _sig_ can be represented literally by an integer pair _(r, s)_, with _0 < r, s < n_. - Points on the curve with equation _y2 = x3 + 7_ over the integers modulo _p_: - The point at infinity is the identity element of the curve group, and is the only point without X and Y coordinates. - The function _is\_infinite(P)_ returns whether or not _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 _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 _bytes(l, x)_, where _x_ is an integer, returns the _l_\-byte encoding of _x_, most significant byte first. - The function _bytes\_le(l, x)_, where _x_ is an integer, returns the _l_\-byte encoding of _x_, least significant byte first. - The function _fill\_bytes(l, x)_, where _x_ is a byte, returns the length _l_ byte array in which every byte is _x_. - The function _hmac(k, m)_, where _k_ and _m_ are byte arrays, returns HMAC-SHA256\[^hmac\] with key _k_ over message _m_. - _x\-1_ refers to the modular multiplicative inverse of the integer _x_ modulo _n_. ### Algorithms This section specifies the following algorithms: - _nonce\_rfc6979(sk, msghash, extra, count)_ derives a nonce deterministically. - _sign(sk, msghash, extra)_ produces an ECDSA signature under a given additional data input. - _verify(sig, P, msghash)_ checks an ECDSA signature. - _DeterministicSign(sk, msghash)_ grinds _sign_ until _r_ is low and normalizes _s_. #### Nonce Derivation Input: - The secret key _sk_: a 32-byte array - The message hash _msghash_: a 32-byte array - The additional data _extra_: a byte array, possibly empty - The attempt counter _count_: an integer, _count >= 0_ The algorithm _nonce\_rfc6979(sk, msghash, extra, count)_ is defined as:\[^kv\] - Let _h = bytes(32, int(msghash) mod n)_\[^bits2octets\] - Let _V = fill\_bytes(32, 0x01)_ - Let _K = fill\_bytes(32, 0x00)_ - Let _K = hmac(K, V || 0x00 || sk || h || extra)_ - Let _V = hmac(K, V)_ - Let _K = hmac(K, V || 0x01 || sk || h || extra)_ - Let _V = hmac(K, V)_ - Let _V = hmac(K, V)_ - For _j = 1, ..., count_: - Let _K = hmac(K, V || 0x00)_ - Let _V = hmac(K, V)_ - Let _V = hmac(K, V)_ - Return _V_ #### ECDSA Signing Input: - The secret key _sk_: a 32-byte array - The message hash _msghash_: a 32-byte array - The additional data _extra_: a byte array, possibly empty The algorithm _sign(sk, msghash, extra)_ is defined as: - Let _d = int(sk)_ - Fail if _d = 0_ or _d >= n_ - For _count = 0, 1, ..., 232 - 1_:\[^attempt\] - Let _nonce = nonce\_rfc6979(sk, msghash, extra, count)_ - Let _k = int(nonce)_ - Continue if _k = 0_ or _k >= n_ - Let _R = k⋅G_ - Let _r = x(R) mod n_ - Continue if _r = 0_ - Let _s = k\-1 \* (d \* r + int(msghash)) mod n_ - Continue if _s = 0_ - Return _(r, s)_ - Fail #### ECDSA Verification Input: - The signature _sig_: _(r, s)_ - The public key _P_: a point - The message hash _msghash_: a 32-byte array The algorithm _verify(sig, P, msghash)_ is defined as: - If _is\_infinite(P)_: - Return _false_ - If _y(P)2 ≠ x(P)3 + 7 mod p_: - Return _false_ - Let _(r, s) = sig_ - If _r <= 0\* or \*r >= n_: - Return _false_ - If _s <= 0\* or \*s >= n_: - Return _false_ - Let _w = s\-1_ - Let _u1 = w \* int(msghash) mod n_ - Let _u2 = w \* r mod n_ - Let _R = u1⋅G + u2⋅P_ - If _is\_infinite(R)_: - Return _false_ - If _x(R) mod n ≠ r_: - Return _false_ - Return _true_ #### Deterministic Signing Input: - The secret key _sk_: a 32-byte array - The message hash _msghash_: a 32-byte array The algorithm _DeterministicSign(sk, msghash)_ is defined as follows. The **grind counter** is _0_ for the initial call to _sign_, which supplies no additional data, and takes the value of the loop variable _i_ for every subsequent call. - Fail if _int(sk) = 0_ or _int(sk) >= n_ - Let _(r, s) = sign(sk, msghash, empty\_bytestring)_\[^ndata\] - Let _i = 1_ - While _r >= 2255_:\[^geometric\] - If _i >= 232_: - Fail - Let _extra = bytes\_le(4, i) || fill\_bytes(28, 0x00)_\[^core\] - Let _(r, s) = sign(sk, msghash, extra)_ - Let _i = i + 1_ - If _s > half\_order_:\[^lows\] - Let _s = n - s_ - Let _P = int(sk)⋅G_ - If _verify((r, s), P, msghash)_ returns _false_, abort\[^verifysign\] - Return _(r, s)_ The predicate _r >= 2255_ is equivalent to testing that the most significant byte of _bytes(32, r)_ is greater than or equal to _0x80_. ## Rationale Bitcoin encodes ECDSA signatures in a strict DER form with an additional 1-byte sighash flag, which serializes _r_ and _s_ as arbitrary-length big-endian signed integers\[^bip66\]. Their encoding being signed means that even though every value of _r_ and _s_ can be encoded in 32 bytes or less as an unsigned integer, a null byte must be prepended if the most significant bit is set, raising the maximum size to 33 bytes each. The maximum size of a DER encoded ECDSA signature is 72 bytes, or 73 with the sighash flag. The signing algorithm as specified makes use of low-_r_ grinding and low-_s_ normalization\[^lowspolicy\] to exclusively produce low-_r_ and low-_s_ signatures. This produces signatures with a maximum DER encoding size of 70 bytes, or 71 with the sighash flag.\[^bip62size\] Against a signer that normalizes _s_ but does not grind, low-_r_ grinding saves on average 0.5 vbytes per signature in legacy inputs and 0.125 vbytes in v0 segwit inputs.\[^optech\] In 2-of-3 P2SH inputs it saves 2.5 vbytes on average, as a single high-_r_ signature pushes the input script's length indicator from one byte to three. The cost is rather cheap: low-_r_ grinding requires an additional signing operation and low-_s_ normalization requires a scalar subtraction. Uniform adoption is worthwhile independently of the savings, as a signer that does not grind is identifiable on-chain by its high-_r_ signatures.\[^review\] ### Low-_r_ Grinding #### Why RFC 6979 Grinding requires a nonce derivation that is deterministic in the secret key and message, and that additionally accepts a counter, so that a fresh and unrelated nonce can be derived for the same key and message.\[^noncereq\] RFC 6979 provides exactly this: it is the IETF's standard deterministic nonce derivation for ECDSA, and its section 3.6 admits an additional data input, for which it names a signature counter as an example:\[^rfc6979\] > It suffices that the additional data k' is non-repeating (e.g., a signature counter or a monotonic clock) to ensure "random-looking" signatures are indistinguishable, in a cryptographic way, from plain (EC)DSA signatures. #### Potential Alternate Grinding Methods **A fresh random nonce on each attempt.** Drawing each candidate nonce from a cryptographically secure random source also yields unrelated nonces, and is a valid means of producing low-_r_ signatures. Such a method is not adopted because the resulting signatures are not reproducible, which reopens the exfiltration problem described in the Motivation. Randomness would buy some protection against fault injection, which is why [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) recommends it for Schnorr signatures. Deterministic derivation is nonetheless established practice for ECDSA in Bitcoin, as RFC 6979 is libsecp256k1's default nonce function and Bitcoin Core requests it explicitly.\[^deterministictoday\] **Grinding for smaller _r_.** In order for a lower _r_ value to save any space, it must be an entire byte smaller, and thus must have the leading 9 bits unset rather than just the leading bit. Computing such an _r_ value would take 512 signing operations on average, as opposed to the two of regular low-_r_ grinding.\[^geometric\] Grinding for a smaller _r_ was deemed too expensive to be adopted widely. Because few signers would do so, the signers that did would be identifiable on-chain.\[^pr13666\] **Speeding up grinding with the _λ_ endomorphism.** It was suggested to use secp256k1's _λ_ endomorphism to quickly compute alternative nonces.\[^endomorphism\] Low-_r_ grinding as specified takes only two point multiplications on average. The added complexity of using the _λ_ endomorphism cannot meaningfully improve on that.\[^endospeedup\] ## Backward Compatibility Signatures generated under this specification are normal valid signatures and will verify under existing consensus rules, and thus are fully backward compatible. ## Copyright This BIP is licensed under the CC0-1.0 license. \[^rchoice\]: Technically a signer selects a nonce _k_, from which _r = x(k⋅G) mod n_ follows. It cannot target a particular _r_ without solving the discrete logarithm problem, and only about half the integers modulo _n_ occur as an _r_ at all, since _r_ must be the x-coordinate of a curve point. What the signer has is free choice of _k_, and so free choice among the _r_ values that result. \[^darkskippy\]: [Dark Skippy](https://darkskippy.com/) is a method by which malicious signing device firmware embeds seed material in the nonces of otherwise valid signatures, from which an attacker who observes those signatures on-chain can recover the seed. Raised in the context of this document by Craig Raw; see [this comment](https://github.com/bitcoin/bips/pull/2224#issuecomment-5114943404). \[^lowsnormalization\]: Low-_s_ normalization preserves signature validity: Let _(r, s)_ be a high-_s_ signature that _verify_ accepts for a public key _P_ and message hash _msghash_. Let _(r, s')_ be a low-_s_ signature with _s' = n - s_, and let us consider whether _verify_ will accept it under _P_ and _msghash_. The checks on _P_, _msghash_, and _r_ do not involve _s_ and are unchanged, and _s'_ passes the range check because _0 < s < n_ implies _0 < n - s < n_. Since _s' ≡ -s (mod n)_, _w' = -w_, so _u1' = -u1_, _u2' = -u2_, and consequently _R' = -R_. The x-coordinate of a finite point is invariant under negation, so _x(R') mod n = r_, and thus _verify_ accepts _(r, n - s)_ and low-_s_ normalization preserves validity. \[^hmac\]: [RFC 2104: HMAC: Keyed-Hashing for Message Authentication](https://www.rfc-editor.org/rfc/rfc2104), instantiated with SHA-256 as specified in [FIPS 180-4](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf). \[^kv\]: _K_ and _V_ are the internal state variables of the HMAC-based generator specified in [RFC 6979 section 3.2](https://www.rfc-editor.org/rfc/rfc6979#section-3.2), and carry its names. Both are 32-byte arrays rather than curve points, and _K_ is unrelated to the nonce _k_. \[^bits2octets\]: This reduction is RFC 6979's _bits2octets(h1)_, required by [section 3.2d](https://www.rfc-editor.org/rfc/rfc6979#section-3.2). It has no effect unless _int(msghash) >= n_, which occurs with probability about 1.27 · 2\-128. libsecp256k1 performs it as `msgmod32` in `nonce_function_rfc6979`; see [libsecp256k1 `src/secp256k1.c`](https://github.com/bitcoin-core/secp256k1/blob/master/src/secp256k1.c). Bitcoin Core acquired the reduction in v24.0, having fed the unreduced hash from v0.17.0 through v23.0. \[^attempt\]: _count_ advances the RFC 6979 generator without changing _extra_, and is distinct from the grind counter _i_. libsecp256k1 increments the same counter whenever the derived nonce falls outside _\[1, n-1\]_, or the resulting _r_ or _s_ is zero; see `secp256k1_ecdsa_sign_inner` in [libsecp256k1 `src/secp256k1.c`](https://github.com/bitcoin-core/secp256k1/blob/master/src/secp256k1.c), which retries in both cases rather than failing. Each of those conditions has probability on the order of 2\-128 or less, so _count_ is 0 for every signature produced in practice. Because _sign_ rejects an out-of-range secret key, and _DeterministicSign_ rejects one before the loop is entered, no secret key makes every attempt fail, so the loop's _Fail_ branch is unreachable in practice. An implementation may therefore omit the retry and fail on the first unusable nonce instead. Retrying is recommended and costs nothing, and neither choice affects the test vectors or interoperability. \[^ndata\]: Omitting the additional data makes RFC 6979 hash a 64-byte seed rather than a 96-byte one, so grind counter _0_ does not produce the nonce that 32 null bytes would. See [libsecp256k1 `src/secp256k1.c`](https://github.com/bitcoin-core/secp256k1/blob/master/src/secp256k1.c), `nonce_function_rfc6979`, which notes that the argument mixtures have distinct lengths and so cannot emulate one another. \[^geometric\]: For an event of probability _q_, the expected number of attempts before the first success is 1/_q_. A low _r_ arises with probability approximately 1/2, so grinding as specified takes two attempts on average, needs more than _j_ attempts with probability 2\-j, and terminates with probability 1; Bitcoin Core allots a 32-bit counter, which cannot be exhausted in practice. Grinding for an _r_ a whole byte smaller instead has _q_ = 2\-9, giving 512 attempts on average. That threshold is nine bits rather than eight because DER restores the padding byte whenever the leading content byte has its most significant bit set, so _r_ must fall below 2247 rather than 2248. \[^core\]: The little-endian counter is an artifact of `CKey::Sign` writing the counter into a 32-byte entropy buffer with `WriteLE32`; see [Bitcoin Core `src/key.cpp`](https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp). \[^lows\]: [libsecp256k1 `src/ecdsa_impl.h`](https://github.com/bitcoin-core/secp256k1/blob/master/src/ecdsa_impl.h), `secp256k1_ecdsa_sig_sign`: `high = secp256k1_scalar_is_high(sigs); secp256k1_scalar_cond_negate(sigs, high);` \[^verifysign\]: Verifying the signature before leaving the signer prevents random or attacker provoked computation errors. This prevents publishing invalid signatures which may leak information about the secret key. It is recommended, but can be omitted if the computation cost is prohibitive, at the cost of detecting faults in the signing computation. The preceding wording is taken from the equivalent step in the signing algorithm of [BIP 340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki), which is licensed under BSD-2-Clause. Bitcoin Core performs the check unconditionally in [`CKey::Sign`](https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp). Because the check cannot alter the returned signature, omitting it affects neither the test vectors nor interoperability. \[^bip66\]: [BIP 66: Strict DER signatures](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki). \[^lowspolicy\]: Note that transactions with high-_s_ signatures are valid but currently will not be relayed based on standard policy: see [Bitcoin Core `src/policy/policy.h`](https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.h). \[^bip62size\]: A signer that normalizes _s_ but does not grind falls between the two bounds, at 71 bytes of DER. [BIP 62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki), "DER encoding", gives that case as "the total signature size being at most 72 bytes (and on average 71.494 bytes)", counting the sighash flag. The average falls slightly below 71.5 because _r_ occasionally encodes in fewer than 32 bytes. \[^optech\]: [Bitcoin Optech: Low-r grinding](https://bitcoinops.org/en/topics/low-r-grinding/). \[^review\]: See, e.g., [this comment](https://github.com/bitcoin/bitcoin/pull/13666#issuecomment-406053492) and the surrounding discussion in the pull request that introduced grinding to Bitcoin Core. \[^noncereq\]: Two published signatures whose nonces stand in a relation an attacker can find will leak the secret key. Neither the intermediate attempts of a grind nor the counter that produced the successful one is published, so the constraint binds across messages rather than within a single grind loop; RFC 6979 satisfies it in both directions in any case. A fresh nonce from a cryptographically secure random source on each attempt also satisfies it, though the resulting signatures are not reproducible. \[^rfc6979\]: [RFC 6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)](https://www.rfc-editor.org/rfc/rfc6979). The additional data input and the non-repetition requirement are given in [section 3.6](https://www.rfc-editor.org/rfc/rfc6979#section-3.6). \[^deterministictoday\]: `secp256k1_nonce_function_default` is `nonce_function_rfc6979`; see [libsecp256k1 `src/secp256k1.c`](https://github.com/bitcoin-core/secp256k1/blob/master/src/secp256k1.c). Bitcoin Core passes `secp256k1_nonce_function_rfc6979` to `secp256k1_ecdsa_sign` in [`CKey::Sign`](https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp). \[^pr13666\]: [Bitcoin Core PR #13666, "Always create signatures with Low R values"](https://github.com/bitcoin/bitcoin/pull/13666), released in [Bitcoin Core v0.17.0](https://bitcoincore.org/en/releases/0.17.0/). The review discussion also considered grinding for even smaller _r_ values; see [this comment](https://github.com/bitcoin/bitcoin/pull/13666#issuecomment-405116700). \[^endomorphism\]: [Suggested during review of the pull request that introduced grinding to Bitcoin Core](https://github.com/bitcoin/bitcoin/pull/13666#issuecomment-405116700); the replies that follow discuss the nonce distribution it would produce. \[^endospeedup\]: A single point multiplication for the nonce _k_ also yields the _r_ values belonging to _λk_ and _λ_2_k_, where _λ_ is a primitive cube root of unity modulo the group order; see [libsecp256k1 `src/scalar_impl.h`](https://github.com/bitcoin-core/secp256k1/blob/master/src/scalar_impl.h), `secp256k1_const_lambda`. Since a signer must compute one point multiplication in any case, this saves at most one per signature, and capturing it requires curve arithmetic outside the signing routine.