The adversary of this section is the forger. It watches the network accept spend after spend, each authorised by a signature; it may coax the legitimate signer into signing any messages of its choosing; and it wins if it can then exhibit one signature the signer never made—a spend of coins it does not control, an authorisation conjured from public data alone. Every verifier in a consensus network checks every signature, so the forger’s target is public and its victory is total: a single forged spend authorisation steals, and a single forged balance certificate mints value from nothing. The primitive that defeats it, the digital signature, is the last cryptographic object of this volume built directly on the discrete logarithm; it will also turn out, in its Schnorr form, to be the first proof of knowledge we construct—the bridge to the proof systems of Section 9.
The message authentication codes of §6.3 already defeat a forger, but only between two parties who share a secret key: verification runs , so whoever can check a tag can also mint one. Authentication by MAC is therefore private and repudiable—a verifier cannot exhibit the tag to a third party as evidence, since the verifier could have produced it. A blockchain inverts every one of these constraints. A transaction’s authorisation must be checked by every full node, none of whom the signer has met and none of whom may be capable of forging it; and the check must be transferable, so that a block, once validated, convinces everyone else.
A digital signature meets these demands by splitting the key. Signing uses a secret key ; verification uses a matching public key that may be published to the world. Anybody can verify; only the holder of can sign; and because verification needs no secret, a valid signature is non-repudiable evidence that the holder of signed. The price is computational: where the Carter–Wegman MAC of §6.3 was information-theoretically secure, every signature scheme in this section rests on the hardness of the discrete logarithm.
Zcash’s Orchard protocol uses two closely related signature schemes, both Schnorr-type schemes over an elliptic curve, and both derived from the one identification protocol this section develops (protocol specification § 5.4.7):
the spend authorisation signature, whose key pair can be re-randomised so that successive uses are unlinkable (protocol specification § 4.15), and
the binding signature, which simultaneously certifies the consistency of a transaction’s value commitments and proves knowledge of a discrete logarithm (protocol specification § 4.14).
Throughout, is a cyclic group of prime order , written additively, with a fixed generator ; scalar multiplication is for and . Concretely is the Pallas group of §2.6, whose order is the -bit prime , so scalars live in the field . Because has prime order and generates it, the map is a bijection : the discrete logarithm of any to base always exists and is unique. Hardness of computing it is the DLog assumption of §2.1, transcribed additively.
A digital signature scheme is a triple of PPT algorithms with, for each security parameter , a message space :
outputs a key pair ;
, for , outputs a signature ;
is deterministic and outputs a bit.
Correctness requires that for every , every in the support of , and every ,
the probability over the coins of . Probability- correctness is called perfect; a scheme achieving only overwhelming-probability correctness tolerates a failure rate. Every scheme in this section is perfectly correct.
The security goal transcribes the MAC forgery game of Definition 6.8 into the public-key setting: the adversary now receives the verification key, and its oracle access models a signer who can be induced to sign arbitrary messages.
For a signature scheme and adversary , the game runs as follows.
The challenger runs .
The adversary runs on input with oracle access to ; let be the set of messages it submits to the oracle, and let be its output.
The game outputs iff and .
Scheme is existentially unforgeable under chosen-message attack (EUF-CMA) if for every PPT ,
Two features of the definition deserve emphasis. The oracle access is adaptive and bounded only by the adversary’s polynomial running time: it may choose each query after seeing all previous signatures. And the forgery is existential: the adversary wins with a valid signature on any message never submitted to the oracle, however meaningless—the definition does not ask the forged message to be useful, so security under it protects even messages the signer would consider absurd.
The strong variant, sUF-CMA, replaces the winning condition by: the pair was not among the message–signature pairs returned by the oracle.
Strong unforgeability forbids producing even a new signature on an already-signed message. Plain EUF-CMA permits a scheme in which, given one valid signature, anyone can cheaply compute a second, different valid signature on the same message; such malleability is harmless when a signature only certifies origin, but fatal whenever a signature doubles as a unique token—certain anti-replay mechanisms, for instance, identify a message by its signature and break if signatures are malleable.
The textbook mechanisms—RSA, Schnorr, ECDSA—sign only fixed-size inputs: an element of for RSA, a scalar in for Schnorr and ECDSA. Arbitrary messages are accommodated by hashing first, and the composition is provably safe.
Let be a signature scheme with message space , and let be drawn from a collision-resistant family (Definition 3.7). Define with message space by
If is EUF-CMA and is collision resistant, then is EUF-CMA; concretely, for every adversary against there are comparably efficient against and against with
Let be a valid forgery of on a fresh message , and split on the digest. Case 1: the digest is reused, i.e. for some queried . Then but their digests agree, so the pair is a collision in ; the reduction , which generates a key pair with itself and answers ’s signing queries by signing digests under that secret key—the collision game grants no signing oracle—outputs it. Case 2: the digest is fresh, i.e. differs from the digest of every queried message. Then is a valid forgery against on a message never submitted to its signing oracle, and outputs it. The two cases are exhaustive, so the union bound on the winning event gives the stated inequality. □
In all the Schnorr-type schemes below, the hash absorbs more than the message: the public key and the per-signature commitment value enter the hash alongside . Hashing the public key prevents key-substitution (duplicate-signature) attacks, in which a signature valid under one key is exhibited as valid under another; hashing the commitment is exactly what the Fiat–Shamir transform of §8.5 requires. “Hash-and-sign” in practice therefore means hashing more than the message; Theorem 8.4 captures only the message-compression part of the discipline.
Every scheme in the rest of this section is a costume worn by a single interactive protocol, in which a prover convinces a verifier that it knows the discrete logarithm of a public point— without revealing anything about it. We develop the protocol self-contained, with concrete statements and proofs; the general vocabulary it exemplifies (Sigma-protocols, of which it is the canonical instance: three-move, public-coin, honest-verifier zero-knowledge (HVZK) proofs of knowledge) is deliberately deferred to Section 9, where it is developed for arbitrary relations.
The object of the protocol is the discrete-log relation
the statement is a public point , the witness its discrete logarithm .
Fix of prime order . The prover holds a secret key ; both parties hold the public key . The protocol has three moves.
Commitment. The prover samples uniformly and sends . We call the commitment (or nonce point) and the nonce.
Challenge. The verifier samples uniformly and sends .
Response. The prover sends in .
The verifier accepts iff
| (2) |
A triple satisfying (2) is an accepting transcript for . The verifier’s only message is a uniformly random value chosen independently of , so the protocol is public-coin: the verifier keeps no secrets and exercises no discretion.
Three properties make this protocol what it is: honest runs always accept; answering two distinct challenges on one commitment is possible only for a party who knows ; and a transcript reveals nothing about . We prove each in turn.
If prover and verifier are honest, the verifier accepts with probability .
With , and , linearity of scalar multiplication gives
which is exactly (2). The computation holds identically for every choice of and . □
There is an efficient extractor that, given two accepting transcripts and for the same statement with the same commitment but distinct challenges , outputs the discrete logarithm of .
Both transcripts satisfy (2); subtracting the two equations in cancels :
Since generates a group of prime order , equality of the two multiples forces the equality of scalars in . The hypothesis makes a nonzero element of the field , hence invertible, so the extractor outputs
Verification that is direct, and the whole computation costs a single field inversion. □
Theorem 8.8 is the central mechanism of this section. It makes the protocol a proof of knowledge: below, it converts a convincing prover into an extractable witness; after the Fiat–Shamir transform it is the source of unforgeability; and in §8.6 it reappears with its sign reversed, as the reason a signer must never reuse a nonce.
Suppose a (possibly dishonest) prover makes the verifier accept with probability noticeably larger than —the probability of simply guessing the single challenge for which a prepared response works. Run the prover once: record its commitment , feed it a uniform challenge , and note whether its response accepts. Now rewind it to the moment just after it sent —restore its internal state, which is possible because we run the prover as a subroutine—and feed a fresh independent challenge . A standard averaging argument shows that with probability roughly , both runs accept and ; the argument is the heavy-row lemma, an instance of Markov’s inequality applied to the matrix whose rows are the prover’s random coins and whose columns are challenges (Math Guide, §“Random variables and expectation”). The two accepting transcripts share , so the extractor of Theorem 8.8 recovers . Making the verifier accept with non-trivial probability is therefore, up to rewinding, the same as knowing . The same rewinding argument, sharpened into the forking lemma, carries the signature analysis of §8.6.
There is an efficient simulator that, on input a statement and a challenge , outputs an accepting transcript distributed identically to an honest execution conditioned on the challenge being . Consequently, for a uniform challenge, the distribution of simulated transcripts coincides exactly with the distribution of real ones.
The simulator works backwards: it samples uniformly, sets
and outputs —accepting by construction, since (2) rearranges to exactly this definition of .
Compare distributions with the challenge fixed to . In a real honest transcript, is uniform on , , and ; the map is a translation of , hence a bijection, so is uniform on , and is the same deterministic function of that the simulator uses. The real transcript is: sample uniform, set —precisely the simulated distribution. The two distributions are identical, not merely statistically close, and averaging over a uniform preserves the identity. □
The simulator of Theorem 8.10 matches the real distribution only when the challenge is sampled independently of . A cheating verifier could instead choose as a function of , and against such a verifier the simulator—which commits to only after seeing —no longer obviously works. For our purposes honest-verifier zero knowledge is exactly enough: after the Fiat–Shamir transform the challenge is a hash of , and in the random oracle model that hash behaves like an honest, -independent coin. The deeper point of the theorem is what the simulator’s existence proves: since anyone, without , can manufacture transcripts with the true distribution, a transcript carries no information about beyond what the statement already reveals.
An identification protocol convinces one verifier, once, interactively. A signature must convince everyone, forever, on its own. The Fiat–Shamir transform removes the interaction by making the prover compute the challenge itself—as a hash of everything the verifier would have seen before issuing it, with the message folded in so that the resulting object certifies . The transform is generic: it converts any Sigma-protocol into a non-interactive proof, and, with a message in the hash, into a signature. This subsection owns only the Schnorr instance; the general transform, its subtleties and its failure modes are the business of Section 9 (§“The Fiat–Shamir transform: from interactive to non-interactive”).
Fix of prime order and a hash function . Messages are arbitrary bit strings.
: sample , set , output .
: sample , set , compute the challenge
set in , and output .
: recompute and accept iff .
The Schnorr signature scheme is perfectly correct.
For an honest signature with , and , the verifier recomputes the same —the challenge is a deterministic function of , all of which the verifier holds—and the check holds by the completeness computation of Proposition 8.7. □
Two presentational choices in Construction 8.12 deserve note.
The signature transmits and omits , which the verifier recomputes. The space-saving variant transmits instead: the verifier recovers (the simulator’s equation, read as reconstruction) and checks . The two are interchangeable; the deployed schemes below use the form.
The hash takes the public key alongside and —key-prefixing. The single-key unforgeability proof of §8.6 does not require it, but it forecloses attacks that relate signatures under different keys (Remark 8.5), it is standard in modern instantiations such as EdDSA, and it earns its keep in the re-randomised setting of §8.8.
What must a forger of Schnorr signatures accomplish? A valid pair on a fresh message is an accepting transcript of the identification protocol whose challenge is —a value the forger cannot choose freely if the hash is honest. The security argument makes “honest” precise by idealising , then turns the rewinding of Remark 8.9 into a quantitative tool.
The random oracle of Definition 3.13 generalises verbatim to an arbitrary finite range: a random oracle with range is a function drawn uniformly from the set of all such functions, realised lazily by sampling each new answer on first query. For Schnorr signatures the range is the challenge space , and the ROM for signatures models , with every party—signer, verifier, forger, and reduction—sharing oracle access (Definition 1.26).
The model remains a heuristic, with the uninstantiability caveat and the working stance of Remark 1.29: a ROM proof rules out all attacks that treat the hash as a black box—the overwhelming majority—and it is the standard yardstick for Fiat–Shamir signatures. The reductions below exploit both powers of Proposition 3.14: programmability (the reduction chooses oracle answers on the fly, provided they appear uniform) and observability (the reduction sees every query the adversary makes).
The first tool disposes of the signing oracle: in the ROM, the zero-knowledge simulator of Theorem 8.10 answers signing queries without the secret key.
In the ROM there is an efficient simulator that, given only the public key and the ability to program , answers signing queries with signatures distributed identically to genuine ones, except that it aborts with probability at most over an attack making signing and hash queries.
To sign without : sample and uniformly, set —the HVZK simulator of Theorem 8.10—then program
and output . The signature verifies by construction, and by Theorem 8.10 its distribution matches a real signature’s exactly: in both cases is uniform, and is uniform because a fresh oracle answer is.
Programming fails only if the entry is already defined—by an earlier adversary hash query or an earlier simulated signature. The point is a fixed translate of for uniform , hence uniform over the elements of ; at most oracle entries exist at any point of the attack, so a given signing query collides with probability at most , and the union bound over signing queries gives the stated abort probability. Conditioned on no abort, the adversary’s view is identical to the real game. □
Lemma 8.16 reduces forgery to a pure discrete-log problem: the reduction can play the whole EUF-CMA game knowing only . What remains is to convert one forgery into two accepting transcripts on the same commitment—the input that Theorem 8.8 demands. The quantitative engine is the forking lemma, in the game-based form due to Bellare and Neven.
Fix an integer , a finite set with , and a randomised input generator . Let be a randomised algorithm that on input and challenges returns a pair with , where means failure, and let
Define the forking algorithm on input : pick coins for and ; run ; if , return ; otherwise resample afresh and run with the same coins ; if and , return , else . Then
the probability also over the coins of .
Condition on the coins and the prefix up to the forking point. For each fixed prefix there is (averaging over the suffix) a set of good values of on which succeeds with index ; write . The fork succeeds at this prefix iff the first draw and the independent re-draw both land in and differ: two independent uniform draws land in together with probability , and subtracting the diagonal of equal draws costs at most , so the per-prefix fork probability is at least . Taking expectations over prefixes, , since by linearity of expectation (Math Guide, §“Random variables and expectation”); this squares the average success probability. The index ranging over possible positions introduces the factor , and collecting terms yields . The squaring step is where the squared probability—and hence the tightness loss examined below—enters. □
Model as a random oracle with range . If an adversary runs in time , makes at most hash queries and signing queries, and forges with probability , then there is an algorithm running in time approximately that computes discrete logarithms in with probability
In particular, if DLog is hard in , the Schnorr signature scheme is EUF-CMA in the ROM.
Wrap as the algorithm of Theorem 8.17, with input —the DLog challenge, so outputs for uniform —challenge set (so ), and prepared challenges. Algorithm runs on , answering the -th distinct hash query with from its challenge list and answering signing queries by the simulator of Lemma 8.16, whose programming aborts cost the term.
Suppose outputs a valid fresh forgery , and let . The critical hash input must actually have been queried during the run: otherwise is a uniform value has never seen, and the verification equation then holds only with probability over the oracle’s choice—the term collects these guessing events (the covering the query itself makes to verify the forgery). So outputs the index of the critical query together with , and minus the loss terms above.
Now fork. Both runs of share the coins and the challenge prefix , which together determine ’s behaviour up to the moment it produces the critical query; both runs therefore query the same critical input at index , but receive different answers . Success of the fork yields two accepting transcripts and with the same commitment and distinct challenges, whereupon the extractor of Theorem 8.8 computes
the discrete logarithm of . Substituting , and into gives the stated bound; the running time is two runs of plus bookkeeping. □
The dominant term of Theorem 8.18 is : the reduction runs the forger twice and squares its success probability, divided by the number of hash queries. The reduction is therefore far from tight (Definition 1.22). Concretely, a forger succeeding with probability after hash queries yields a guaranteed DLog-solver advantage of only about
a factor weaker than itself. The guarantee runs in the useful direction—any forger yields some DLog solver, so DLog hardness still implies security—but the quantitative content is feeble. Two lessons follow, and they must be kept apart. The conservative lesson (Remark 1.23): a designer who wants this theorem to underwrite a target signature-security level must provision with roughly twice as many bits of DLog security as the target, since the reduction hands back only the square of the forger’s advantage; and the squaring is intrinsic to the rewinding route—it enters at the squaring step of Theorem 8.17, so any analysis that runs the forger twice and extracts by special soundness pays it. What the theorem does not establish is a matching attack: the loss belongs to the reduction, not provably to the scheme, so doubled parameters are the price of this proof, not a demonstrated necessity, and parameter selection in practice weighs concrete attack models and query bounds as well. Tighter reductions exist once the rewinding route is abandoned—under the one-more discrete logarithm assumption (that no efficient adversary, given random elements of and queries to a discrete-logarithm oracle, outputs all logarithms), under DDH (Definition 2.5) together with key-prefixing, or in the idealised algebraic models of Remark 1.30.
Suppose a signer produces two Schnorr signatures and on distinct messages with the same commitment —a nonce reused outright, or drawn twice from a faulty source. Then, except with probability over the challenge hash, anyone can compute the secret key from the two signatures.
The challenges and differ except with probability , the chance that the random oracle answers the two distinct inputs identically. Given , the pairs and are two accepting transcripts sharing a commitment with distinct challenges, and the extractor of Theorem 8.8—run now by the adversary—outputs . □
Special soundness, the source of unforgeability, is thus also its dark mirror: the security of the scheme rests entirely on the nonce being fresh and unpredictable for every signature. This is not a theoretical worry—it is the classic operational failure of deployed Schnorr-family schemes—and it motivates deriving nonces deterministically from the secret key and message, the defining idea of EdDSA, to which we now turn.
EdDSA retains the Schnorr signature algebra of Construction 8.12 unchanged and hardens two implementation surfaces.
Deterministic nonces. The nonce is derived as a hash of a secret prefix (part of the expanded secret key) and the message, rather than sampled fresh: no faulty random-number generator can repeat a nonce across distinct messages and trigger Proposition 8.20.
In the ROM the deterministic nonce is, to anyone ignorant of the secret prefix, a fresh uniform value per message, so the unforgeability proof of Theorem 8.18 carries over essentially unchanged.
Zcash’s signature scheme generalises EdDSA in two directions, and the generalisations are the whole point: the base point becomes a parameter, and the key becomes shiftable.
RedDSA is the Schnorr/EdDSA scheme with the base point a parameter of the scheme: different uses sign with respect to different generators.
: sample , output secret key and public key .
: sample a fresh random byte string and derive the nonce . This is randomised, hash-based nonce generation: unlike EdDSA’s derivation, it is not deterministic from the signing key and message, so its safety rests on being fresh and unpredictable, the hashing ensuring only that a repeated cannot repeat a nonce across distinct messages. Set , , , and output .
: accept iff with .
For a fixed base point, RedDSA is Schnorr/EdDSA, and its EUF-CMA security in the ROM is Theorem 8.18 with replaced by .
The deployed scheme follows Construction 8.22 line for line (protocol specification § 5.4.7). The randomiser is uniform bytes, and both hashes are the function : BLAKE2b-512 personalised with Zcash_RedPallasH, its -byte output reduced to by wide reduction— the expand-then-reduce discipline of Construction 3.18, with the -bit width making the modular bias negligible. The nonce hash absorbs and the challenge hash , key-prefixed in both cases.
Orchard instantiates RedDSA twice, both times as RedPallas—RedDSA over the Pallas curve—and the two instantiations differ only in the base point:
the spend authorisation base point, derived by hashing to the curve with domain z.cash:Orchard and input G, for the re-randomisable signature of §8.8; and
The curve varies only across protocol generations: Sapling’s RedJubjub is the same scheme over the Jubjub curve; the curve, its two base points and the personalisation (Zcash_RedJubjubH against Zcash_RedPallasH) are all that distinguish the two.
A shielded protocol faces a linkage problem that no ordinary signature scheme addresses. Spending a note requires proving spend authority, and the obvious design—publish the spender’s public key and a signature under it—would stamp every spend by the same wallet with the same key, linking them all. Orchard’s answer exploits the algebraic structure of the RedDSA public key: because the key is a homomorphic image of the secret, it can be shifted into a fresh disguise for every spend.
Fix a base point . Given a secret key with public key , and a randomiser , the re-randomised signing and verification keys are
Orchard publishes a fresh per spend, signs with the shifted secret key , and proves in zero knowledge that is a valid re-randomisation of an authorised public key.
The pair is a valid RedDSA key pair: , so a RedDSA signature under verifies under .
Linearity of scalar multiplication gives
The pair is thus exactly -shaped, and the correctness of signing and verification (Proposition 8.13) applies verbatim. □
The enabling structure deserves a sentence of its own. The public key is a homomorphic image of the scalar, so shifting the secret by shifts the public key by —a quantity computable from and alone, without the secret key. A verifier, or a circuit, can therefore check the relationship between and given , while only the spender who knows can sign under the shifted key.
Fix a base point . For any public key , if is uniform then is uniformly distributed over . Consequently, in the game where an adversary—of unbounded computational power, and permitted to choose two public keys itself—receives for a challenger’s uniform bit and fresh uniform , and must guess : the distributions of for and are identical, and no adversary guesses with probability better than .
The point generates , which has prime order , so is a bijection ; for uniform , the point is uniform over . Translation by the fixed element is a bijection of and carries the uniform distribution to itself, so is uniform over —for every , hence independently of . The two conditional distributions of coincide exactly, so the adversary’s view is statistically independent of ; no test distinguishes identical distributions, and the best any distinguisher can do is guess, succeeding with probability exactly . □
The guarantee is information-theoretic—perfect, resting on no computational assumption—but its precondition matters: must be sampled uniformly and freshly per use, and must be kept secret. In Orchard the transaction builder samples afresh for each spend and reveals it only to the proving circuit and the signer.
Theorem 8.26 covers only the re-randomised key. Full unlinkability of a spend further requires that the accompanying signature and zero-knowledge proof leak nothing beyond their statements, that the randomiser stays secret, and that no other transaction field correlates two spends. In Orchard the protocol publishes with each Action (the unit that spends one note and creates one) while proving, inside the Halo 2 circuit, knowledge of a witness for with a public key whose holder is authorised to spend the note (Orchard’s spend validating key)—the circuit constrains as a public input—and the network verifies the spend authorisation signature against the public . Signing under requires , that is, knowledge of both and ; only the legitimate key-holder in possession of this spend’s can sign.
Does unforgeability survive re-randomisation? A forgery under satisfies with . One is tempted to subtract from the verification equation: , apparently a forgery under the original key . But the identity holds with , while the base verifier recomputes —the plain subtraction converts forgeries only for the non-key-prefixed variant of Schnorr. For key-prefixed RedDSA one argues in the ROM by either of two routes. (i) The pair is itself a base-scheme key pair (Proposition 8.25) whose public key is uniform (Theorem 8.26), so a forger against is literally a forger against the base scheme at the key ; the reduction, which knows , recovers from the extracted . (ii) When the adversary sees signatures under several randomisers , one re-runs the forking argument of Theorem 8.18 on the critical query , simulating signing under the remaining keys by oracle programming (Lemma 8.16). A pitfall marks the boundary: a naive translation that programs must be a carefully injective domain swap, and it fails outright with multiple randomisers—distinct -prefixed inputs would collide on a single -prefixed point, a detectable deviation from a random oracle.
The second RedPallas instantiation guards a different treasure: not who may spend, but whether value is conserved. A shielded transaction hides its amounts inside commitments; the forger of this subsection is a counterfeiter who would arrange commitments whose hidden values do not balance—minting money—while still producing whatever certificate the protocol demands. The defence consumes the homomorphism established in §4.6 and turns this section’s central lesson—a Schnorr signature is a proof of knowledge of a discrete logarithm—from analysis into design.
Shielded protocols commit to value with the homomorphic Pedersen commitment
where and are independent generators of —independent meaning that no party knows the discrete logarithm of one to the base of the other, arranged by deriving both by hashing to the curve (Construction 3.24)—and is a random blinding scalar. (In the notation of the orchard crate and of Remark 4.21, the randomness base here called is the generator ; this section reserves for the signature nonce point. The base is exactly the binding base point of Remark 8.23.) By Theorem 4.20, the group sum of commitments commits to the sum of values with the sum of blindings.
Sapling commits per note: a transaction carries input commitments and output commitments , and the net commitment is
Orchard has no per-note value commitments: each Action—the unit that simultaneously spends a note of value and creates a note of value —commits once to its net value change, publishing
and over the transaction’s Actions (protocol specification § 5.4.8.3). The Action structure itself—how spends and outputs are fused into these units and assembled into a transaction—is the business of the Ironwood Guide. Either way, the homomorphism collapses the pile:
where is the net value— in Sapling, in Orchard— and is the net blinding. The transaction balances precisely when equals the public balancing value ; for a transaction with internal balance , the -component vanishes and . Three observations set up the construction. Every element of is some multiple of , since generates the prime-order group, so what distinguishes a balanced transaction is not the existence of a representation but the ability to compute one. When the values balance, the signer knows the multiplier: it is the net blinding , assembled from the individual blindings. When they do not, computing any -multiple representation of from the published commitments would require knowing , assumed hard.
With and as above and the transaction balanced, so that , set the binding verification key and the binding signing key . The binding signature is a RedDSA signature over the base point , with signing key and verification key , on a message that is the hash of the transaction (the sighash). The verifier recomputes from the publicly listed value commitments and the public balancing value, then checks with .
In the ROM, a valid binding signature on a transaction is a proof of knowledge of the discrete logarithm of the net commitment to the base ; combined with the soundness of the accompanying zero-knowledge proofs (per Action in Orchard, per note in Sapling), which fix and range-check the committed values, it forces the transaction to balance.
Part 1: proof of knowledge. The binding signature is exactly a Fiat–Shamir Schnorr proof for the relation with base and statement . By special soundness (Theorem 8.8) together with the forking argument of Theorem 8.18— specialised to a single statement and no signing oracle—any algorithm producing a valid signature under with non-negligible probability can be rewound to two accepting transcripts , with , from which the extractor recovers with . Producing a valid binding signature is therefore equivalent, up to the standard rewinding loss, to knowing .
Part 2: knowledge forces balance. Write for the true net value and net blinding that the commitments imply; these are well defined once the accompanying proofs fix the committed openings—in Orchard the per-Action circuit fixes , and the opening of , in Sapling the per-note proofs fix each . If the signer knows with , subtracting the two expressions for gives
where enters as a scalar, that is, as its residue in . Whenever , that residue is a nonzero element of , hence invertible, so
—exhibiting and contradicting the independence of and . Therefore .
Part 3: from congruence to equality. Balance in alone is not yet economic balance: an integer net value equal to a nonzero multiple of would pass the test above while minting units at a stroke. The gap is closed by the range checks in the same accompanying proofs: in Orchard the per-Action circuit constrains and to (the Action statement, protocol specification § 4.18.4), and in Sapling the per-note proofs constrain each likewise. A transaction with Actions (count notes instead for Sapling) therefore has as an integer, vastly below the -bit for any transaction that can be serialised, and the only multiple of in that range is . Hence over , not merely in . □
In deployment the transaction is not internally balanced: it declares a public balancing value , and the verifier signs off against , folding the public value into the verification key—the orchard crate’s Bundle::binding_validating_key subtracts a commitment to with zero blinding from the sum of the Actions’ (protocol specification § 4.14). The argument of Theorem 8.30 applies verbatim to the folded key and forces ; the balancing value is encoded as a signed -bit integer, so the range checks promote the congruence to the integer equality exactly as in Part 3.
The single pair accomplishes three things at once. First, it proves knowledge of , certifying balance, by Theorem 8.30. Second, because the Fiat–Shamir challenge hashes the transaction sighash, the same signature authenticates the transaction: altering any signed field changes and invalidates , so the binding signature doubles as an integrity check binding the shielded components together—the origin of the name. Third, the construction needs no trusted setup and no separate circuit for the balance check: it is pure elliptic-curve arithmetic that anyone can verify. The homomorphism of the commitment turns the arithmetic statement “the values balance” into the algebraic statement “ is a known multiple of ”, and the Schnorr signature is the off-the-shelf proof of knowledge for precisely that statement—the purest illustration in the protocol that a digital signature is a proof of knowledge of a discrete logarithm.
Set the two RedPallas uses side by side. The spend authorisation signature verifies under a re-randomised key , chosen to hide which long-term key authorised the spend: the signing key encodes authority, and buys unlinkability (Theorem 8.26). The binding signature verifies under a key that the spender does not choose: the transaction’s own commitments force it, the “secret key” is the net blinding factor, and signing proves balance (Theorem 8.30). Both are the same three lines of Schnorr arithmetic; what differs is the meaning assigned to the discrete logarithm—authority in one case, value-conservation in the other. The unifying lesson of this section: once a public key is the image of a secret under , a Schnorr signature is a compact, non-interactive proof of knowing that secret, and the designer chooses what knowing it means.
Two signature schemes in the series live outside the Pallas group: the transparent layer authorises spends with ECDSA, and the issuance bundle of Zcash Shielded Assets is authorised with a BIP-340 Schnorr signature. Both run over secp256k1, and both are registered here at the level a consumer needs—syntax, deployed conventions, and where their security stands—rather than constructed from scratch.
The curve secp256k1 is the short Weierstrass curve over the prime field with , with a fixed base point of prime order (a -bit prime) and cofactor ; every constant is a named parameter of SEC 2. In SEC 2’s terminology it is a Koblitz curve, one with , a choice that buys implementation speed and plays no role in what follows. The group law, point encodings, and the discrete-logarithm problem on such a curve are the general machinery of the Math Guide, §“Elliptic curves” and §“The elliptic-curve discrete logarithm problem”; the hardness assumption is Definition 2.1 in the group .
Let be the integer read from the -byte digest of the message, and write for the -coordinate of a point, read as an integer; the secret scalar is written , since is taken.
: sample , set , output .
: sample , set and , then ; restart if or ; output .
: require , compute , and accept iff is not the identity and .
Correctness: . The nonce must be fresh and secret, for the reason of Proposition 8.20 in different algebra: two signatures and under one on distinct digests give , hence and then .
Where Schnorr’s challenge is a hash of , ECDSA’s is the coordinate itself, so the scheme is not a Fiat–Shamir transform and the forking-lemma route to Theorem 8.18 does not apply. Unforgeability analyses exist—in the generic group model, and in the ROM under additional assumptions on the map —but they lie outside this volume’s path: the transparent layer inherits ECDSA’s security from Bitcoin’s track record rather than from a reduction.
Three conventions fix how the transparent layer uses Construction 8.33, which protocol specification § 4.1.7 names as the script signature scheme.
The message is the sighash. The digest is the -byte SIGHASH transaction hash of protocol specification § 4.10 (ZIP 244 for version-5 transactions), so the sighash algorithm plays the role of the hash in Theorem 8.4. Signer and verifier both feed it in as a digest.
DER encoding and the sighash-type byte. On the wire a signature is the DER encoding of —an ASN.1 SEQUENCE of two minimally encoded INTEGERs—followed by one trailing byte, the sighash type, selecting which parts of the transaction the sighash commits to ( for every signature the transaction builder emits; a signer working from a partially created transaction honours whichever valid type the input records). The signer appends the byte; the verifier splits it off and enforces strict DER unconditionally, the BIP-66 rule, so a malformed encoding fails script evaluation. The public key travels as its -byte compressed encoding, the bytes that commits to (§3.9).
Low- normalisation. If verifies then so does , so a third party can re-encode a valid signature and change a pre-ZIP-244 transaction id; the normalisation takes the representative (BIP-62), which the deployed signer always emits (secp256k1 crate, sign_ecdsa, whose libsecp256k1 backend documents the created signature as always in lower- form) and which script evaluation checks only under the LowS flag, one the consensus check does not set (zcash_script crate, src/external/pubkey.rs, check_low_s; zebra-script crate, src/lib.rs).
Write for the tagged hash with ASCII tag —domain separation in the sense of Definition 3.16, the doubled tag digest making the prefix a whole -byte SHA-256 block—and read digests as integers modulo .
Keys. Sample and set . The public key is the -byte coordinate alone (x-only): the verifier reconstructs as the point with that abscissa and even , and the signer replaces by when is odd, keeping the pair consistent.
: derive with for auxiliary randomness ; set , negating when is odd; compute and ; output the bytes .
: lift to the even- point , recompute , set , and accept iff is not the identity, is even, and .
The algebra is the Schnorr signature of Construction 8.12 in its form with key-prefixing (Remark 8.14), under of order and ; the unforgeability proof of §8.6 carries over with that tagged hash modelled as the random oracle. What differs is convention: points travel by abscissa alone with parity fixed by the even- rule, saving a byte per key and the parity of per signature and letting the same bytes serve as key encoding and as hash input; the challenge hash is domain-separated by tag; and the nonce is deterministic with optional auxiliary randomness, as in Construction 8.21. The in-series consumer is the issuance authorisation signature of Zcash Shielded Assets: ZIP 227 (specified, in a draft ZIP) instantiates as BIP-340 over secp256k1, prefixes both the validating-key encoding and the signature with a scheme byte , and signs the transaction’s sighash. The reference implementation, not yet deployed, is the QED-it fork of the orchard crate (commit cf801a5), src/issuance/auth.rs, whose ZSASchnorr signs through the secp256k1 crate’s BIP-340 routine with zeroed auxiliary randomness. The issuance protocol itself is the business of the ZSA Guide.