Taproot merkle branch

Each hash in the branch is one sibling from the taptree, in order from your leaf upward to the root. BIP-341 caps the branch at 128 hashes, 4,096 bytes, and its sorted tree means the branch carries no left-or-right direction bits at all. Your branch length is public, so a deeper leaf leaks the minimum depth of your tree and hints at which wallet built the output.

How it works

A Taproot merkle branch travels inside the control block, the last item on the witness stack of a script path spend once any annex has been removed.

The control block has a fixed shape. Byte zero carries the leaf version plus the parity of the output key's Y coordinate. Bytes 1 through 32 hold the internal public key. Everything after that is the branch: m consecutive 32-byte hashes, so the control block measures 33 + 32m bytes, and m must be an integer from 0 through 128. Any other length fails the spend before a single opcode runs.

Verification starts at the bottom. A node hashes the revealed script under the TapLeaf tag, then folds in each branch hash in turn under the TapBranch tag, comparing the two 32-byte values lexicographically at every step and hashing the smaller one first. What comes out is the taptree root, which is hashed with the internal key under the TapTweak tag, added to the internal point, and checked against the 32 bytes in the output being spent.

That comparison is the whole trick. Because BIP-341 sorts the two children before hashing them, a branch never says which side a sibling sat on: the verifier works it out. The rationale is blunt about why, saying the design does not care about the position of specific scripts in the tree, only that they are actually committed to.

The 128 ceiling is a security bound rather than an arbitrary cap. Depth in an optimally packed tree runs near the base-two logarithm of one over a leaf's probability, so depth 129 would mean a script with a chance of use below 1 in 2^128, which BIP-341 says can probably be deleted instead. At the other end, a single-leaf taptree has an m of 0, an empty branch, and a tapleaf hash that is already the root.

Where you see it

Taproot merkle branches show up in any transaction that spends a bc1p output by revealing a script instead of signing with the key.

BIP-341 works one example on a tree of five leaves. A, B, C and E are TapLeaf hashes and AB is a TapBranch hash over the first two. To spend using script D the control block carries C, then E, then AB: three hashes, 96 bytes of branch, a 129-byte control block. E is hashed before CD when those two combine, because E sorts lower.

The privacy cost is what to plan around. BIP-341's security section says the depth of a script leaks the minimum depth of the tree, which suggests the wallet software that built the output and helps chain analysis cluster addresses, and it recommends deviating from the tree the leaf probabilities would give you. Leaf reuse is the other trap: spending a different output can republish the same branch hashes, so two spends sharing a 32-byte sibling look related.

Taproot merkle branch vs merkle block

A Taproot merkle branch proves a script belongs to an address; a merkle block proves a transaction belongs to a block. The taptree branch is consensus-critical, recomputed by every full node validating the spend, and it is position-free because sorting removed the need to say left or right. A proof over a block's transaction tree cannot borrow that trick, since the order of transactions under a block's merkle root is fixed and meaningful, so it has to carry the walk as well as the hashes.