Zcash transactions are grouped into blocks, and every block names its parent by including the parent header’s hash (Crypto Guide, §“Hash functions and the random oracle model”); the genesis block alone has no parent. Blocks therefore form a tree rooted at genesis, and each root-to-leaf path — each branch — is one internally consistent version of history. Branches need not be consistent with one another: one branch can contain a transaction that conflicts with a transaction in a sibling branch, and that freedom is exactly the attack surface this volume quantifies.
A single coherent history requires a rule every node can apply locally and use to converge once one valid branch is strictly preferred. The rule is not simply “longest”: it weighs each block by the computational effort represented by its header target.
Let be the conversion from the header’s nBits field to its 256-bit target threshold (specification §7.7.4). The work of a block is
(specification §7.7.5, “Definition of Work”). A lower target admits fewer valid headers, so a block meeting it certifies proportionally more expected hashing; work is that certificate made additive.
The deployed Zebra validator computes this quantity with a 256-bit in-word
trick: zebra evaluates
(!expanded.0 / (expanded.0 + 1)) + 1; the retired
zcashd computed the identical
expression on arith_uint256, with ~
spelling the complement. The form
agrees with
Definition 2.1 exactly: writing for the target and
, the complement is , and
so the in-word computation equals the out-of-word quotient (checked by script over random targets).
Rosenfeld’s paper states the same rule for Bitcoin — “the branch representing the most proof of work”, with first-seen tie-breaking — so the model uses the same selection rule. The shorthand “longest chain” is exact only while difficulty is constant, which is precisely the paper’s Assumption 4.2 and not a property of the deployed chain (Section 8.2). Note also what the rule does not say: nothing marks a chain as permanently chosen. A node that learns of a heavier branch switches to it, however deep the fork point — subject only to the node-local rails of Section 8.4. Consensus is a standing competition, not an election with a winner.
A transaction has confirmations if it is included in a block of the best chain and there are blocks on the path from that block to the chain’s leaf, inclusive. The block containing the transaction is its first confirmation.
Different nodes may briefly disagree on the best chain when two blocks of equal cumulative work arrive in different orders. Absent a concurrent extension of the other branch, a later block makes one branch strictly heavier, and nodes converge on it once that block propagates (Figure 1). Such ties are the benign case. The attack of Section 5 is the malicious one: a fork manufactured in private and released only when it wins.
The double-spend attack, as the paper lays it out (§3):
broadcast a transaction paying the merchant;
secretly mine a branch from the last pre-transaction block, containing instead a conflicting transaction paying the attacker himself;
wait until the merchant’s transaction has confirmations and the merchant, satisfied, hands over the goods;
in the paper’s first-seen tie model, keep extending the secret branch until it carries more work than the public one, then broadcast it. Every node that sees it switches to it, the payment to the merchant is no longer part of history, and the attacker has both the goods and the coins.
Nothing in step 4 violates any validity rule — the released branch is a perfectly well-formed chain, merely a different one. The only question is probabilistic: with what probability does the secret branch ever get ahead? Answering it exactly in that first-seen model is the business of Sections 4 and 5; the toolkit comes first.