Satoshi Hike Construction

1. Status

The status prose in this section is informative. The rule index is the ID-to-heading map. The subsection “Part A rule classes” is the normative classification.

This document is Satoshi Hike 2.3 Construction (Part A object definition). Part A is the construction: SAMPLE_BYTES 1024, STEPS_PER_LEG 2000000, KIND v2.2-pcoc-object, anchor-window offsets 2, 3, and 4, the NL4 terrain word, the §11.1 fold, and the asynchronous producer event model (Rule A6 lives in Producer Process). FRAMING. Unknown-kind measurement (Rule A5) and the full §14 measure procedure live in Measurement Record. Section 13.6 Bari waypoint service lives in Waypoint Publication. Part B admission levers, judgment, Rule B7/B9, and section 15.5 floor measuring method live in Admission Process (value-free process) and/or outside policy instances (gl-admit-*); this Construction file does not set lever values. Section 16.2 implementation requirements live in Conformance.

Rule index

Normative for the ID-to-heading map. The heading text in the section named is the rule. A test named for an ID tests that heading. This table does not add a second rule. Classes for these headings, and for unnumbered Part A sentences, are in “Part A rule classes” below.

Part A rule classes

Normative.

This subsection is the normative classification of Part A. It does not add a second construction. Each row is one rule and one class. Informative prose, section 5, section 13.6 (Bari rules BR1–BR4, classed there), section 16.2 (Rules I1–I6), section 7.4, section 13.4, the expected-case list in section 13.1, and sections 17, 18, and 19 are not rows. A glossary sentence that only renames a row is not a second row. The Normative and Informative marks on the sections a row cites stay where those sections put them.

Rule ID scheme.

• Heading IDs in the rule index stay A1–A5 and their dotted children. A heading that states one rule of one class is that row.
• When one heading states more than one class, the rows are ID.n in SPEC order (n starts at 1). Those rows are the classification. The parent ID is the group and is not given a second class.
• A2 is a group heading. A2.1–A2.4 are the rows. A2 is not a separate class.
• A normative Part A sentence that has no heading ID gets P<section>.<n>, in reading order. The digits before the first dot are the SPEC section number. P marks a Part A construction paragraph. It does not renumber A1–A5 and it is not Part B. An ID that is not in this table is unassigned and is not used.
• Classes are INVARIANT, CONSTANT, RANGE, and POLICY THRESHOLD. An INVARIANT holds byte for byte or as an exact measurement. A CONSTANT is a fixed parameter of this version. A RANGE is an allowed value or format. A POLICY THRESHOLD is admission only.
• Part A has no POLICY THRESHOLD row. Sentences that can be misread as thresholds are listed after the table and stay in the class written here. Admission thresholds are named parameters in section 15. Rule B9 is the one section 15 row in this table. It classes those refuses. It is not a Part A measurement.

Sentences reviewed for POLICY THRESHOLD. None of the rows above is a POLICY THRESHOLD. The sentences a reader might take for one are:

1. leg_count ≥ 1 (A3.2, A4.1.3, P13.1). It is the section 13.2 loop, recorded under shape. It is not an admission floor. Rule B8 sets no leg-count threshold.
2. Hashcash difficulty 21 (P13.5). It is a produce and Bari constant. It is not an admission threshold.
3. Section 9, “mean about 60 seconds.” That phrase describes the synth sequencer. It is not a section 6 constant, not a conformance-small parameter, and not an admission threshold.
4. Section 13.1, a stage that ends at leg_count = 1 “is conforming.” That sentence means the producer followed section 13. Judgment of the record is section 14.
5. Rule A4.9, the bookend pair (N, S). Section 14 records the integers. It does not apply leg_rate_floor. The admission rate is Rule B2 on (hike_legs, hike_span), not on (N, S).
6. The informative note under Rule A4.11 about the two, three, or four blocks from I_{b−1} to P_b. Those sentences are not a Part A number. Rule B3 is not an admission input and does not adjust hike_span.

No Part A sentence is moved into section 15 by this classification. Where section 14 says an admission service may judge a recorded token, the judgment stays in section 15.

2. Scope

Normative.

This document specifies Satoshi Hike 2.3.

A hike has exactly eighteen stages (Rule A2.1).

Section 13 produces the object. Section 14 measures it. Section 15 is the admission service. Produce and verify perform no signature check. The admission service checks the signature (section 15.1).

3. Interpretation

Normative.

“Must” and “must not” apply to a conforming producer, a conforming verifier, and a conforming admission service.

In this file, “must”, “must not”, and “may”, in lowercase or in capitals, carry the meanings that BCP 14 (RFC 2119, RFC 8174) gives to MUST, MUST NOT, and MAY. They state requirements only in text marked Normative. In normative text, a plain statement (“is”, “does”, “uses”, “is not”) is a requirement as well. Text marked Informative states no requirement. Where informative text uses one of these words, it restates a rule of the normative section it names, and that section governs.

Byte ranges are half-open. b[i:j] is bytes i through j-1 of b, starting at index 0.

0^n is the byte string of n zero bytes.

‖ is raw concatenation of byte strings, in the written order. A concatenation has no length prefix, no tag, and no separator.

le64(x) is the 8-byte little-endian encoding of the unsigned integer x with 0 ≤ x < 2^64.

u64_le(b) is the unsigned integer represented by the 8-byte string b in little-endian order.

mod is the non-negative remainder. For a ≥ 0 and m > 0, a mod m is the integer r with 0 ≤ r < m and a = qm + r for some integer q.

mod 2^64 on a u64 quantity is ordinary wrapping arithmetic on a 64-bit unsigned integer. The result is the low 64 bits, and overflow is discarded. That is this mod with modulus 2^64. It is the rule for the NL4 word, the parent indices, the slot mix, and the step’s u64 state. A mod with any other modulus stays the remainder above.

SHA-256 is the function specified by FIPS 180-4. Its output is 32 bytes. In this document, H means SHA-256.

4. Glossary

Normative.

The public key is the 32-byte string used below. Produce and verify do not test a signature on it.

Wording not used. Use the term in the table.

SEAL_DOMAIN pcoc-walk-v1 is an exempt wire constant. It is not wording from that table. The verify-record key seed_value and the token seed-value mismatch are exempt wire names. Do not rename them.

Part A (sections 8–14) does not say that verify or the object passes, fails, rejects, denies, or admits, and it does not say accept, refuse, revoke, or held. Those outcomes are section 15. Do not say “minimum legs per stage.” A per-stage rate is analysis. It is not an admission test.

6. Constants

Normative.

The six-leg check draws 6 legs. That count is not a constant in this table.

WORDS_PER_SLOT = SLOT_BYTES / 8. The divisor is the width of one little-endian u64.

N_SLOTS = TERRAIN_BYTES / SLOT_BYTES, and the division is exact: TERRAIN_BYTES = N_SLOTS × SLOT_BYTES.

OFFSET_MODULUS = TERRAIN_BYTES − SAMPLE_BYTES + 1.

The section 6 numbers for WORDS_PER_SLOT, N_SLOTS, and OFFSET_MODULUS are that production evaluation. They are not a second free constant. Under conformance-small the same formulas apply to that profile’s SLOT_BYTES, TERRAIN_BYTES, and SAMPLE_BYTES.

SEAL_DOMAIN is the twelve ASCII bytes 70 63 6f 63 2d 77 61 6c 6b 2d 76 31. It is exactly those twelve bytes.

Normative. Domain identifiers. The byte strings pcoc-walk-v1 (SEAL_DOMAIN), bari-hc-v2 (the Hashcash challenge prefix), pcoc-gate-signin-v1 (the sign-in challenge domain), and the /v1 HTTP route prefix are wire-format domain identifiers. Their digits are not specification versions and do not change with the version of this file. The only specification-version marker in an object is the kind label v2.2-pcoc-object (KIND).

There is no seed domain label. A domain label on the seed, or a squeeze of the seed to fewer than 256 bits, is not this construction.

STAGES is 18. That count, and the beacon count that goes with it, is a profile constant. It is not a security number. The description of this arbitrary profile size is 18 stages and 19 beacons (seed_beacon plus I_0 … I_17). The object stores 18 stage maps, numbered 0–17. Admission does not treat 18, 17, or 19 as a threshold.

7. Encodings

Informative. Summary. How integers, hexadecimal strings, and the hike object are written as bytes. Section 7.1 covers little-endian integers, 7.2 hexadecimal, and 7.3 the deterministic CBOR of the object and the order of the decode checks (malformed, then decode failure, then Rule A5). Section 7.4 gives worked checks.

Normative.

7.1 Little-endian integers

le64 and u64_le are defined in section 3.

The first eight bytes of a 32-byte string b are b[0:8]. Those bytes are SHA-256 output order when b is a digest: byte 0 is the first byte of the digest. u64_le does not reverse a digest a second time.

7.2 Hexadecimal

A hexadecimal spelling uses the digits 0-9, a-f, and A-F. Letter case does not change the value. The spelling contains no spaces.

A 64-digit spelling denotes 32 bytes. The first two digits are byte 0. Natural order is that spelling: byte 0 first. Bitcoin display order is the one reversal in section 9. A digest is not reversed a second time.

7.3 CBOR

The hike object is one CBOR data item, as defined by RFC 8949. The item is a map.

Produce emits the core deterministic encoding:

• definite lengths only
• unsigned integers in the shortest encoding
• no floating-point values, no tags, and no big-integer tags
• map keys sorted by the bytewise lexicographic order of their definite-length encodings

Every field name in this object is at most 23 bytes, so the first byte of an encoded key is 0x60 plus the name length. For the fields in section 8, that order is:

Top-level map. Keys sort by encoded length, then bytewise. steps_per_leg is 13 bytes. last_interrupt is 14 bytes. last_interrupt_height is 21 bytes.

1. fill
2. kind
3. stages
4. n_slots
5. public_key
6. slot_bytes
7. seed_beacon
8. sample_bytes
9. steps_per_leg
10. last_interrupt
11. last_interrupt_height

Stage 0 has no path key (Rule A3.3). Its map:

1. beacon
2. waypoint
3. leg_count
4. checkpoints
5. leg_results
6. beacon_height

Each stage map for stages 1–17:

1. path
2. beacon
3. waypoint
4. leg_count
5. checkpoints
6. leg_results
7. beacon_height

Text values and map keys are definite-length UTF-8 text strings (CBOR major type 3). A length from 0 through 23 is the additional information in the first byte. A longer string uses additional information 24, 25, 26, or 27 and the length bytes that follow, then the UTF-8 bytes. Indefinite-length text is not a text string in this object. KIND is 16 bytes, so the kind value is the head byte 0x70 and those 16 bytes. Byte fields are byte strings (major type 2). Counts and heights are unsigned integers (major type 0). Arrays are definite arrays in the order defined in section 8.

Verification decodes one definite-length CBOR data item and records section 14. These are decoding rules. A definite-length encoding of the section 8 values decodes. A non-shortest definite-length unsigned integer decodes when the numeric value is the same. Map key order is not a shape mismatch. Indefinite lengths, tags, floating-point values, simple values, negative integers, a map key that is not a text string, a duplicate key, and any byte after that one data item are a malformed CBOR value. A text string whose bytes are not valid UTF-8 (RFC 3629) is also a malformed CBOR value, including a map key and a kind value. It is not Rule A5 and it is not a decode failure. A malformed CBOR value is shape mismatch, and shape_item includes malformed cbor. Later measurements are still recorded. Produce is what fixes the canonical bytes. Verification sorts the input bytes in this order. First, input that is not one definite-length CBOR data item under these rules is a malformed CBOR value, whatever its first data item holds. That includes an empty input, bytes that are not CBOR, bytes that end inside an item, and a malformed item that is not a map. Rule A5 is not applied to a malformed CBOR value, even when a kind text can be read from it. Second, one well-formed data item that is not a map, or a map with no kind key whose value is a text string, is a decode failure: there is no section 14 record, and the verify CLI exits with code 1 (section 18). Third, a map whose kind text is not exactly KIND is Rule A5. Every other input is measured by section 14.

7.4 Checks

Informative.

le64(1) = 01 00 00 00 00 00 00 00.

le64(0x0102030405060708) = 08 07 06 05 04 03 02 01.

FIPS 180-4’s SHA-256 example for the three bytes abc is ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad.

SHA-256(SEAL_DOMAIN ‖ le64(0)) is the 32-byte digest whose hexadecimal spelling, byte 0 first, is 4816bdaf23240476ca57e168301eceee8eb8170ec5446863855e4ceebb55b533. The first eight digest bytes, in that index order, are 48 16 bd af 23 24 04 76. Their spelling in index order is 4816bdaf23240476. When S_folded = 0, section 11 sets S' = u64_le(E[0:8]), the little-endian integer of those eight bytes. That integer is 0x76042423afbd1648. E is that digest. D is the seed, not this digest. The spelling 4816bdaf23240476 is the digest bytes in index order. It is not the hexadecimal spelling of the integer S'.

A seed preimage of 32 bytes of 0x11 followed by 32 bytes of 0x22 has seed 5189c77d29fe5d546a045ec46986852785fea5c13ac7da9c115ff5fb6edf817c (byte 0 first). The four lanes are P[0] = 0x545dfe297dc78951, P[1] = 0x27858669c45e046a, P[2] = 0x9cdac73ac1a5fe85, P[3] = 0x7c81df6efbf55f11. The NL4 base word at i = 0, j = 0 is 0xc7582082a632c2c8. There is no fill pin.

8. Hike object

Informative. Summary. The hike object is one CBOR map. It holds the top-level fields, 18 stage maps numbered 0–17 with their beacons, heights, checkpoints, leg count, leg results, and waypoint (and, on stages 1–17, path), and last_interrupt (Rule A3). Verify (section 14) measures it, and section 15 judges it.

Normative.

Rule A3. What the object stores

The object has exactly these top-level fields:

Evidence and convenience. Evidence, the hash-bound values, is the seed preimage (public_key, seed_beacon), the checkpoints, the leg results, the waypoints W_1 … W_17, the Bitcoin headers (stages[g].beacon for g ≥ 1, and last_interrupt), the path’s leaf, Merkle path and root, which bind the path to the waypoint, stages[0].waypoint (the seed, SHA-256(public_key ‖ seed_beacon)), and any calculated field whose hash dependencies enforce order and cost. Convenience signposts are the path locators (txid, vout, block_hash, block_height), checked against the index, leg_count, beacon_height, last_interrupt_height, the section 6 constants, and stages[0].beacon (= seed_beacon). Verify records leg_count under shape: shape_item includes leg_count when it differs from len(checkpoints) (Rule A4.1). Section 6 constants are recorded as constant. Stored heights are recorded as index_comparison (Rule A4.2). They are convenience. d_g and delta_h do not subtract a stored height unless the index comparison that confirms it is match (Rules A4.5 and A4.8). Verify checks a convenience signpost against the evidence or the index and never relies on it. A broken signpost is a recorded mismatch. Section 15 is where an admission service may judge that recorded mismatch.

Rule A3.1 Headers

The field name beacon is kept.

• stages[0].beacon = seed_beacon, and stages[0].beacon_height is that header’s height.
• For g = 0 … 16, I_g = stages[g+1].beacon, and stages[g+1].beacon_height is the height of I_g.
• I_17 = last_interrupt, and last_interrupt_height is its height.

stages[g].beacon for g ≥ 1 is I_{g−1}, the interrupt stage g started from. It is not a second header read after the waypoint post.

For 0 ≤ g < 17, stages[g+1].beacon_height > stages[g].beacon_height, and stages[g+1].beacon differs from stages[g].beacon.

last_interrupt_height > stages[17].beacon_height, and last_interrupt differs from stages[17].beacon.

The object therefore carries seed_beacon and all 18 interrupts. The object carries no block time. Section 14 reads each block time from the portable index (sections 9 and 14.2).

Rule A3.2 Per stage

Stage 0’s map has exactly these fields. It has no path key.

Stages 1–17 each have exactly these fields:

len(checkpoints) = len(leg_results) = leg_count.

An object-byte height above 2^53 − 1, including beacon_height and last_interrupt_height, is not a usable unsigned value on the verify record. Section 14 records shape mismatch, shape_item includes height_range, and the value is not defined. It is not not read. Do not clamp the value and do not record it.

checkpoints[j] and leg_results[j] belong to the same leg.

stages[0].beacon = seed_beacon.

stages[0].waypoint = SHA-256(public_key ‖ seed_beacon).

Rule A3.3 Paths

Stage 0 has no path. The stage-0 map omits the path key. Omission is the encoding. An empty byte string is not a stage-0 path. The words “not planted by design” are not a token in this file.

Stages 1–17 each carry the path of their waypoint W_g, or empty bytes for a skip.

stages[17].path (W_17) is always the empty byte string. W_17 is not asked, including when a jump would put an offset at or below the cut-off (section 13.1). The record is not fetched by design.

Sixteen waypoints, W_1 … W_16, are fetchable. W_17 is not one of them.

A path key on stage 0 is a shape mismatch (Rule A4.1). Those bytes are not a path. Verify does not give them path semantics.

The object has no terrain field. A verifier recomputes terrain from public_key and seed_beacon.

A leg result on the object is le64 of the u64 defined in section 11, stored as an 8-byte byte string.

9. Clock

Informative. Summary. The clock is Bitcoin headers. Produce reads its plane’s tip sequence (Observe) for the seed beacon and each stage’s interrupt. Verify reads the stored headers back from the portable index {index-url}. This section states the read and body rules, the byte order of the header hashes, and the live-plane header source.

Normative.

{tip-url} and {index-url} are absolute URLs with scheme http or https (ASCII case-insensitive) and no trailing slash.

A clock read is one GET of a URL below. The reader does not follow a redirect. A status other than 200 is not a successful read. The reader does not require a particular Content-Type.

A successful body is UTF-8 JSON: one JSON object and no second value. A byte order mark (U+FEFF, the bytes EF BB BF) is not a successful read and is not stripped. Bytes that are not UTF-8 are not a successful read.

A body is one JSON object and no second value. If the same member name occurs more than once in any JSON object in the document, including a nested object, the read is not successful. The reader does not keep one of the repeated values.

Header measurement and plant measurement are separate reads of GET {index-url}/index/{height}. Each read parses the body on its own. The header measurement uses only header.hash, header.height, and header.time. It is a successful header read only when header is a JSON object and header.hash and header.height follow the rules below. A body with no header member, or a header that is not that object, is an unsuccessful header read: section 14.2 records index_comparison not read and T not read. network, plant, plants, and every member other than header.hash, header.height, and header.time do not change index_comparison or T.

The plant measurement does not require header. A plant read that returns a JSON object is a returned document. Section 14.3 then records plant match or mismatch from network and the plant records in that object. A plant read that does not return a document is plant not read. One returned document can be a header not read and a plant match: the document has network and a matching plant and has no usable header. The anchor-window vector’s height 4 is that document. The header reads for that vector return no document. The one issued plant read returns a document with no header member. A returned document with a usable header and no matching plant is a successful header read and plant mismatch.

header.hash is a JSON string of exactly 64 hexadecimal digits under section 7.2, so the digits are 0-9, a-f, and A-F, and letter case does not change the value. The string has no 0x prefix. The digits are Bitcoin display order. Let display be the 32 bytes of that spelling under section 7.2. The natural beacon is the 32-byte string natural with

natural[i] = display[31 − i]    for i = 0 … 31

That formula is the single reversal rule. Bitcoin display order is the natural 32 bytes reversed: display[i] = natural[31 − i]. Apply it only when reading a Bitcoin display hex string into natural bytes, or when writing natural bytes as a Bitcoin display hex string. Do not reverse between two values that are already natural order. Do not reverse a digest a second time.

Where each hash is written, and the order it uses:

• A SHA-256 digest in this file (the seed, a checkpoint, a waypoint, a fold, a Merkle leaf node, sibling, or root) is natural order. Byte 0 is the first byte of the digest. The object stores those 32 raw bytes. A hex spelling of them is byte 0 first.
• seed_beacon, stages[g].beacon, and last_interrupt are natural-order raw bytes.
• An index document’s header.hash is Bitcoin display hex. Reverse it once to natural order before comparing it with a stored beacon.
• A canonical path body stores block_hash and txid as 32 raw bytes in natural order, the same order as the object beacon. The interrupt-header check is the same height and those same 32 bytes, compared with the stored beacon, with no reversal.
• A path body’s root, leaf, and Merkle siblings are natural-order digest bytes. No reversal.
• An index plant’s root is hex in natural order. Compare it with the path root with no reversal.
• An index plant’s txid and block_hash are Bitcoin display hex. Reverse each once to natural order before comparing it with the path body.
• The verify record’s stored_hash is natural-order hex, byte 0 first.
• The verify record’s block_hash, on P_g, P_b, and claimed_block, is Bitcoin display hex: the reversal of the path body’s natural block_hash bytes. It is not a byte-0-first spelling of those bytes.
• A produce event-log tip or waypoint is natural-order hex, byte 0 first. An event-log block is the path body’s block_hash, byte 0 first. It is not display order.
• The Hashcash header_hash is natural order: SHA-256(SHA-256(header)) of the 80-byte fee header, not reversed. The challenge does not use display bytes. X-Bari-Hashcash-Header spells the 80 header bytes in wire order, byte 0 first.
• Every block-hash comparison in Rule BR1 (section 13.6) is natural order on both sides, with no reversal. For current, the hash of Bari’s tip is SHA-256(SHA-256(header)) of Bari’s tip header, natural order, the same bytes as header_hash. For before, the previous-block hash of Bari’s tip is the 32 bytes at offset 4 of Bari’s tip header, in wire order, which is natural order: SHA-256(SHA-256(header)) of the block before the tip, the same bytes as that block’s header_hash. For after, the fee header’s previous-block field is the 32 bytes at offset 4 of the fee header, in wire order, compared with the natural-order hash of Bari’s tip. The after proof-of-work check reads the natural-order SHA-256(SHA-256(header)) as a little-endian 256-bit integer. A tip hash that Bari learns as Bitcoin display hex, from an RPC, an index document, or a log, is reversed once to natural order before any comparison. Neither side is ever compared in display order. A fee header that matches Bari’s tip only when one side is reversed is not current, before, or after, and the POST is answered 402.
• The path-ask leaf is the waypoint’s hex, byte 0 first.

header.height is a JSON number in the range 0 … 2^53 − 1. It is not a JSON string. A JSON number written with a fractional part or an exponent is not a height. That bound is what this file states for a height. A height above 2^53 − 1 that an index document reports makes that read unsuccessful. Record not read. Do not clamp the value and do not record the oversized value. An integer above 2^53 − 1 in beacon_height or last_interrupt_height is recorded in section 14: shape mismatch, shape_item includes height_range, and the value is not defined. It is not not read. block_height in a body that decodes is in 0 … 2^32 − 1, which is inside 0 … 2^53 − 1. A hash-verified canonical path body has no height above 2^53 − 1. A body that does not decode, or whose validate_for does not succeed, has plant mismatch and claimed_block not defined. That is not shape_item height_range (P14.6). The hike object still decodes. not read is only for a read that is not hash-bound or whose hash does not agree.

header.time is the Bitcoin header nTime of the header at that height. It is a JSON integer in the range 0 … 2^32 − 1, in Unix seconds. It is not a JSON string. A JSON number written with a fractional part or an exponent is not a time. On the mainnet path, header.time equals the nTime of the block whose hash is header.hash. The portable index is faithful to Bitcoin: header hash, height, and nTime. Anyone may bypass the index and read Bitcoin directly (see §14). Section 14 measures the portable index. It does not read Bitcoin as its procedure. T(x) reads header.time from the portable index for block x only when Rule A4.2 records index_comparison match. Produce does not read header.time. Bari’s observed time (header.timestamp_unix_ms, when a document carries it) is a different member. Section 14 does not use it as T.

A read whose header has no time, or whose time breaks this rule, is still a successful read for hash and height when those members follow the rules above. T for that header is then not read. Section 14.2 records that token. A read that is not successful leaves both the index comparison and T as not read. T is taken only when section 14.2 records index_comparison match for that header. match requires the stored hash to agree with the index. A successful read whose hash does not agree is mismatch, and T is not read. Do not take that document’s time. A height disagreement is also mismatch, and T is not read on any mismatch. A successful read with a well-formed time does not record T when the hash does not agree.

The body rules above are the portable index. header.hash and header.height follow those rules for every header read. header.time follows them on a row that carries it. A plant read does not require them. A row with no header.time records T as not read. This file does not name a cut height and does not backfill a row. Produce Observe does not use that GET.

Produce Observe returns (natural, height) from the plane's one tip sequence. The default profile is the test plane. Its sequence is the synth sequencer (the synth tip sequence). Wire magic is regtest headers (header network magic for gossip). That magic is not a Bitcoin Core plant and not a tip clock. One cadence, mean about 60 seconds. “Mean about 60 seconds” describes the synth sequencer. It is not a section 6 constant, not a conformance-small parameter, and not an admission threshold. The natural beacon is that header's hash in natural byte order. Test Observe is that gossip peer. It does not GET an HTTP tip.

Synth headers. Every synth header carries the fixed nBits 0x207fffff. A synth header has valid proof of work when SHA-256(SHA-256(header)), read as a little-endian 256-bit integer, is at most the target that nBits encodes. On the test plane Bari applies that fixed nBits and that check for the Rule BR1 “after” case. The test plane keeps the same ±1 block contract as the live plane; only the block interval is shorter. Synth proof of work is cheap by design. A forged “after” header is valid only while Bari’s tip is unchanged, and it does not lower the 21-bit fee.

The live profile is explicit. Its sequence is the Bitcoin best chain, the chain with the most work, read by gossip. Live Observe does not GET an HTTP tip.

When no gossip peer is named, the starting list is a copy of Bitcoin Core's current mainnet DNS seeds (CMainParams::vSeeds in src/kernel/chainparams.cpp). The list is Core's own bootstrap. This specification does not invent a host. The copy is what lets a producer join gossip without naming one peer and without depending on any groundinglab node. A lookup of one seed returns node addresses. The producer connects to those nodes and asks them for more peers. An address that does not answer is dropped. That is how a producer stays independent of any single gossip peer.

Header source. On the live plane the producer’s header source keeps sessions with at least HEADER_PEERS_MIN gossip peers at the same time, for the whole run. HEADER_PEERS_MIN is 2. A peer announces a header when it relays that header or a header that builds on it. When one connected peer has announced a header and another connected peer has not announced it within HEADER_PEER_SILENCE_SECONDS of the first announcement, the silent peer is disconnected and replaced by a new peer from the starting list or from addresses that peers have given. HEADER_PEER_SILENCE_SECONDS is 120. Both values are constants of this file. They are not levers and not SDK options. While no peer announces a new header, no peer is replaced: a natural gap between blocks is not silence. When fewer than HEADER_PEERS_MIN peers are connected, the header source keeps connecting new peers asynchronously, backing off between attempts, and writes an alert record (section 13.5) named header_peers_low each time the count falls below HEADER_PEERS_MIN. The walk continues, the object is unaffected, and the run still follows this section. A header source built to use one peer does not follow this section. Keeping, replacing, and reconnecting peers is asynchronous work and never pauses a leg (Rule A6). The copied list is checked again against Bitcoin Core's mainnet chainparams when a producer release is cut.

The copy, in Core's order, is dnsseed.bluematt.me, seed.bitcoin.jonasschnelli.ch, seed.btc.petertodd.net, seed.bitcoin.sprovoost.nl, dnsseed.emzy.de, seed.bitcoin.wiz.biz, seed.mainnet.achownodes.xyz. The port is 8333. A named peer is still host:port when the producer supplies one. This specification does not name that host or port. The test profile does not use this list. Its Observe remains the synth peer.

Produce does not read {index-url}. Produce does not read an HTTP tip, including {tip-url}/index and {tip-url}/index/{height}.

Observe is that plane sequence and returns (natural, height).

The seed beacon is the natural beacon from the first successful Observe, taken at the start of produce, before any leg. It fixes the terrain. It is the header stage 0 starts from. That header is the latest one already on the tip sequence. Produce does not wait for a header mined after produce starts. A header that is minutes old is the seed when no later header has been read. After the terrain fill, stage 0’s legs begin from the seed. There is no Bari post before those legs. A later header is the interrupt I_0, read at the Observe after a checkpoint. It does not replace the seed. If the header source holds no header yet, the run has not started: produce keeps reading asynchronously until a seed read succeeds or the run is cancelled. No leg exists yet, so no leg is paused.

A stage ends at its interrupt. The interrupt is the first successful Observe, taken after a checkpoint has been recorded, that returns a natural beacon different from the header the stage started from and a height strictly greater than that header’s height. The header stage 0 started from is seed_beacon. The header stage g ≥ 1 started from is I_{g−1}. Both the hash condition and the height condition are required. If the tip moved by more than one block before that check, the interrupt is the tip as read. It is not an earlier header the producer did not read. The interrupt is a Bitcoin header interrupting the drive. The post-checkpoint tip read returns at once the latest header the producer’s header source already holds. It never waits for a header, a peer, or the network. A read that finds no newer header, or whose header source is unavailable, is not an interrupt: the stage continues with its next leg, and an unavailable source is logged (section 13.5).

The interrupt that ends stage g, for g from 0 through 16, is stored as stages[g+1].beacon. The waypoint W_{g+1} is built from that interrupt after it is read (Rule A1.3, section 12.2). The interrupt that ends stage 17 is last_interrupt. No second Observe replaces stages[g].beacon after the waypoint post. There is no rebinding.

A header newer than I_g is the next interrupt candidate. Produce reads it at the Observe after stage g+1’s first checkpoint, the same as any other header.

An Observe taken for the Hashcash fee header, a waypoint POST, or a path ask does not end a stage and is not I_g. Those reads, the POST, and the ask are asynchronous events (Rule A6). None of them pauses a leg.

Heights are stored on stages. A height is not an input to SHA-256 in this construction.

A clock read that does not succeed never stops the run and never withholds the object. A post-checkpoint tip read that does not succeed is not an interrupt: the walk continues with its next leg, and produce logs the transitory condition (section 13.5). An Observe for the fee header, a waypoint POST, or a path ask that does not succeed is a miss. Rule A3.4 records it and produce continues.

Verification does not Observe the tip sequence and does not GET an HTTP tip. Section 14.2 reads GET {index-url}/index/{height} under the body rules in this section, once for each stored header: each stage’s beacon_height, then last_interrupt_height. It records index_comparison and T for each. That read is part of the header measurement in section 14.2. It is not the only request verify may send: section 14.3 may read the same index for a present path’s plant facts. Verify does not GET a Bari path. The index is that plane's index. The default profile does not fill https://index.groundinglab.io.

10. Terrain

Normative.

seed_preimage = public_key ‖ seed_beacon          # 64 bytes, no separator, no label
D = SHA-256(seed_preimage)                        # the seed, 32 bytes
P[k] = u64_le(D[8k : 8k+8])                       # k = 0 … 3

The seed preimage is 64 bytes. It has no separator and no domain label. The seed is the 32-byte digest D. It is not a 64-bit pin. Lane P[k], for k = 0 … 3, is eight little-endian bytes of D. All 256 bits of D are the lanes. There is no fifth lane and no domain label on the seed. Informative. Leg 0 of stage 0 starts at S_0 = u64_le(D[0:8]) = P[0], and the first terrain-sample offset is P[0] mod OFFSET_MODULUS. The same 64 bits are lane 0, the first leg’s opening state, and that first sample offset. That reuse is the seed, by design. It is not a separate exploit.

Normative. Every terrain word depends on all 256 bits of the seed. A word map in which some word is unchanged when any one lane changes is not this construction. The NL4 base word below is that rule. Parent mixing and slot_mix do not remove it.

The seed equals stages[0].waypoint by design. Both are D. Nothing new is stored on the object.

Every integer step below is a u64. A sum or product written mod 2^64 wraps as section 3 defines: the low 64 bits are kept. The terrain is TERRAIN_BYTES bytes, filled below, and then left unchanged. Later beacons do not change it. Slot i, for 0 ≤ i < N_SLOTS, is

terrain[i × SLOT_BYTES : (i+1) × SLOT_BYTES]

Every load of slot i returns those same SLOT_BYTES bytes. The step does not write terrain.

10.1 mix64

mix64(x):
    y = (x + MIX_ADD) mod 2^64
    y = ((y XOR (y >> 30)) × MIX_MUL1) mod 2^64
    y = ((y XOR (y >> 27)) × MIX_MUL2) mod 2^64
    return y XOR (y >> 31)

>> is a logical right shift of a u64: vacated high bits are zero. It does not sign-extend. << is a left shift of a u64. The shift count is not reduced modulo 32. i << 32 is the slot index multiplied by 2^32 in that u64, and for every legal i the product fits in 64 bits.

10.2 Lanes

The four lanes are P[0], P[1], P[2], and P[3] from the seed, as section 10 states. A squeeze of the seed to one 64-bit fill pin is not this construction. Do not compute one. Do not use one.

Informative. Conformance does not require computing such a squeeze. The pack may publish a terrain digest made from a squeezed seed as a negative. An implementation that emits that digest does not conform.

10.3 Word rotation and parent indices

rotl(w, r) is w rotated left by r bits on a 64-bit word. Bits that leave the top re-enter at the bottom. rotl(w, 0) = w. In this section r is in 0 … 63.

floor_log2(n), for an integer n ≥ 1, is the greatest integer b with 2^b ≤ n.

reverse32(v) treats v as 32 bits, high bits zero when v < 2^32. Bit k of the result, with bit 0 the least significant bit, equals bit 31 − k of v.

For a slot index i with 1 ≤ i < N_SLOTS:

bits = max(floor_log2(i), 1)
bitrev_parent(i) = (reverse32(i) >> (32 − bits)) mod i

h = (i × MIX_ADD) mod 2^64
mul_parent(i) = floor(h / 2^32) mod i

Both parent values are integers in 0 … i − 1.

10.4 dag2 fill

Start from TERRAIN_BYTES zero bytes. For i from 0 through N_SLOTS − 1, build WORDS_PER_SLOT words and then store the slot.

The base word is NL4. For each j in 0 … WORDS_PER_SLOT − 1:

c = (i << 32) XOR j XOR WORD_XOR
t = mix64( P[j mod 4] XOR c )
t = mix64( t XOR rotl(P[(j + 1) mod 4], 17) )
t = mix64( t XOR rotl(P[(j + 2) mod 4], 31) )
t = mix64( t XOR rotl(P[(j + 3) mod 4], 47) )
w[j] = t

mix64 is §10.1, including the initial + MIX_ADD. A finalizer that omits MIX_ADD is not this function. i << 32 is the slot index multiplied by 2^32 in a u64, as under mix64 above: a left shift of a u64, and the shift count is not reduced modulo 32. j is the word index. j mod 4 selects a lane, and the next three steps fold the other three lanes in, so the word depends on P[0], P[1], P[2], and P[3].

A base word that uses one lane, two lanes, or a linear mix of the four lanes (including a map that is unchanged when two lanes are each replaced by their bitwise complement) is not NL4. Those maps are not conforming.

Informative. The one-lane map is mix64(P[j mod 4] XOR c). The linear map is one mix64 of P[j mod 4] XOR rotl(P[(j + 1) mod 4], 17) XOR rotl(P[(j + 2) mod 4], 31) XOR rotl(P[(j + 3) mod 4], 47) XOR c, with c as in the NL4 chain. Neither map is NL4.

Slot 0 keeps those words. It has no parent lanes and no slot mix.

When i > 0, take the three parents in this order, even if two of them are the same index:

1. i − 1
2. bitrev_parent(i)
3. mul_parent(i)

For parent number k in 1, 2, 3, and for each j in 0 … WORDS_PER_SLOT − 1, let p be that parent index and let pw be the little-endian word already stored at word j of slot p:

rot = (j + k) mod 64
w[j] = mix64( (w[j] XOR rotl(pw, rot)) XOR ((k × PARENT_MUL) mod 2^64) )

After those three parents:

slot_mix = (i × SLOT_MUL) mod 2^64
w[j] = mix64(w[j] XOR slot_mix)    for j = 0 … WORDS_PER_SLOT − 1

For every slot, including slot 0, write le64(w[j]) into word j of slot i.

Terrain is computed once per terrain, from the seed, before the first leg. That is once per PCOC for the producer and once per gate check for a verifier that rebuilds the terrain. It is not once per leg. The public key and the seed beacon enter only through the seed preimage.

11. Leg

Normative.

A leg is STEPS_PER_LEG steps. It starts from the previous checkpoint defined in section 12. The leg result is the u64 end state of the leg. The checkpoint is the digest below. Every leg in a stage uses the same 32-byte second limb: the seed on stage 0, and waypoint W_g on stage g ≥ 1.

11.1 Step

Let S be the current u64 state. One step computes the next state S'.

i = S mod N_SLOTS
slot = terrain[i × SLOT_BYTES : (i+1) × SLOT_BYTES]

slot is SLOT_BYTES long and contains WORDS_PER_SLOT little-endian words. Word w, for w = 0 … WORDS_PER_SLOT − 1, is u64_le(slot[8w : 8w+8]). The word index is the integer w.

acc = 0
for w = 0 … WORDS_PER_SLOT − 1:
    acc = (acc + mix64(word(w) XOR S)) mod 2^64
S_folded = acc
E = SHA-256(SEAL_DOMAIN ‖ le64(S_folded))
S' = u64_le(E[0:8])

mix64 is exactly §10.1, including the initial + MIX_ADD. A function that omits MIX_ADD is not mix64. A port that used that shorter function produced a different step. acc starts at 0, not at S. Each step of the loop adds the mix64 output with wrapping addition in mod 2^64. Equal words do not cancel under addition. An XOR of those outputs is not this fold. The per-word input is word(w) XOR S. There is no w term. The loop is every word in the slot. Under section 6, WORDS_PER_SLOT is 2048, so the production bound is w = 0 … 2047. Profile conformance-small (section 16.1) uses that profile’s WORDS_PER_SLOT in this same sentence. It does not change the production constant.

Normative. Every input to mix64 is word(w) XOR S. No per-word term is independent of S, so nothing can be pre-folded into the stored terrain. A transformed terrain array is not the §10.4 terrain and is non-conforming. Equal words do not cancel under addition.

Informative. The last stage of mix64 is y XOR (y >> 31), which is linear over GF(2). An accumulator that XORs mix64 outputs lets a producer apply that stage once to the XOR of the pre-final values. Wrapping addition is not that linear map, so that hoist does not compute this fold. mix64 itself is unchanged.

The fold S_folded = S XOR (XOR over w of (word(w) XOR w)) is not conforming. The parenthesised XOR does not depend on S, so one 8-byte value per slot can stand in for the slot. It is the negative slot_summary_fold. The XOR accumulator acc = acc XOR mix64(word(w) XOR w XOR S) is also not conforming. It is the negative xor_accumulator_fold. The wrapping-add fold acc = (acc + mix64(word(w) XOR w XOR S)) mod 2^64 is also not conforming. word(w) XOR w does not depend on S. It is the negative xor_w_fold. The wrapping-add fold acc = (acc + mix64(word(w) XOR ((S + w) mod 2^64))) mod 2^64 is also not conforming. It is the negative s_plus_w_fold. At S = 0 those two folds match each other, because (S + w) equals w, and both differ from this section: this section mixes word(w) XOR S.

Normative. Christian's requirement, in his words:

a deliberately inefficient algorithm on the hash principle in reverse; a hash can't rehydrate the 16 KB, so each step must be driven by the full 16 KB slot, and no digest, lookup table or smaller data can stand in for it. No efficiencies, caching, tables or partial reads anywhere in hike/fold/terrain. A producer speed-up is a suspected break: flag it, never merge it.

Normative. A conforming producer and a conforming verifier, on every step of every leg, load all SLOT_BYTES bytes of the selected slot from the terrain of this PCOC and mix each of the WORDS_PER_SLOT words with the current state S by the §11.1 loop, including mix64 with MIX_ADD. The load is SLOT_BYTES bytes per step. A value computed on an earlier step does not satisfy the load on this step. A table, a digest, a per-slot summary, or any value shorter than the slot does not satisfy the load. Terrain is filled once for this PCOC from this seed, by §10.4, before the first leg, and is not shared with another PCOC and not reused from an earlier PCOC. The same rule applies to a gate recomputing a leg: one terrain for that check, then one full slot load mixed with S on every step of every recomputed leg. A producer or a verifier that emits the same leg, checkpoint, or waypoint bytes by a shorter load is non-conforming. A producer speed-up is a suspected break: flag it, and do not merge it. One terrain fill for this PCOC, shared by every leg of that run, is required. It is not a cache of an earlier step and it is not a cache shared with another PCOC. Running the legs of one round concurrently is not an efficiency. Each step still reads the full slot and mixes every word with S.

SEAL_DOMAIN ‖ le64(S_folded) is 20 bytes. That is one SHA-256 block.

Informative. The baseline that sets the floor and the gate policy is commodity hardware with SHA-256 instructions, x86 SHA-NI or Armv8 SHA2, of the commodity laptop with SHA instructions (for example an AMD Ryzen 5 5600H).

Normative. Where the host provides SHA-256 instructions (x86 SHA-NI or Armv8 SHA2), an implementation uses those instructions for every SHA-256 in this construction: the seed, the seal, the checkpoint, the waypoint fold, and the waypoint. A software SHA-256 is permitted only where the host has no such instructions. This requirement does not change a byte. A vector match does not excuse a software SHA-256 on a host that has the instructions. Hardware SHA-256 and software SHA-256 give identical bytes. A vector does not test which one ran. The rule is there so a measured rate is the rate of the baseline host.

E[0:8] is the first eight bytes of the seal digest E in index order, byte 0 first. S' = u64_le(E[0:8]) is the little-endian integer of those bytes. It is not the integer whose big-endian hexadecimal spelling is the same eight bytes. S and S' are 64-bit unsigned integers under the wrapping rule in section 3. The step does not keep a wider integer. Section 7.4 records the S_folded = 0 check: those eight digest bytes spell 4816bdaf23240476 in index order, and the integer S' is 0x76042423afbd1648.

The step reads terrain and does not write it.

11.2 Leg result

S_0 = u64_le(previous_checkpoint[0:8])
S_{t+1} = Step(S_t)    for t = 0 … STEPS_PER_LEG − 1
leg_result = S_{STEPS_PER_LEG}

leg_result is a u64. On the hike object it is the byte string le64(leg_result).

11.3 Terrain sample

The terrain sample at a previous checkpoint is a contiguous window of SAMPLE_BYTES bytes. It is not aligned to a slot boundary.

offset = u64_le(previous_checkpoint[0:8]) mod OFFSET_MODULUS
terrain_sample = terrain[offset : offset + SAMPLE_BYTES]

The offset is taken from the first eight bytes of the previous checkpoint. The window itself is the sample.

This window is not the waypoint’s slot sample. The slot sample is defined in section 12.

11.4 Checkpoint

Rule A2.3. The checkpoint bind, in order, is

H(previous checkpoint ‖ stage limb ‖ terrain sample(at previous checkpoint) ‖ leg result)

H is SHA-256. The stage limb is the seed on stage 0 and W_g on stage g ≥ 1. The four limbs are raw bytes:

The preimage is 32 + 32 + SAMPLE_BYTES + 8 bytes. Under section 6 that is 32 + 32 + 1024 + 8 = 1096 bytes. On stage 0 the second limb is the seed.

The stage path is not a limb of this preimage. Stage 0 has no path.

The checkpoint is the 32-byte digest. The hike object stores that digest and the matching leg_results limb. The first limb is the full 32-byte previous checkpoint. The eight bytes that select the terrain sample are not a substitute for that limb. The leg result appears only as the fourth limb.

12. Stage and waypoint

Normative.

Stages are stages[0] through stages[17].

A stage contains one or more legs. The count is how many legs the drive in section 13 recorded before interrupt I_g. Every leg in stage 0 uses the seed as its second checkpoint limb. Every leg in stage g ≥ 1 uses waypoint W_g.

12.1 Previous checkpoint

Rule A2. Stages and where leg 0 starts

Rule A2.1 Eighteen stages

seed_beacon plus the 18 interrupts gives 18 stages, numbered 0–17.

Rule A2.2 Leg 0

The seed is

stages[0].waypoint = SHA-256(public_key ‖ seed_beacon)   # the seed; 64-byte seed preimage; no label

The seed equals stages[0].waypoint by design. That field is the seed. It is not a Rule A1 waypoint. It is stored on the object. It is the stage limb of stage 0’s checkpoint preimages (section 11.4). It is the third limb of W_1’s preimage (section 12.2). It is never posted to Bari. Stage 0 has no waypoint of its own. The seed is not one of W_1 … W_17.

Leg 0 of stage 0 starts from the seed. Leg 0 of stage g ≥ 1 starts from W_g:

stage 0:           previous = stages[0].waypoint    # the seed
stage g, g ≥ 1:    previous = stages[g].waypoint    # W_g

Leg j for j ≥ 1 uses previous checkpoint checkpoints[j − 1] of that same stage.

The public key reaches every later checkpoint, fold, and waypoint through the seed.

A stage does not carry the last checkpoint of the previous stage forward. The previous stage’s checkpoints reach the next stage through the fold in its waypoint (section 12.2).

Rule A2.3 Checkpoint

The checkpoint preimage is section 11.4. The stage limb is the seed on stage 0 and W_g on stage g ≥ 1. Leg 0’s previous checkpoint is that same value. Leg j ≥ 1 uses checkpoints[j − 1] of that stage.

Rule A2.4 First post

The first Bari post is W_1, after I_0. Stage 0 has no plant and no path.

12.2 Waypoint

Waypoint preimage

Rule A1.3. For g from 0 through 16, after stage g has ended at interrupt I_g, produce computes W_{g+1} as follows. B is I_g, in natural order. It is stages[g+1].beacon. B is not stages[g].beacon. W is stages[g].waypoint: the seed when g = 0, and W_g when g ≥ 1. C[0] … C[n−1] are stages[g].checkpoints in leg order. n ≥ 1. fold_g is the fold below.

F_0 = 0^32
F_{j+1} = SHA-256(F_j ‖ C[j])    for j = 0 … n − 1
fold = F_n                        # fold_g

slot_index = u64_le(B[0:8]) mod N_SLOTS
slot_sample = terrain[slot_index × SLOT_BYTES : (slot_index + 1) × SLOT_BYTES]

W_{g+1} = SHA-256(B ‖ slot_sample ‖ W ‖ fold)

That concatenation order is normative. B is the interrupt I_g, in natural order, stored as stages[g+1].beacon. slot_sample is the terrain slot indexed by I_g’s hash. The preimage is 32 + SLOT_BYTES + 32 + 32 bytes. Under section 6 that is 32 + 16384 + 32 + 32 = 16480 bytes.

The stage path is not an input to this preimage.

F_0 is the start value of the fold. It is not itself hashed. When n ≥ 1, the first hash in the fold is SHA-256(0^32 ‖ C[0]).

Produce requires n ≥ 1. An empty checkpoint list is a shape mismatch (leg_count when that count differs from len(checkpoints)), not a skipped waypoint.

Verify still applies this fold when both stages of the pair are present and the checkpoint bytes are usable. n = 0 leaves fold = F_0 = 0^32 and performs no hash. Verify recomputes W_{g+1} from that fold and records mismatch when the digest differs from the stored waypoint. That stage’s legs is []. not defined is recorded only when the stage pair is absent or the bytes needed for the recompute are absent or unusable. An empty checkpoint list is usable. whole_hike_legs adds each stage’s checkpoint count, including zero, when every stage from 1 through 17 has a usable count. A missing stage leaves whole_hike_legs not defined. hike_legs counts those same checkpoints. Stage 0 is in neither count. six_leg is not defined when leg_total < 6.

W_{g+1} is the pivot. It ends stage g and starts stage g+1. Produce posts it to Bari with the Hashcash fee (section 13.1). Leg 0 of stage g+1 starts from it.

W_1 is built after I_0 from that interrupt, its slot sample, the seed, and the fold of stage 0’s checkpoints. It is the first waypoint posted to Bari.

Stage 17 ends at I_17. No waypoint is computed from stage 17 or from last_interrupt. Stage 17’s checkpoints are not folded into a waypoint.

12.3 What a stage stores

When stage g ends at I_g, the object records the header the stage started from (beacon and beacon_height), the seed or the waypoint the stage’s legs used, leg_count, checkpoints, and leg_results.

For g from 0 through 16, I_g is stored as stages[g+1].beacon and stages[g+1].beacon_height. I_17 is stored as last_interrupt and last_interrupt_height.

Stage 0 has no plant and no path key. No ask is made for stage 0.

The path ask window is section 13.1. No ask is made above the cut-off. A waypoint W_1 … W_16 with no checked path stores empty bytes and produce writes path_skip <g> (Rule A3.4). W_17 stores empty bytes and produce writes not fetched by design 17.

14. Verify — relocated

FRAMING (2026-10-24). The measurement procedure formerly inlined here as §14 Verify (Rule A4, §§14.1–14.7, Rule A5) was relocated without wording change to 06-Measurement_Record_Process.md. Construction defines the object; Measurement reads a finished object against Construction and emits the fact record. Rule-index rows A4/A5 above still identify those rules.