Commitment Scheme
A commitment scheme is a cryptographic protocol that lets you lock in a value (commit) and reveal it later without being able to change it.
Key Takeaways
- A commitment scheme is a two-phase cryptographic protocol: you first commit to a value (locking it in without revealing it), then reveal the value later and prove it matches. It works like a sealed envelope that you hand to someone before opening it.
- Two core security properties make it work: hiding (nobody can figure out the committed value before the reveal) and binding (the committer cannot change the value after committing). No scheme can achieve both properties perfectly at the same time.
- Bitcoin uses commitment schemes extensively: hash locks in HTLCs commit to a preimage, Taproot tweaks a public key to commit to a script tree, and Pedersen commitments hide transaction amounts in Confidential Transactions.
What Is a Commitment Scheme?
A commitment scheme is a cryptographic protocol that allows one party to commit to a chosen value while keeping it hidden from others. Later, the committer can reveal the value and prove it matches what was originally committed. Think of it as writing a prediction on a piece of paper, locking it in a safe, and handing the safe to someone: they know a prediction exists but cannot read it until you provide the key.
This two-phase structure solves a fundamental problem in trustless systems: how do you prove you made a decision at a specific point in time without revealing that decision prematurely? Commitment schemes provide this guarantee without requiring a trusted third party, making them a building block for payment channels, atomic swaps, privacy protocols, and zero-knowledge proofs.
How It Works
Every commitment scheme consists of three algorithms: a setup phase that establishes public parameters, a commit function that produces the commitment, and a verify function that checks the reveal.
The Commit Phase
The committer selects a value (the message) and combines it with randomness to produce a commitment: a short, fixed-size output that encodes the value without revealing it. The randomness is critical. Without it, a commitment to a low-entropy value (like a yes/no vote) could be brute-forced by trying all possible inputs.
The committer publishes or sends the commitment to the other party and stores the original value and randomness privately. Once the commitment is published, the committer is locked in.
The Reveal Phase
When the time comes, the committer discloses the original value and the randomness used. The verifier re-runs the commitment function with these inputs and checks whether the result matches the published commitment. If it matches, the reveal is accepted. If not, the committer attempted to cheat.
Hiding vs. Binding
The security of a commitment scheme rests on two properties:
- Hiding: the commitment reveals nothing about the underlying value. Computationally hiding means no efficient algorithm can determine the value. Perfectly hiding means even an adversary with unlimited computing power cannot determine it.
- Binding: the committer cannot open the commitment to a different value than what was originally committed. Computationally binding means finding two values that produce the same commitment requires solving a hard mathematical problem. Perfectly binding means no two distinct values can ever produce the same commitment.
A fundamental result in cryptography proves that no commitment scheme can be simultaneously perfectly hiding and perfectly binding. Practical schemes must choose which property to make information-theoretic (perfect) and which to make computational. Hash-based commitments are perfectly binding but only computationally hiding. Pedersen commitments are perfectly hiding but only computationally binding.
Hash-Based Commitments
The simplest commitment scheme uses a cryptographic hash function. To commit to a value m, the committer generates a random blinding factor r and computes:
# Commit phase
C = SHA256(m || r)
# Reveal phase
# Committer discloses m and r
# Verifier checks: SHA256(m || r) == CThe hash output C is the commitment. Because SHA-256 is collision-resistant, finding a different pair (m', r') that produces the same hash is computationally infeasible: the scheme is perfectly binding. The random blinding factor r prevents brute-force attacks on the hidden value: the scheme is computationally hiding.
This construction is the foundation for hash locks in Bitcoin's HTLCs and Lightning Network payment routing.
Pedersen Commitments
Pedersen commitments, proposed by Torben Pryds Pedersen in 1991, offer a different tradeoff: perfect hiding at the cost of computational binding. The construction uses two independent generator points on an elliptic curve:
# G and H are independent generator points on secp256k1
# Nobody knows the discrete log of H with respect to G
C = v * G + r * H
# v = value being committed
# r = random blinding factorThe key advantage is the homomorphic property: adding two commitments on the curve produces a valid commitment to the sum of the underlying values. This allows verifiers to confirm that transaction inputs equal outputs without ever seeing the actual amounts.
Commitment Schemes in Bitcoin
Hash Locks in HTLCs
Hash Time-Locked Contracts use hash-based commitments as their core locking mechanism. A sender generates a random 32-byte secret (the preimage), computes its SHA-256 hash (the commitment), and creates a Bitcoin script with two spending paths:
- Hash lock path: the recipient provides the preimage that hashes to the committed value, plus a valid signature
- Time lock path: after a timeout, the sender can reclaim funds
Every standard Lightning Network payment routes value through a chain of HTLCs, each locked to the same hash commitment. When the final recipient reveals the preimage, it propagates back through each hop, settling the entire payment atomically. This is the commitment-reveal pattern in action: the hash is the commitment, and the preimage is the reveal.
Taproot Key Tweaking
Taproot (BIP 341, activated November 2021) uses a commitment scheme to embed an entire Merkle tree of scripts into a single public key. The process creates an output key Q by tweaking an internal key P:
# t = tagged hash of internal key and Merkle root
t = hash_TapTweak(P || merkle_root)
# Output key commits to the script tree
Q = P + t * GThe output key Q is the commitment to the entire script tree. This creates two spending paths: a key path spend using a single Schnorr signature (which looks indistinguishable from a regular payment), or a script path spend that reveals the internal key, a specific leaf script, and a Merkle proof. The key path spend is the "keep the commitment sealed" option: complex contracts look like simple payments on chain.
Taproot uses domain-separated tagged hashes (hash_TapLeaf, hash_TapBranch, hash_TapTweak) to prevent cross-protocol attacks where a hash from one context could be reused in another. For a deeper look at how Taproot and Schnorr signatures work together, see the Taproot and Schnorr signatures deep dive.
Confidential Transactions
On the Liquid Network, Pedersen commitments replace plaintext transaction amounts. Each output amount becomes a commitment on the secp256k1 curve, and validators verify that the sum of input commitments equals the sum of output commitments without ever seeing the actual values.
Pedersen commitments alone do not prevent negative values (which could create coins from nothing). Range proofs, originally implemented with Borromean ring signatures and later upgraded to Bulletproofs, are attached to each output to prove the committed value falls within a valid range (0 to 264 − 1) without revealing the amount. For more on this construction, see the zero-knowledge proofs in Bitcoin research article.
Other Applications
Commitment schemes appear throughout blockchain protocols beyond Bitcoin:
- Timestamping: protocols like OpenTimestamps aggregate document hashes into a Merkle tree and commit the root to Bitcoin via OP_RETURN, providing decentralized proof that data existed before a specific block
- Zero-knowledge proofs: KZG polynomial commitments (Kate-Zaverucha-Goldberg, 2010) allow a prover to commit to a polynomial and later prove correct evaluation at specific points, used in Ethereum's EIP-4844 proto-danksharding
- Mimblewimble: protocols like Grin build their entire transaction model on Pedersen commitments, where every output is a commitment and no plaintext amounts or addresses exist on chain
- Commit-reveal on smart contract platforms: blind auctions, on-chain randomness generation, and anti-front-running mechanisms use commitment schemes to prevent participants from reacting to others' choices
- PTLCs: the next evolution of HTLCs, replacing hash commitments with adaptor signatures for improved privacy across payment routes
Why It Matters
Commitment schemes are the cryptographic glue that makes trustless protocols possible. Without them, there is no way to prove you made a decision at a specific point in time without revealing that decision prematurely. Every Lightning payment, every Taproot spend, and every confidential transaction depends on the commit-then-reveal pattern.
For Bitcoin Layer 2 protocols like Spark, commitment schemes underpin the security model: they enable off-chain state updates that can be verified and enforced on chain when needed. The binding property ensures that parties cannot retroactively change committed states, while the hiding property preserves privacy until a dispute requires on-chain resolution.
Risks and Considerations
Computational Assumptions
Commitment schemes that rely on computational hardness (like the discrete logarithm problem) could be broken by advances in computing. A sufficiently powerful quantum computer running Shor's algorithm could break the binding property of Pedersen commitments, allowing a party to open a commitment to any value. Hash-based schemes using SHA-256 are more resistant to quantum attacks, though Grover's algorithm effectively halves their security parameter.
Randomness Quality
Hash-based commitments depend entirely on the quality of the random blinding factor. If the randomness is predictable or reused, the hiding property breaks and the committed value can be recovered. Secure random number generation is essential for any commitment scheme implementation.
Timing and Liveness
In protocols that use commitments with timelocks (like HTLCs), parties must reveal within the timeout window or lose funds. System failures, network outages, or blockchain congestion during the reveal window can result in unintended outcomes. Protocols using commitment schemes must account for these liveness requirements.
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.