Inclusion and block links
The witness supplies a miner transaction, two transaction-tree paths, and 1–65 block hashing blobs. The first blob is the payment block; the last is the work block. They may be the same.
Height from the miner transaction
Section titled “Height from the miner transaction”Require a version-2 miner transaction with tagged-key outputs, one txin_gen input, and null RingCT. Its encoded height must satisfy payment_height >= min_payment_height. Its hash occupies leaf zero in the payment block’s transaction tree.
Two exact transaction-tree paths
Section titled “Two exact transaction-tree paths”Use Monero’s canonical tree_hash shape and sibling order:
- Miner transaction index 0.
- Payment transaction index greater than 0 and less than the transaction count.
Both paths must reach the hashing blob’s transaction root and contain exactly the siblings required by their count/index. Monero does not use Bitcoin’s duplicate-last-leaf tree.
Hashing blob layout
Section titled “Hashing blob layout”Every blob requires major version 16, canonical varints, and no trailing bytes:
varint(major_version)varint(minor_version)varint(timestamp)previous_block_id[32]nonce[4 little-endian bytes]transaction_root[32]varint(transaction_count)These are hashing blobs, not serialized full blocks. Compute each link ID as:
link_id(blob) = Keccak256(varint(byte_length(blob)) || blob)The next blob’s previous-block field must equal that ID.
Links and work
Section titled “Links and work”MAX_BLOCK_LINKS = 64 bounds the path. Every adjacency is checked; RandomX is computed only on the final blob. Intermediate heights, timestamps, full transactions, and separate work results are not verified. Link count measures commitment distance, not cumulative work or confirmations.
See RandomX for the target and witness encoding for framing.