jonnify·bcs /bcs/ideas/identity-contract/placement-not-security

B1.2 · dive 3 of 4 — the placed property

Placement, not security.

hash32 is one finalizer round from MurmurHash3 — xor-shift, the fmix64 multiply constant, xor-shift, truncated to 32 bits. Any holder of an id computes where its row lives — trie slot, cache shard, partition, queue lane — with no directory and no rendezvous.

The same answer everywhere: 234878118 for the reference id, reproduced by Elixir, Rust, C, TypeScript, wasm, Go, and SQL in this repository's committed outputs, at 0.9586 nanoseconds in pure Go.

The round, step by step — applied to the reference snowflake 274557032793636864 (formula: content/contract.md §6; result: content/vectors.json). Select a stage; the value after it is computed live.
k = snowflake 274557032793636864 k ^= k >> 33 xor-shift k ×= 0xFF51AFD7ED558CCD wraparound multiply, mod 2⁶⁴ k ^= k >> 33 xor-shift k mod 2³² hash32 = 234878118 one round of fmix64 — the constant carries Appleby’s public-domain lineage
readout · Select a stage. The committed vector: hash32(274557032793636864) = 234878118 (content/vectors.json) — the value the live computation below must land on.
§1

The formula, frozen

content/contract.md §6
content/contract.md §6 · the placement hash, normativefrozen
k = snowflake
k = k XOR (k >> 33)
k = (k × 0xFF51AFD7ED558CCD) mod 2^64
k = k XOR (k >> 33)
hash32 = k mod 2^32

The constant carries Appleby's public-domain lineage, but the full finalizer's avalanche certificate does not transfer to a single round — so the distribution this series relies on is measured directly over snowflake-shaped inputs in the committed hash audit (bcs_hash_audit.out). Hosts without native unsigned 64-bit arithmetic emulate the multiply exactly: the BEAM uses bignums then masks, SQL splits 32-bit halves, JavaScript uses BigInt.

§2

The same answer everywhere

content/vectors.json · vectors.hash32

Seven runtimes — Elixir, Rust, C, TypeScript, wasm, Go, and SQL — reproduce 234878118 for the reference id in this repository's committed outputs. Adjacent inputs land far apart: one trailing bit between …864 and …865 separates 234878118 from 989747343.

content/vectors.json · the hash32 vectorsfrozen
hash32(274557032793636864)   = 234878118   ← the reference id
hash32(274557032793636865)   = 989747343   ← one trailing bit away
hash32(0)                    = 0
hash32(1)                    = 2466077478
hash32(4611686018427387904)  = 3201652940
hash32(9223372036854775807)  = 2186628710
§3

Lanes, run by hand

content/contract.md §6 · consumers and evolution

Placement over the six committed vectors. Select a snowflake; a pure function replays the round, asserts the committed hash, and takes hash32 mod 2⁸ — the power-of-two modulus the contract bounds uniformity-critical consumers to (k ≤ 8). One function routes a CHAMP slot, a cache shard, and a hash partition; the routing table is retired.

lane · Select a snowflake. The lane is hash32 mod 256 — arithmetic any holder runs identically, in any runtime, with no directory and no rendezvous.

Fairness across small or odd lane counts is constructed by round-robin assignment, never hashed; the 5-bit trie windows are clean at every level on the committed audit's evidence.

§4

The hard edge

content/bcs1.2.md · Decisions

This is placement, not security. A non-cryptographic finalizer with no key is exactly the wrong tool wherever an adversary chooses inputs: the odd multiply and the xor-shift are both invertible, so truncation's 2³² preimages are the only veil. The contract states the edge and the manuscript repeats it — the round's virtue is spread, not secrecy.

Should a future measurement find pathology, the successor is hash32/v2 — the full two-round finalizer — behind a wire-version bump with a dual-placement migration window: placement evolution is a planned lane, not an emergency (content/contract.md §6).

§5

References

sources · related

Sources

Related