TapBranch

TapBranch is the internal-node hash function used to assemble a Taproot script tree from its leaves up to a single Merkle root. Where each individual script becomes a leaf hashed with hashTapLeaf, every parent node in the tree is computed as hashTapBranch(a || b), combining two child hashes into one 32-byte value. Applied repeatedly — pairs of leaves into branches, pairs of branches into higher branches — it condenses an arbitrary set of alternative spending scripts into the single Merkle root that the Taproot tweak commits to inside an output key. TapBranch is defined in BIP 341 and executes on every script-path spend your node validates.

Lexicographic ordering: the clever detail

TapBranch's defining quirk is that it sorts its two inputs before hashing: given children a and b, it hashes a || b if a is lexicographically smaller, otherwise b || a. This canonical ordering means the hash of a parent node is identical regardless of which child sat on the left or right in the tree as originally constructed. The practical payoff shows up at spend time: a verifier reconstructing the root from a revealed leaf and its Merkle proof never needs to be told the sibling's side. That removes one position bit per tree level from the control block, simplifies the format, and eliminates an entire class of encoding ambiguity — there is exactly one valid way to hash any pair of children, so there is nothing for implementations to disagree about.

Tagged hashing and domain separation

Like every hash in the Taproot design, TapBranch is a tagged hash: SHA256(SHA256(tag) || SHA256(tag) || data) with the tag string "TapBranch". The doubled tag digest occupies a full 64-byte SHA-256 block, which lets implementations precompute the hash state once and reuse it — a small but real efficiency win. More importantly, tagging provides domain separation: a TapBranch output can never be confused with a TapLeaf hash, a tweak hash, or a signature hash, because each uses a different tag. Without this, an attacker might craft data valid in one context and replay it in another; with it, every hash in the protocol carries an unforgeable statement of what it is.

Shape freedom and its consequences

BIP 341 deliberately does not mandate a balanced tree. A wallet is free to build any binary tree over its leaves, and the sensible strategy is a Huffman-style arrangement: place the scripts most likely to be used near the root, so their Merkle proofs — and therefore their witness bytes and fees — are shortest, and exile the unlikely emergency clauses to the deep branches. Two wallets committing to the same set of scripts in different tree shapes will produce different roots and different addresses; the tree's structure, not just its contents, is part of the commitment. Depth is capped at 128 levels, which still allows an astronomically large number of leaves.

Why a sovereign user should care

One more subtlety: because only hashes climb the tree, the parties assembling a shared Taproot output never need to reveal their scripts to each other to compute the root — each can contribute a subtree hash and keep its contents private even from co-signers. The commitment binds everyone to the full set of conditions while disclosing, at every stage from construction through spending, only what each party chooses to reveal.

TapBranch is the mechanism that lets a single, ordinary-looking address quietly commit to a whole vault design — timelocked recovery paths, multisig fallbacks, inheritance clauses — with only the executed branch ever revealed, and unused branches hidden forever behind their sibling hashes. Verifying it requires nothing but SHA-256 and comparison, cheap enough for the most modest full node. See how a single branch chain is proven during spending in Taproot Merkle Path, and how the resulting root binds into the output key via the Taproot Tweak.