| title | GridPool | |
|---|---|---|
| subtitle | Decentralized Bitcoin Reward Sharing with Ranked Proofs of Work | |
| author | Grid Labs | |
| date | 2026-07-20 | |
| lang | en-US | |
| toc | true | |
| numbersections | true | |
| geometry |
|
|
| fontsize | 10pt |
Draft whitepaper for GridPool protocol V2.1 with V2.2 Monotonic Snapshot Reconciliation.
This document explains the mechanism, its statistical basis, and its intended security properties. It is not yet a normative interoperability specification. Where this paper says a node "must" do something, it describes the proposed consensus rule; independent implementations should use published test vectors and a future normative specification rather than this prose alone.
The reference implementation identifies V2.1 as consensus protocol version 21.
V2.2 (consensus version 22) adds Monotonic Snapshot Reconciliation and is
scheduled for coordinated mainnet-beta activation at Bitcoin height 959500
(approximately 24 July 2026). V2.2-capable software runs V2.1 rules until that
height.
Bitcoin miners use pools to reduce payout variance, but conventional pools usually introduce a trusted accounting service, a custodial payout path, or a second consensus system such as a sharechain. GridPool explores a different design point: miners independently construct Bitcoin blocks, exchange a small set of verifiable high-difficulty proof-of-work claims, and commit a common payout suffix directly in the coinbase transaction.
The key statistical inversion is simple. A conventional pool normally assigns a share target in advance and credits work by counting accepted shares at that assigned difficulty. GridPool instead uses each hash's achieved difficulty. Because achieved difficulties have a known heavy-tailed distribution, a bounded set of the best proofs contains useful evidence about the work that produced it. Ranking those proofs allows GridPool to estimate accumulated work, choose a sparse set of payout claims, and bound protocol state without maintaining a complete share ledger.
V2.1 separates three concepts that earlier versions conflated:
- a bounded Unpaid Work Set of valid proof IDs;
- an Active Snapshot, which is the fixed post-slot-0 payout suffix miners commit to at a Bitcoin block boundary; and
- Paid Lineage, the exact proof IDs consumed by an actual GridPool block.
At every Bitcoin block, a node snapshots the highest-ranked unpaid proofs but does not clear them. When GridPool finds a Bitcoin block, that block pays the previous active snapshot; only the proof IDs actually paid are removed. Nodes merge compatible current-parent proofs rather than choosing one whole Work Set over another. Proofs on the previous Bitcoin parent that were unknown when a node crossed its local block boundary cannot later rewrite that boundary.
V2.2 adds Monotonic Snapshot Reconciliation (MSR). Honest sibling snapshots that share the same predecessor, Bitcoin boundary, and payout variant form a family. Once a node fully validates multiple family members, it computes a deterministic union of their proven unpaid work, ranks by achieved difficulty, and derives a reconciled snapshot. Omission cannot remove known work; addition requires valid proof of work. Subsequent branch hashrate does not elect a winner. MSR is designed to heal last-millisecond boundary races without reintroducing a heaviest-branch rule.
This design removes a trusted pool wallet, a central accounting database, and a long-lived sharechain. It does not eliminate network partitions, denial of service, censorship by a sufficiently isolated majority, or all timing risk. The project remains beta software. V2.2 ships with hardened direct-ingress stale-parent handling and payment removal keyed to the winning block's proven snapshot; two-block reorg vectors and packaging remain active work.
Solo mining has fair expected value before costs, but extreme variance. A small miner may contribute useful work for years without finding a Bitcoin block. Pools aggregate block-finding probability and divide rewards according to an accounting rule, turning rare large payouts into smaller, more frequent ones.
The usual implementation gives an operator at least one privileged role:
- receive shares and maintain the authoritative work ledger;
- construct or approve block templates;
- receive the coinbase and pay miners later; or
- choose which miners and transactions are permitted.
Those roles create operational efficiency, but also create failure, custody, regulatory, and censorship surfaces.
GridPool is designed around the following goals:
- Sovereign template construction. A miner or its local gateway obtains transactions from its own Bitcoin node and builds its own candidate block.
- Direct coinbase settlement. Shared rewards go directly to miner payout scripts in the block that earns them; there is no pool wallet or later payout promise.
- Proof-based accounting. A node can verify every retained claim without trusting the sender's identity, username, timestamp, or reported hashrate.
- Bounded state. Normal operation should not require an ever-growing share history or a second blockchain.
- Open participation. Identity creation must not create reward claims.
- Loose coupling to mining transports. DATUM, Stratum V2, direct devices, or future gateways can act as adapters without redefining consensus.
GridPool does not promise instant deterministic finality among partitioned nodes. Bitcoin's own chain selects the block that was actually paid. GridPool's job is to make honest convergence practical and manipulation costly without creating a second chain.
In a conventional variable-difficulty pool, a worker receives an assigned
difficulty d. Every hash meeting that target is normally credited as d
units of work. A hash that happens to be one thousand times better than d
usually receives the same ledger credit as one that barely met d, unless the
hash also solves a Bitcoin block.
GridPool does not use achieved difficulty as a proportional payout multiplier. It uses achieved difficulty to rank claims. A retained proof earns one fixed shared slot if it is selected into the active payout snapshot. A better proof is more likely to survive competition for that bounded list.
Let H be a uniformly distributed proof-of-work hash interpreted as a positive
integer, and let T_1 be Bitcoin's difficulty-1 target. Ignoring negligible
discrete effects, achieved difficulty is
Condition on hashes that meet an admission difficulty d_min. For x >= d_min,
Therefore
is approximately uniform on (0,1). The best achieved difficulties correspond
to the smallest uniform order statistics.
The practical intuition comes first: instead of counting every qualifying hash,
retain the best m and inspect the weakest retained one. Producing m unusually
strong outcomes requires proportionally more trials, so the difficulty at rank
m estimates the total hashing that produced the list. Increasing m makes
that estimate more precise.
Suppose S qualifying hashes were generated and the protocol retains the best
m. Let V_(m) be the m-th smallest normalized value, equivalently let
D_(m) be the m-th highest achieved difficulty. Then
The common large-sample estimate is
For fixed S, an exactly unbiased form is
Its variance is
so for S much larger than m, relative standard error approaches
This is approximately 3.34% for m=897 and 5.79% for m=300.
Under Bitcoin's conventional difficulty units, the corresponding accumulated hash estimate is approximately
This estimate applies to the work represented by a comparable proof window. A GridPool Work Set is an unpaid lineage window, not automatically a fixed time window, so converting its cutoff into instantaneous hashrate also requires a defensible elapsed-time anchor. The cutoff is useful evidence; it is not a magic clock.
The conditional achieved-difficulty distribution has a Pareto tail with shape parameter one. In the idealized unbounded model, its mean is not finite. A raw sum is therefore dominated by occasional extreme outliers and is a noisy way to compare similarly sized proof sets.
The fixed-rank cutoff is much more stable. For full equal-depth reserves, the
difficulty of the 897th proof is the statistically natural comparison of the
amount of work represented by each reserve. This observation is useful for
diagnostics and research. V2.1 does not use it as permission to replace an
established local snapshot with a late stale-parent branch.
Proof values are independent of payout labels. If miner i supplies fraction
alpha_i of the eligible hashes in a comparable window, each retained rank is
attributed to that miner with probability alpha_i. For m shared ranks,
and, under the simple independent-label approximation,
Splitting one miner across many payout addresses does not create more work and does not increase expected rank ownership. It only divides the same stochastic claims among more labels.
A relayable GridPool proof contains enough information for another node to verify the claimed work and payout commitment:
- the 80-byte Bitcoin block header;
- the complete coinbase transaction;
- the coinbase Merkle branch;
- the Bitcoin parent block hash;
- the payout snapshot identifier used by the template;
- slot-0 attribution derived from the coinbase itself; and
- non-consensus metadata used for diagnostics.
A verifier checks at least:
- header proof of work and achieved difficulty;
- the header's parent block context;
- reconstruction of the header Merkle root from the coinbase and branch;
- the required post-slot-0 payout suffix for the referenced snapshot;
- slot-0 script validity and attribution;
- proof ID consistency and duplicate status; and
- admission against the current bounded reserve floor.
The sender's username, address metadata, and claimed difficulty are not the source of truth. Attribution comes from the coinbase output committed by the header.
The proof does not include the full transaction list. It therefore demonstrates the coinbase and header commitment without directly revealing every transaction chosen by the miner. This is transaction-selection privacy, not anonymity: peer addresses, timing, coinbase scripts, and later blocks can still reveal information.
The Unpaid Work Set is a set of valid, distinct, unpaid proof IDs sorted by:
- achieved difficulty, descending; and
- deterministic proof ID tie-break, ascending.
The default reserve limit is 897, three times the nominal 299 post-slot-0
positions. When full, a new proof must exceed the current lowest retained
difficulty to affect canonical state. Lower-difficulty telemetry can still be
used locally or as rate-limited network pulse data without mutating consensus.
The fixed size provides three useful properties:
- bounded memory and state-bundle size;
- an endogenous admission floor as hashrate grows; and
- a statistically precise order-statistic view of accumulated unpaid work.
The Active Snapshot is the fixed post-slot-0 payout suffix used by miners at the current Bitcoin tip. It is not the entire coinbase and does not contain the finder's slot 0.
The default design has 300 conceptual payout slots. Let
With the public reference network's canonical support output (ADR-0007, accepted 2026-07-19), the suffix contains:
- one fixed Grid Labs support output of value
q; and - up to
298shared proof outputs of valueq, ordered by proof rank.
Support-off (up to 299 shared proof outputs and no support slot) is not an
interoperable dialect of the public reference network. It may exist only as an
experimental build, private deployment, or future coordinated migration. The
support destination is protocol-canonical; implementations must not substitute
an arbitrary operator-controlled fee address and still claim reference-network
compatibility. Mixed fee-on/fee-off peering is explicitly deferred so paid
lineage remains single-variant.
Slot 0 receives the remainder of total coinbase value after the required suffix:
- one conceptual base slot;
- all transaction fees;
- integer-division remainder; and
- any value not consumed by unfilled shared positions during bootstrap.
Multiple positions paying the same script may be condensed into one transaction output if the consensus serialization rules preserve the required value.
Every unpaid proof records the snapshot against which its coinbase was built. Nodes retain the payout outputs and proof lineage needed to validate that snapshot after newer Bitcoin blocks create newer active snapshots.
This is what permits proofs built against different, but previously valid, snapshot suffixes to coexist in a later Work Set. Context retention is bounded by references from active or unpaid state, not by an unbounded historical chain.
Paid Lineage is the exact set of proof IDs represented by the snapshot that an accepted GridPool block actually paid. Those IDs are consumed once. Other unpaid proofs remain in the reserve even if they were below the active payout cutoff or arrived after that snapshot was created.
Paid-once behavior is stronger than clearing an entire list: it preserves work through ordinary Bitcoin blocks and allows a lucky sequence of GridPool blocks to walk deeper into the reserve without paying the same proof twice.
GridPool has two related but different clocks:
- snapshot cadence: every Bitcoin block; and
- payment epoch: from one GridPool-found Bitcoin block to the next.
Calling every snapshot a new "round" obscures this distinction. This paper uses "snapshot" for ordinary Bitcoin block boundaries and "payment epoch" for the period over which unpaid proofs compete until GridPool earns a block.
When a node locally observes a valid new Bitcoin tip that was not produced by GridPool:
- it freezes a new active payout suffix from its current highest-ranked unpaid proofs;
- it records the Bitcoin block hash/height as that snapshot's boundary;
- it retains the entire Unpaid Work Set; and
- it begins accepting proofs whose headers build on the new parent.
No proof has been paid, so no paid lineage is removed.
When a miner finds a Bitcoin block using a GridPool template:
- the full block is submitted through the miner's local Bitcoin infrastructure;
- the GridPool proof is validated and inserted into the Work Set;
- the block's coinbase identifies the active snapshot it actually paid;
- exactly that snapshot's shared proof IDs are removed from unpaid state; and
- the next active snapshot is built from the remaining reserve.
Inserting the block proof before removal matters. The finder normally remains eligible for a future shared slot unless its proof ID was already part of the snapshot just paid. Bitcoin consensus already awards it slot 0 and fees in the block it found.
A bare chain-tip notification is sufficient to create an ordinary snapshot. It is not sufficient to consume paid lineage. Removal requires a validated GridPool block proof and its coinbase commitment.
on ordinary_bitcoin_tip(block):
active_snapshot = snapshot(top(unpaid_work_set))
current_parent = block.hash
on valid_share(proof):
verify_pow_header_coinbase_merkle_parent_snapshot(proof)
if proof.parent == current_parent:
unpaid_work_set = top_897(union(unpaid_work_set, proof))
else if proof.id is already locally known:
preserve_existing_lineage(proof)
else:
reject_or_quarantine_as_late_previous_parent(proof)
on valid_gridpool_block(block_proof):
unpaid_work_set = top_897(union(unpaid_work_set, block_proof))
paid = snapshot_identified_by(block_proof.coinbase)
unpaid_work_set = unpaid_work_set - paid.proof_ids
active_snapshot = snapshot(top(unpaid_work_set))
current_parent = block_proof.block_hash
If peers share the same active payout state but have different subsets of valid proofs on the current Bitcoin parent, the correct operation is set union followed by deterministic sorting, deduplication, and trimming to the reserve limit. It is not an all-or-nothing choice between two candidate reserves.
This removes the usual reason to ask whether sum difficulty, median difficulty,
or the 897th proof should select a normal same-parent branch. If both proofs
are valid and compatible, both are evidence and both should be considered.
Peers cannot prove when they first learned a Bitcoin block, and peer timestamps can be forged. V2.1 therefore anchors admissibility to each node's own ordering:
- a proof accepted before local observation of the next Bitcoin block may enter that node's snapshot and reserve;
- an unknown proof on the old parent arriving after that boundary cannot rewrite the active snapshot or enter canonical future reserve; and
- current-parent proofs remain mergeable only when their retained payout contexts commit to a compatible active payout state.
As a consensus rule, this closes the simplest delayed-snapshot attack: an attacker cannot backdate stale work and force an established node to replace its local boundary merely by presenting a statistically "stronger" stale list. The reference implementation does not yet enforce this rule consistently on direct share ingress; see the implementation-status section.
Suppose proof x reaches node A immediately before block B(h+1), but reaches
node B immediately after B has observed that block. A may include x in
S_A; B freezes S_B without it. B cannot trust A's assertion that x was
timely, so B does not retroactively add it.
Proofs subsequently mined on parent B(h+1) commit to the payout context used
to build them. Proofs built against S_A remain valid on A's branch, and
proofs built against S_B remain valid on B's branch. They cannot be
cross-credited without weakening payout validation. Merge-forward still
resolves ordinary candidate Work Set differences among nodes that share one
active payout state; it is not automatic reconciliation of S_A != S_B.
It is important not to overstate convergence. If x is strong enough to remain
cutoff-relevant, A and B can continue to construct different active snapshots.
The difference may become irrelevant when the distinguishing proof is
displaced from the payout cutoff. An independently validated GridPool payment
can also identify paid lineage, but complete automatic recovery for every
genuine active-snapshot split is not yet specified. Correct cross-snapshot
payment handling and an explicit recovery policy are therefore
consensus-critical.
A sharechain must repeatedly choose a single next tip at a short interval. Two otherwise valid shares can conflict because only one extends the selected tip. That creates continuous orphan pressure and makes latency an ongoing accounting factor.
GridPool normally unions independent proofs and sorts them by achieved difficulty. Latency is concentrated near Bitcoin block boundaries rather than every share interval. A late proof can miss a snapshot and, under V2.1, may be excluded by nodes that first see it after the boundary; it does not orphan a chain of descendants. This should reduce latency-driven centralization pressure, but it does not make latency irrelevant.
Each shared position has fixed value q. A miner's expected fraction of shared
positions follows its fraction of eligible work. The block finder separately
receives slot 0 and all transaction fees. Thus the design combines:
- shared variance reduction for retained proof owners; and
- a direct finder premium that discourages withholding.
The currently modeled 300-slot design materially reduces actual BTC payout
variance in mature-team scenarios while preserving expected value. The exact
variance reduction is scenario-dependent, not universally 300x; correlated
slot ownership, finite windows, team block cadence, reserve churn, and the
finder component all matter.
Once the team is large enough to keep the ranked list competitively occupied, a fixed miner's expected payout-event cadence and asymptotic variance become approximately independent of total GridPool team hashrate. Increasing the team raises team block frequency while reducing that miner's expected positions per team block by the inverse factor. Expected BTC remains determined by the miner's fraction of Bitcoin network hashrate. This cancellation is a mature- team result, not a claim about sparse bootstrap conditions.
Let D_s be a proof's achieved difficulty and D_net Bitcoin network
difficulty. During the race until the team finds its next Bitcoin block, better
proofs and Bitcoin blocks can be modeled as competing Poisson processes. The
probability that no more than m-1 better proofs arrive before the block is
This explains why an easy proof earned early by a tiny team is not automatically a durable reward claim. It must remain above the final payout cutoff. A very strong proof can persist; ordinary proofs are displaced as more work arrives.
Leaving GridPool after earning a strong proof does not manufacture value. The proof remains a claim backed by work already performed, and the miner gives up:
- opportunities to earn additional shared proofs;
- the chance to find slot 0 and fees; and
- the chance to accelerate payment of its own existing claims.
Simulation has found no theft mechanism against miners who remain. Under an idealized zero-fee outside option, a sufficiently large miner can retain already earned GridPool claims while moving new work elsewhere, creating a small option-like strategy. Whether that is economically attractive depends on outside fees, payout timing, and variance tolerance. The defensible claim is narrower than "pool hopping is impossible": hopping cannot forge proofs or debit another miner's paid lineage.
A miner withholding a valid GridPool block gives up slot 0 and transaction fees
and delays payment of its own shared claims. Straightforward profit-maximizing
withholding is therefore costly in the current models. An attacker with external
utility for disruption can still burn money; GridPool does not claim to make
griefing impossible. The damage is bounded by discoveries the attacker actually
controls and suppresses: to first order, a miner with team fraction a that
withholds fraction w removes about a w of team block opportunities, not
blocks found by honest miners.
Creating nodes, workers, or payout addresses creates no proof of work. Admission and ranking depend on validated hashes, so identity multiplication alone cannot create expected payout share.
Sybil nodes can still consume connections, distort unprotected topology discovery, or assist an eclipse attack. Networking requires independent resource limits and diverse peer selection.
A fabricated claim must satisfy header proof of work, Merkle commitment, coinbase payout structure, parent context, and slot-0 attribution. Changing the payout address changes the coinbase, Merkle root, and header, invalidating the claimed work.
An attacker may intentionally continue mining the old Bitcoin parent after a new block appears, then claim it learned the block later. No decentralized node can verify the attacker's wall clock. V2.1 avoids that question: established nodes use their own local receive order and refuse to import unknown old-parent proofs across the boundary.
This sacrifices universal credit for a proof found in the last milliseconds of a Bitcoin height. The alternative would give a majority miner a deterministic path to manufacture a stronger retroactive branch by burning stale work.
GridPool has no sharechain to reorganize, so a "51% attack" is not a sharechain reorg. A majority miner can nevertheless:
- refuse to relay other miners' proofs;
- isolate or eclipse peers;
- mine a private payout suffix;
- dominate future rank positions with real work; or
- degrade the team's block-finding probability by withholding blocks.
V2.1 prevents a late stale list from automatically replacing an established node's snapshot. It does not force partitioned miners to agree or stop a majority from forming a separate team. Censorship resistance ultimately depends on miners retaining sovereign template construction and enough independent connectivity to exchange proofs outside a censor's view.
No generic profitable "51% hash wins the payout state" attack is currently known under the intended V2.1 rules. Candidate-state anchoring rejects the tested cross-active-state selective-inclusion transition even when the modeled attacker exceeds 50%. That is evidence against a known mechanism, not a proof against every majority censorship, partition, eclipse, or externally funded griefing strategy.
A GridPool share proof reveals the coinbase and its Merkle branch, but not the full transaction list. A relay node therefore cannot generally infer which ordinary transactions the miner selected from the GridPool message alone.
If an adversary already knows a target transaction, other information channels may reveal inclusion, and a found Bitcoin block is public. GridPool should be described as reducing the pool operator's transaction-veto surface, not as a cryptographic guarantee that transaction selection is unobservable.
Proof-of-work admission makes state mutation expensive, but it is not a complete DoS defense. Connections, malformed payloads, signatures, snapshot-context validation, and state-bundle transfer all consume resources before or outside the ranked reserve. Implementations still need rate limits, payload bounds, deduplication, parser hardening, and peer reputation that does not become a consensus identity system.
The canonical reference path uses authenticated peer sessions with WebSocket and HTTP state-bundle fallback. Compact UDP relay is an optional fast path for proofs that fit within a conservative datagram budget; full validation still occurs at each receiver, and reliable transports remain the recovery path.
Recent beta telemetry also uses rate-limited pulse proofs: valid proof-of-work below the Work Set mutation floor that measures reachability and transport arrival without changing payout state. Pulse traffic is diagnostics, not consensus weight.
The networking architecture separates:
- discovery: learning candidate peers;
- reachability: determining whether inbound TCP or UDP is possible;
- transport: UDP, WebSocket, or HTTP;
- proof validation: independent of transport; and
- state recovery: bounded bundle exchange after missed relay.
Public seed nodes are useful for bootstrap but should not become mandatory permanent relays. The roadmap includes automatic PCP/NAT-PMP/UPnP mapping where safe, explicit public-node configuration, and later UDP hole punching or relay fallback where measurements justify the complexity.
Compact UDP does not remove the large-coinbase problem by itself. A full 300-address coinbase plus proof can exceed a single conservative datagram. The implementation must fall back to reliable full-proof relay unless a compact reconstruction scheme can prove that peers share the required snapshot context.
GridPool consensus begins at a valid Bitcoin header, coinbase, Merkle branch, and payout context. How a miner obtains that template is an adapter concern.
Current and experimental paths include:
- DATUM gateways using a miner's own Bitcoin node;
- a Stratum V2 integration path;
- Hydrapool or other Stratum V1 gateways; and
- direct devices that fetch templates from a local Bitcoin node and submit GridPool proofs over HTTP.
Adapters must not silently truncate the required payout suffix. Some Stratum V1 firmware cannot accept large coinbase transactions; those devices produce consensus-invalid GridPool proofs if a gateway shortens the payout list. Stratum V2 header-only mining can remove the ASIC's coinbase-size constraint, but the job declarator or template provider must still construct the exact GridPool coinbase and preserve per-miner slot-0 attribution.
When a full Bitcoin solution is found, the local template-building stack must submit the complete block to a Bitcoin node. GridPool proof relay is not a substitute for Bitcoin block submission.
The consensus state is deliberately bounded by proof count, but byte size still depends on coinbase and snapshot-context size.
At default parameters a node retains at most:
897canonical unpaid proofs;- one active payout suffix;
- recent paid lineage; and
- the distinct snapshot contexts still referenced by unpaid proofs.
Proof verification cost includes one header hash, coinbase parsing, Merkle-branch
reconstruction, payout validation, and context lookup. Sorting 897 items is
small on general-purpose hardware; repeated validation of large imported bundles
and many distinct retained contexts is the more important resource concern.
The protocol must bound:
- proof count per bundle;
- coinbase and Merkle-path bytes;
- number and size of retained contexts;
- peer/session fanout;
- pulse rate; and
- recovery frequency.
Consumer-node viability should be established by soak tests on Raspberry Pi, Umbrel, and Start9-class hardware rather than inferred from asymptotic counts.
As of 2026-07-14, the reference source contains 102 automated test methods. The
suite covers ordinary snapshot preservation, current-parent merge, rejection of
unknown stale-parent candidate-bundle proofs, reserve depth,
retained-context validation, fee-on snapshot construction, and paid-proof
removal in the ordinary local snapshot path.
That is meaningful engineering evidence, not a proof of consensus completeness. The following launch-hardening work was identified while preparing this paper:
- Direct-ingress boundary enforcement. Direct share validation uses an accepted-parent set that deliberately retains the immediate previous parent and parents represented by existing reserve proofs. A previously unknown proof arriving after the local boundary can therefore appear valid and enter the Work Set even though candidate-bundle merge would exclude it. The robust candidate-import safety gate is now being applied consistently to canonical admission: old parents remain available to revalidate known lineage, while newly received old-parent proofs do not rewrite live state. Direct HTTP, peer, UDP, WebSocket, and DATUM boundary-race tests should cover the rule.
- Cross-snapshot GridPool payment. If a valid block pays a retained divergent snapshot rather than the receiver's current active snapshot, paid lineage must come from the block's actual snapshot. Explicit unit tests are being added to verify removal against the block-proven lineage rather than the receiver's incidental local view.
- Fee-on/fee-off lineage. Snapshot contexts retain the fee-free payout variant, but do not clearly retain a separate fee-free proof-ID lineage. A fee-free block validated by a fee-enabled node could otherwise leave one actually paid proof eligible. Cross-configuration tests are required.
- Recovery fetch gating. Candidate proof sets are mergeable, but peer sync can still decide whether to fetch a candidate using aggregate difficulty. After relay loss, a lower-total peer may hold a unique valid current-parent proof that is never requested. Set-difference-aware recovery is preferable.
- Boundary disagreement duration. The current latency simulation measures immediate snapshot disagreement and missed slot/node pairs. It does not model how long a strong boundary-only proof keeps snapshots divergent, nor complete cross-snapshot payment reconciliation.
- Conformance vectors. The test suite is tied to one implementation. A separate normative specification and implementation-independent vectors are needed before multiple codebases can safely interoperate.
These are launch-hardening tasks, not reasons to discard the ranked-proof model. They are reasons to keep public claims narrower than the design ambition.
The companion modeling repository contains reproducible studies of payout variance, pool hopping, block withholding, consensus scoring, and boundary latency. The strongest current findings are:
- broad payout snapshots reduce actual BTC payout variance without changing expected value under the modeled assumptions;
- the fixed-rank cutoff estimates represented work more reliably than raw sums of heavy-tailed achieved difficulties;
- straightforward block withholding is costly to a profit-seeking finder;
- hopping cannot forge work or erase another miner's paid lineage; and
- lower relay latency sharply reduces immediate boundary disagreement in the stylized network model.
Preliminary four-node public-network telemetry shows agreement on current and candidate state IDs across Main, Dallas, Detroit, and Evomining. Compact UDP payloads were about one fifth of the WebSocket representation and supplied most first proof copies in the dominant categories. This is a field sanity check, not a global latency result. Geography, topology, node load, NAT behavior, sample selection, and the small number of operators limit inference.
The most important unresolved questions are:
- How long do cutoff-relevant boundary disagreements persist in realistic Work Set and payment dynamics after V2.2 MSR activation?
- How complete is recovery under one- and two-block Bitcoin reorganizations?
- What peer topology gives home nodes robust bidirectional participation without dependence on a few public relays?
- Which Stratum V1 firmware safely accepts a full 300-address coinbase?
- How does a dense network behave under eclipse attempts, selective relay, malformed bundles, and pulse spam?
- What is the minimum normative state and test-vector set needed for an independent implementation?
Resolved for the public reference network (2026-07-19): optional dual support-fee dialects are deferred. Reference peers use support-on only so snapshot identity and paid lineage stay single-variant.
GridPool's central idea is not a new share counter. It is the use of achieved proof-of-work difficulty as a sparse, verifiable ranking signal. That signal makes a bounded unpaid reserve possible. A Bitcoin-block snapshot turns the reserve into a direct coinbase payout suffix. Paid lineage consumes only the claims actually settled. Together, those pieces offer a path to variance reduction without a pool wallet, central accounting ledger, or sharechain.
V2.1 improves the design by replacing whole-list branch selection with merge-forward proof sets and local non-retroactive Bitcoin-block boundaries. V2.2 adds monotonic reconciliation so honest sibling snapshots that raced a boundary can converge by union of proven work rather than by subsequent hashrate or operator intervention. Fast relay still reduces how often races occur; MSR bounds how they heal.
The result is promising, testable, and still unfinished. The protocol should be judged by reproducible models, interoperable vectors, adversarial tests, and long-running public telemetry rather than by claims of solved consensus.
- Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008.
- Meni Rosenfeld, Analysis of Bitcoin Pooled Mining Reward Systems, 2011.
- Bitcoin Improvement Proposal 22, getblocktemplate - Fundamentals.
- Bitcoin Core, getblocktemplate RPC documentation.
- Stratum V2, Template Distribution Protocol specification.
- Loi Luu et al., SmartPool: Practical Decentralized Pooled Mining, 2017.
- GridPool simulation source and generated reports,
gridpool-simulationsrepository. - GridPool reference implementation and tests,
boot-protocolrepository.