Signature Grinding

What Is Signature Grinding?

Signature grinding is a wallet optimization technique that regenerates ECDSA signatures until the resulting signature meets specific byte-length criteria. In Bitcoin, this means repeatedly signing a transaction with different nonces until the signature's R component falls in the lower half of its range, producing a DER-encoded signature that is one byte shorter than it otherwise would be.

The technique exploits a quirk of DER (Distinguished Encoding Rules) encoding: integers with a leading high bit require a padding byte to avoid being misinterpreted as negative numbers. Since the R value in an ECDSA signature is effectively random, roughly half of all signatures require this extra byte. Grinding discards those "high-R" signatures and keeps only the smaller "low-R" ones.

While saving a single byte per signature sounds trivial, the savings compound across transactions with multiple inputs. In a fee market where every virtual byte has a cost, consistent size reductions improve fee estimation accuracy and lower total transaction fees.

How It Works

To understand signature grinding, you need to know how Bitcoin encodes ECDSA signatures. An ECDSA signature consists of two 256-bit integers: R and S. Bitcoin serializes these using DER encoding, a standard from the ASN.1 specification.

DER Encoding Structure

A DER-encoded Bitcoin signature follows this layout:

0x30 [total-length]
  0x02 [R-length] [R value: 32 or 33 bytes]
  0x02 [S-length] [S value: 32 or 33 bytes]
[sighash flag: 1 byte]

The 0x30 byte marks a compound structure, each 0x02 byte marks an integer, and the length bytes describe how many bytes follow. The sighash flag (typically SIGHASH_ALL, 0x01) is appended by Bitcoin outside the DER structure.

DER encodes integers as signed values using two's complement. If the most significant bit of R or S is set (meaning the first byte is 0x80 or higher), DER would interpret the value as negative. Since ECDSA R and S values are always positive, a 0x00 padding byte must be prepended to preserve the sign. This means:

• Low-R value (first byte below 0x80): R encodes as 32 bytes
• High-R value (first byte 0x80 or above): R encodes as 33 bytes (with a 0x00 prefix)

The same logic applies to S. However, Bitcoin Core has enforced low-S signatures (per BIP 62 and BIP 146) since v0.10.3, so S is always 32 bytes. That leaves R as the only variable component.

Signature Size Distribution

With low-S already enforced, the R value determines whether a signature is 71 or 72 bytes (including the sighash flag). Since R is derived from a random nonce, approximately 50% of signatures produce a high-R value requiring the extra byte:

The Grinding Process

Signature grinding eliminates high-R signatures by trying different nonces until a low-R result appears. Bitcoin Core implements this using RFC 6979 deterministic nonce generation with an additional counter value as extra entropy:

1. Generate a deterministic nonce using RFC 6979 with counter = 0
2. Produce the ECDSA signature
3. Check if the R value's most significant bit is 0 (low-R)
4. If yes, use this signature
5. If no, increment the counter and repeat from step 1

Each attempt has a 50% chance of producing a low-R value, so on average only two attempts are needed. The process remains fully deterministic: given the same private key, message, and counter, the same signature is always produced. This means signature grinding does not sacrifice reproducibility.

Regarding security, Pieter Wuille (a Bitcoin Core contributor) calculated that grinding costs approximately 1 bit of nonce entropy. With a 256-bit nonce space, this loss is cryptographically negligible.

Why It Matters

Signature grinding provides two practical benefits: lower fees and more predictable transaction sizes.

Fee Savings

The savings depend on the input type and whether the signature resides in the witness:

A transaction consolidating 20 legacy UTXOs saves up to 20 vBytes, which at a fee rate of 50 sat/vB equals 1,000 satoshis. For high-volume services processing thousands of transactions daily, these savings are meaningful.

Predictable Size Estimation

Without grinding, wallets must estimate whether each signature will be 71 or 72 bytes. Overestimating wastes fees; underestimating risks the transaction being rejected for insufficient fee. With grinding, every signature is consistently 71 bytes, making fee estimation exact.

This predictability is especially valuable for protocols that pre-sign transactions, such as Lightning channel commitment transactions and PSBTs in multistep workflows.

Implementation in Bitcoin Software

Bitcoin Core introduced low-R grinding in PR #13666, authored by Andrew Chow and merged in August 2018. It shipped as a default behavior in Bitcoin Core v0.17.0 (October 2018). Since then, multiple other Bitcoin libraries and wallets have adopted the optimization:

The widespread adoption of low-R grinding across the Bitcoin ecosystem means that most modern wallets produce 71-byte signatures by default. On-chain analysis by researcher b10c has shown a clear shift in the distribution of signature sizes following Bitcoin Core's v0.17.0 release.

Schnorr Signatures Eliminate the Need

Schnorr signatures, activated with the Taproot upgrade in November 2021 (defined in BIP-340), solve the variable-length signature problem at the protocol level. Instead of DER encoding, Schnorr signatures use a simple fixed-format encoding:

// Schnorr signature: fixed 64 bytes
[R x-coordinate: 32 bytes] [s scalar: 32 bytes]

// ECDSA signature: variable 71-73 bytes (DER-encoded)
[0x30] [length] [0x02] [R-len] [R: 32-33 bytes]
                [0x02] [S-len] [S: 32-33 bytes] [sighash]

Schnorr signatures are always exactly 64 bytes because they encode the R point using only its x-coordinate (32 bytes) concatenated with the scalar s (32 bytes). There is no DER wrapper, no sign-bit ambiguity, and no padding bytes. The y-coordinate of R is implicitly chosen as the even value, eliminating any need for extra encoding.

For P2TR (Pay-to-Taproot) inputs using the key path spend, the signature is always 64 bytes (or 65 with an explicit sighash type). As noted by Bitcoin Optech: signatures in Taproot transactions cannot be made any shorter. This means signature grinding is relevant only for legacy and SegWit v0 transaction types.

For a deeper look at how Schnorr signatures improve Bitcoin transactions, see Taproot and Schnorr Signatures Explained.

Risks and Considerations

Privacy Implications

Signature grinding can act as a wallet fingerprint. If a wallet always produces low-R signatures, chain analysis tools can use this to narrow down which software created a transaction. Conversely, a wallet that does not grind stands out among the majority that do. As most major wallets now implement grinding, this fingerprinting effect has diminished over time, but it remains a factor in chain analysis.

Diminishing Relevance

As the Bitcoin ecosystem migrates toward Taproot and Schnorr signatures, the need for signature grinding decreases. New wallets and protocols building on P2TR outputs benefit from fixed-size signatures without any grinding overhead. The optimization remains relevant for legacy and SegWit v0 inputs, which will continue to exist in the UTXO set for years to come.

Not a Consensus Rule

Low-R grinding is a wallet policy, not a consensus or relay rule. High-R signatures are perfectly valid on the Bitcoin network. Nodes accept and relay transactions with any valid DER-encoded signature regardless of R value. The optimization is purely opt-in and affects only the transaction creator's fees.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.