Bloch-SIS-PoW, explained down to the source.

0 · Block & header structure

What a block actually is, field by field.

A block (crates/bloch-crypto/src/core/mod.rs::Block) carries a header, a transaction list, DAG accounting fields, and the PoW witness itself:

This matches a live sample from getblockbyheight queried against the public node (see RPC reference): hash, height, blue_score, bits, nonce, merkle_root, parents[] — the RPC layer surfaces exactly these fields, plus a derived size and the transaction list.

Three different hashes, three different jobs

The source computes block-related hashes for three distinct purposes — worth naming precisely rather than assuming there's just one "the block hash":

• Block identity (block_hash()) — SHA3-256("BLOCH-BLOCK-ID-V1" ‖ pow_preimage ‖ nonce ‖ pow_solution). This is the hash used everywhere that matters for consensus and storage: genesis registration, DAG insertion, block storage indexing, and reorg bookkeeping all key off this value (confirmed by direct usage in src/main.rs, src/storage/mod.rs, src/reorg.rs). Binding the PoW solution into the identity hash prevents witness-malleability — you cannot take a valid block and swap in a different valid solution for the same header without changing its hash.
• ASIC-facing mining hash (pow_hash()) — double-SHA256 (SHA-256d) over an 80-byte MiningHeader projection laid out exactly like Bitcoin's classic header (version‖prev_hash‖merkle_root‖timestamp‖bits‖nonce), used only by the Stratum V1/V2 mining path so existing SHA-256d ASIC firmware and pool software can search a nonce in a familiar 80-byte shape. It is not the consensus PoW check — the source is explicit that "SHA-256d is gone" as a validity rule; this hash exists purely for hardware/pool wire compatibility during nonce search.
• DAG indexing hash (dag_hash()) — SHA3-256 over the full, untruncated header serialization (all fields, not the 76-byte PoW projection), used internally for DAG reachability bookkeeping, kept distinct from PoW hashing on purpose.

How multiple parents become one 32-byte commitment

The Module-SIS PoW seed needs a fixed-size preimage, but parents is a variable-length DAG reference list. The header's 80-byte mining projection folds it down via parents_commitment(): sort the parent hashes ascending (so gossip reordering never changes the result), then pairwise SHA-256d-reduce them Bitcoin-merkle-style (duplicating the last element when the level is odd) until one 32-byte root remains — zero parents (only genesis) yields all-zero, one parent passes through unchanged.

The compact difficulty target — Bitcoin-style nBits

The header's bits field is a 4-byte compact encoding of a 256-bit target, "identical in spirit to Bitcoin's nBits" per the source's own comment: the top byte is an exponent, the low 24 bits a mantissa, decoded as target = mantissa << (8 × (exponent − 3)). A live sample from the public node: bits: "0x203fffc0" (from a getblockbyheight query). Retargeting runs on every block via ASERT-Lattice — an Absolutely Scheduled Exponentially Rising Targets algorithm anchored at genesis, tuned for a 30-second block time with a 2-day half-life and clamped to at most a 4× change per single retarget step (MAX_FACTOR = 4) to bound timestamp-manipulation attacks.

Source: crates/bloch-crypto/src/core/mod.rs (BlockHeader, Block, MiningHeader, parents_commitment, hash methods), crates/bloch-sis-pow/src/difficulty.rs (compact bits codec, ASERT-Lattice).

1 · Proof-of-Work

SHAKE-256 hashcash with a Module-SIS structural gate.

Bloch-SIS-PoW's proof-of-work is not "lattice-hard" in the sense of resting its security on the hardness of a Module Short Integer Solution (SIS) problem. It is a SHAKE-256 (Keccak) hashcash — cumulative work against a leading-zeros target, exactly like Bitcoin's SHA-256d, except the hash function is SHAKE-256. Layered on top of the hashcash is a Module-SIS structural gate: before a candidate's hash is even checked against the difficulty target, its accompanying solution vector must satisfy a short-vector condition over a lattice built from the block header. The gate does not replace hashcash security — it filters the search space and ties every valid block to a lattice-structured object, in the same algebraic family (same prime modulus q) as the chain's post-quantum signatures.

The three conditions a solution must satisfy

Conditions (1)+(2) are the Module-SIS structural gate: s must be a short vector (every coefficient in [-2, 2]) whose product with a header-derived matrix lands close to a header-derived target, modulo the prime q = 2²³ − 2¹³ + 1 = 8,380,417 — the same modulus ML-DSA-65 (FIPS 204) uses, chosen deliberately so the number-theoretic transform can be shared between the PoW and the signature subsystem. Condition (3) is the actual hashcash difficulty target: a SHAKE-256 digest of the solution, nonce, and header must fall below a threshold, exactly the "leading zero bits" difficulty familiar from Bitcoin.

Step by step: how Block::validate_pow() actually checks a block

Two details worth making explicit: the residual width k is selected by the height of the block being validated, never the validator's current tip — so an attacker cannot lie about height to get an easier check (a height claimed too high only makes validation stricter, and the real height is independently checked before this runs). And the PoW seed's nonce is a full u64 supplied outside the 76-byte preimage — the crate's own seed derivation is SHAKE256(DOMAIN_SEED ‖ preimage ‖ nonce), matching the formula at the top of this section exactly.

Why the residual gate checks only k coefficients, not all m

Checking the residual against all 512 rows is not a stronger "canonical" mode — the source is explicit that at β = q/16 that configuration is simultaneously trivial for lattice reduction (√M·β ≥ q) and infeasible for honest small-s mining, broken in both directions. The design instead checks a small k of the rows, kept deliberately outside that trivial regime (√k·β < q), so the gate contributes a fixed rejection floor of roughly k · log₂(q / 2β) bits — about 12 bits at the live k = 4, about 24 bits at the candidate k = 8 — without ever becoming the chain's actual security source.

The security model, stated the way the source states it

A trapdoorless PoW cannot be simultaneously lattice-hard and mineable: with no trapdoor, the same short-vector search that an honest miner runs is also the attacker's cheapest attack, so the "hard" and "mineable" regimes are provably disjoint at any single parameter set. Bloch-SIS-PoW's designers made this trade-off explicit rather than papering over it: the PoW's security is the cumulative SHAKE-256 hashcash work, full stop — no "N-bit lattice security" number attaches to any k. The Module-SIS gate is a structural filter that binds work to a lattice form (useful for tying the PoW to the same algebraic family as the signatures, and for future research directions), not the source of hardness.

Its post-quantum property, likewise, comes from the hash function: SHAKE-256 gives Grover's algorithm only a quadratic speedup against preimage/collision search, the standard post-quantum posture for hash-based constructions — not from any lattice hardness claim.

Source: crates/bloch-sis-pow/src/{lib.rs,params.rs}, crates/bloch-crypto/src/core/mod.rs (soft-fork activation constants), and the crate's own README, which we've paraphrased and checked figures against rather than invented.

2 · Signatures

Hybrid Falcon-1024 ‖ ML-DSA-65 — both must verify.

Every Bloch-SIS-PoW key, and every signature, is a concatenation of two independent post-quantum signature schemes: ML-DSA-65 (NIST FIPS 204, the standardized successor to CRYSTALS-Dilithium) and Falcon-1024 (a NIST-selected lattice signature scheme built on NTRU lattices). A signature verifies only if both halves independently verify.

Category numbers are the schemes' own published NIST security categories, not a protocol-specific claim — included here for context, not sourced from the Bloch-SIS-PoW repository itself.

Why hybrid, not just one scheme

Two independent lattice constructions, from different underlying assumptions (module lattices for ML-DSA, NTRU lattices for Falcon), mean a cryptanalytic break of one scheme does not by itself forge a valid signature — the attacker still has to break the other. It's belt-and-suspenders against the risk that any single, relatively young standardized post-quantum scheme has a weakness nobody has found yet. The cost is size: a hybrid public key and signature are roughly the sum of both schemes' sizes, several times larger than a single classical ECDSA key.

Crypto-agility: the suite header

Every enveloped public key, secret key, and signature carries a 4-byte B1 0C + suite-id header, registered in source: 0x0001 is today's ML-DSA-65 ‖ Falcon-1024 hybrid (the shipped default); 0x0002 is a defined ML-DSA-65-only suite, existing to demonstrate that Falcon is removable via the registry without a further wire-format break — it has not been removed, and the shipped default remains the hybrid.

A known implementation caveat, stated plainly

Falcon signing requires constant-time floating-point arithmetic to avoid side-channel leakage of the secret key — a materially harder engineering target than integer-only schemes. Falcon verification is deterministic integer arithmetic and consensus-safe; the caveat applies to the signing path. This is flagged in the reference crate's own documentation, not something we're surfacing to score a point — it's the kind of caveat an unaudited reference implementation should carry until reviewed.

Addresses and replay protection

An address is SHA3-256(public_key) truncated to 20 bytes, rendered as bloch1q… (mainnet) or bloch1t… (testnet) with a checksum. Every transaction's signed preimage additionally folds in a fixed domain constant plus a 4-byte chain-id (0xB10C_0001 mainnet / 0xB10C_0002 testnet), so a signature valid on one chain cannot be replayed on the other even with identical inputs.

Source: crates/bloch-crypto/src/crypto/mod.rs (hybrid sign/verify, suite registry), crates/bloch-crypto/src/crypto/mod.rs::falcon module, crates/bloch-crypto/src/address.rs, crates/bloch-crypto/src/core/mod.rs (key/signature size constants).

3 · Consensus

GhostDAG-Q — a BlockDAG, not a single chain.

Bloch-SIS-PoW's Layer 1 is a BlockDAG: blocks can — and routinely do — have more than one parent, and more than one "tip" can exist at once without either being orphaned. The ordering and security rule that turns this DAG into a single canonical history is GhostDAG-Q, an implementation modeled on the GHOSTDAG protocol used by Kaspa (the node's own source comments cite kaspanet/rusty-kaspa as the reference).

The coloring algorithm, in pseudocode

Paraphrased from src/consensus/mod.rs's block-insertion logic — not a literal copy, but the same steps in the same order:

Two safety properties this buys, both visible directly in source comments: colouring a block blue can never silently push an already-blue block's own anticone over K (the no_regression check above), and a red block is not discarded — it remains part of the DAG, is still fully validated, and can still carry transactions; it is simply excluded from the blue-work tally that drives selected-parent choice and the canonical total order.

The anticone parameter K

Two blocks are in each other's anticone if neither is an ancestor of the other in the DAG — i.e., they were mined concurrently, unaware of each other. GhostDAG-Q colors a block blue (counted toward the canonical order and blue score) if its anticone, intersected with the current blue set, has size at most K; otherwise it is colored red — still part of the DAG and still validated, but excluded from the blue-work accounting that drives selected-parent choice. The live value, confirmed both in source (GHOSTDAG_K) and by querying the running chain's getdaginfo RPC method, is K = 10.

How this differs from a single chain

• Concurrent blocks aren't wasted. On a classic single chain (Bitcoin), two blocks mined within propagation delay of each other mean one is orphaned outright — its work is discarded. On a BlockDAG, both become parents of later blocks; if their mutual anticone stays within K, both are colored blue and both contribute to blue work and (via mergeset) to the canonical order.
• The "longest chain" rule becomes "heaviest blue-work chain." Selected-parent choice is argmax(blue_work), not block height — cumulative proof-of-work along the selected chain, Kaspa-aligned, is what a reorg has to out-produce.
• Finality is still PoW depth. There is no BFT validator set and no separate finality gadget layered on top — Bloch-SIS-PoW's own documentation is explicit that finality works "à la Bitcoin/Kaspa": reorgs deeper than a checkpoint depth are rejected outright by the node (CHECKPOINT_DEPTH = 1,000 blocks), and block bodies below that horizon are eligible for pruning (PRUNING_DEPTH = 10,000 blocks).

Source: src/consensus/mod.rs (GhostDAG-Q implementation, selected-parent and blue-set logic, checkpoint/pruning constants), crates/bloch-crypto/src/core/mod.rs::GHOSTDAG_K, and a live getdaginfo query against the public RPC endpoint (see RPC reference).

4 · Coherence

Coherence — the shielded-pool layer, and its honest caveat.

"Coherence" is the protocol's optional shielded-pool subsystem: SHAKE-256-based note commitments, nullifiers, and a zero-knowledge spend proof, built as a lean, portable core (coherence-core) shared verbatim by the node, an SP1 zkVM guest prover, and the mobile wallet, so all three agree byte-for-byte on what a valid shielded spend looks like.

How it fits together

• Notes are private value-carrying objects (v, an owner tag pk_d, and two randomizers ρ/ψ). Only their SHAKE-256 commitment is published, appended to a fixed-depth-32 incremental Merkle accumulator.
• Spending a note reveals its nullifier — a SHAKE-256 hash keyed by a nullifier key and the note's position — which the node's consensus state records to block any future double-spend of the same note, without ever revealing which commitment it corresponds to.
• The node maintains a bounded window of accepted anchors (ANCHOR_HISTORY = 100 recent Merkle roots) so a spend proof stays valid for a short window after being built, and a bounded reorg-undo horizon (MAX_REORG_UNDO = 128 blocks) to safely unwind shielded state on a chain reorganization without a full resync.
• The actual zero-knowledge statement — check_spend — is proved by an SP1 (RISC-V zkVM) guest program against exactly this same core logic, so the circuit and the node's own validation can never silently diverge.

The exact invariant — check_spend, the statement the ZK circuit proves

Three things this enforces, together: every spent note was really in the commitment tree at the published anchor (membership), every note is spent under its one true nullifier so the same note can never be spent twice (uniqueness), and the arithmetic balances exactly — inputs equal outputs plus the disclosed fee, with no room to mint value inside the shielded pool. This is coherence-core's check_spend function, run identically by the node's own validation and by the SP1 zero-knowledge guest program that proves it — both call the same code, so they cannot silently diverge.

Source: crates/coherence-core/src/lib.rs (notes, commitment tree, spend statement), src/coherence/mod.rs (node-side shielded state, anchor history, reorg-undo bookkeeping), crates/coherence-prover (the SP1 guest).

5 · Emission & the coin

Supply schedule, halving, and the genesis allocation.

Block subsidy: geometric halving, then a perpetual tail

The initial reward is 8,400 BLOCH/block, halving every 1,036,800 blocks (≈1 year at a 30-second target). At the seventh halving (height 7,257,600) the geometric reward would fall to 65 BLOCH — below a fixed 100 BLOCH tail floor — so the floor activates instead and holds perpetually. Unlike Bitcoin's asymptotic-to-zero emission, Bloch-SIS-PoW's mining reward never reaches zero; it settles onto a permanent tail, a design choice shared with chains like Monero that prioritizes a standing miner incentive over a hard supply cap on the mining side. 100% of each block's subsidy currently goes to the miner — the reward-split machinery for validator and oracle pools exists in source but both shares are set to zero, since there is no BFT validator set or oracle system in this pure-PoW design.

The genesis allocation — disclosed in full, structurally passive

Consensus rules encode a one-time allocation of 3,570,000,000 BLOCH — 17% of nominal total supply. The genesis block itself mints none of it; instead the allocation is fully locked for ten years (a 10,368,000-block cliff), then released in 480 equal monthly tranches over the following forty years (41,472,000 blocks) — a fifty-year vesting horizon in total. Each tranche is exactly 7,437,500 BLOCH, dividing the allocation with no remainder.

(Renamed here for neutrality; the underlying source constants encode the same values under different identifier names.)

The allocation address carries no special consensus power: no admin key, no elevated RPC access, no voting weight, no ability to alter emission, difficulty, or any other consensus rule. GhostDAG-Q and SHAKE-256 hashcash validate blocks and order the DAG with no notion of address identity at all — the allocation is a structurally passive balance subject to the same transaction and signature rules as any other UTXO, once it vests.

Source: crates/bloch-crypto/src/core/tokenomics_v2.rs — supply constants, halving/tail-floor logic, and vesting math, each backed by an in-crate consensus test (e.g. halving_emission_closes, vesting_telescopes_to_total) that we cross-checked against the numbers quoted here.

6 · P2P networking

libp2p, empty seed list by design, and a post-quantum transport.

Bloch-SIS-PoW nodes speak libp2p over TCP (and WebSocket), gossip blocks and transactions over gossipsub, discover LAN peers via mDNS, and maintain a persisted peer list on disk (known_peers.json) that survives restarts. The wire protocol carries its own version numbers — PROTOCOL_VERSION = 1, MIN_PROTOCOL_VERSION = 1 — checked on every message, both currently confirmed live by the public node's getnetworkinfo response ("protocol": 1, "net_protocol": 1).

Message types on the wire

The gossip/sync protocol (src/network/mod.rs::NetworkMessage) defines: NewBlock (hash, blue score, height, block bytes), NewTransaction (txid, tx bytes), PeerTip / PeerExchange / PeerRequest / PeerCount (peer bookkeeping and PEX), GetHeaders / Headers (initial block download, keyed by blue score), GetBlock (fetch by hash), and a Version / VersionAck handshake pair carrying version, user agent, blue score, height, and timestamp. Gossip runs over three topics: bloch/blocks/1, bloch/txs/1, bloch/sync/1.

"Your node won't connect" — that's DEFAULT_SEEDS = [], on purpose

The shipped seed list is literally empty in source:

pub const DEFAULT_SEEDS: &[&str] = &[];

No foundation-run bootstrap servers, no privileged seed node, no DNS seed records yet (a domain constant exists in source as a placeholder but has no TXT records configured — it's an acknowledged TODO, not a working feature). This is the ownerless ethos applied literally: nobody operates a canonical bootstrap point. The direct consequence, stated just as plainly: a freshly started node sits alone until you hand it a peer address. That is not a bug report — it's how the software ships. See Run a node for the exact flag to fix it.

Peer exchange (PEX) and how a node grows its peer set

Once connected to even one peer, nodes exchange peer lists (PEX), rate-limited and validated (public-address checks, LAN-address checks, a cap on the known-peers list, pruning of invalid entries) before persisting the results. A node's externally-reachable address is only advertised via PEX after being independently confirmed by at least 3 distinct peers (EXTERNAL_ADDR_QUORUM) — a defense against a single malicious peer poisoning what address gets propagated. After first contact, your node becomes a seed for the next node that dials it.

A post-quantum transport layer, not just post-quantum consensus

Beyond the PoW and the signatures, the node's transport layer (src/transport/) implements an authenticated hybrid handshake using ML-KEM-768 (NIST FIPS 203, formerly CRYSTALS-Kyber) for the session key exchange, ChaCha20-Poly1305 for the encrypted channel, and libp2p Ed25519 identity signatures binding the transcript against man-in-the-middle substitution. The codebase's own history records the first end-to-end production run of this handshake on 2026-04-20 on the project's predecessor chain (pre-rebrand, before the code that runs today's Bloch-SIS-PoW mainnet), documented verbatim in the repository's FIRST_POST_QUANTUM_HANDSHAKE.md. The same transport code is what today's Bloch-SIS-PoW nodes run.

Source: src/network/mod.rs (libp2p wiring, PEX, address-quorum confirmation, gossipsub topics), crates/bloch-crypto/src/core/mod.rs::DEFAULT_SEEDS, src/main.rs (CLI flags and default ports), src/transport/mod.rs (ML-KEM-768 handshake).