Technical architecture
QuietProof is organized in three layers. Keeping them separate is a security property as well as a documentation aid.
APPLICATION
custody · audit · OTC · credit · collaborative protocols
│
▼
ATTESTATION AND POLICY
canonical request · transcript · expiry · nonce · chain evidence
│
▼
CRYPTOGRAPHIC PRIMITIVE
PoKC: ZK knowledge of one or two P2WPKH spend keysPoKC relation
For each distinct public 20-byte witness program h, the prover privately supplies a scalar x and proves:
x ∈ [1, n−1]
P = xG
sec = SEC_compressed(P)
h = RIPEMD160(SHA256(sec))The circuit constrains scalar validity, elliptic-curve multiplication, finite normalized coordinates, canonical compressed SEC encoding, fixed SHA-256, fixed RIPEMD-160, and equality with the public program.
The compressed public key is internal witness data, not a public output.
Exact circuit family
V1 compiles one-key and two-key circuit shapes. There is no inactive padded relation. The canonical count of distinct programs selects the expected circuit identity, and mismatched circuit version, digest, Ligero rate, or query count is rejected before proof acceptance.
| Distinct programs | Public inputs | Private inputs | Quadratic terms | Serialized circuit |
|---|---|---|---|---|
| 1 | 21 | 3,010 | 2,067,522 | 24,876,346 B |
| 2 | 41 | 6,020 | 4,133,092 | 49,663,186 B |
Read the complete PoKC circuit documentation →
Canonical statement and envelope
The public statement binds network, verifier, purpose, message, timestamps, a 32-byte nonce, one to 16 output claims, and optional application bindings. The proof envelope binds the exact statement bytes, circuit digest, circuit version, Ligero rate, query count, and proof bytes.
The Fiat–Shamir transcript seed uses a tagged hash over the statement digest, circuit identity, and proof parameters. Unknown versions, unsupported parameters, malformed lengths, trailing bytes, and non-canonical fields are rejected.
Read the normative QuietProof v1 protocol →
Policy and chain evidence
PoKCVerifyProof(...) checks only the zero-knowledge relation. Applications should normally use VerifyQuietProof(...), which applies policy, proof verification, chain evidence, confirmation and value thresholds, optional bridge authorization, and atomic nonce consumption.
The chain provider is independently selected by the verifier. The bundled provider checks a stable current Bitcoin Core tip; authenticated historical state remains an external provider responsibility.
Assurance material
The repository includes:
- deterministic protocol and circuit fixtures;
- positive and negative native tests;
- real one- and two-key proof round trips;
- an independent Sage 10.6 executable mathematical oracle;
- canonical encoding and circuit-digest anchors; and
- a claim-by-claim security review map.
These are evidence for review, not a substitute for an independent cryptographic and protocol audit.