528 lines
72 KiB
Markdown
528 lines
72 KiB
Markdown
# The last mission, lane 4: what can be invented, judged hard
|
|
|
|
7 October 2026, morning UK. Lane 4 of the final research programme ("the last mission"), worktree `igneum-wt-mission`. The question: given everything Igneum already has (the horizon one page, the frontier lane's sixteen ideas, the new-PoW lane's three schemes, class v5, finality in the proof, work-stake, the tail, vote-or-burn, the ladder, the pool design, the light client, the phone app), what is the NEXT genuinely new thing a GPU chain could do that none has. Every candidate here was checked against prior art by name and year, run through its own game theory with a model this lane ran (`invent_model.py`, section 0), reviewed in the Monero or Kaspa developer's voice, priced in agent hours with a first gate, and given its per-tier consequence and four persona verdicts. Nothing here touches the devnet. No em dashes. Figures from memory say approximate; figures from a source name it.
|
|
|
|
the project lead's rulings are applied as a filter before any idea is scored: miners are the security always; no stake and no coin bond; no holder penalised; no device bounty; no fixed-height activations; no calendar dates; no reliance on another chain; no dev fund; no privacy; nothing that becomes a token sale; the lottery and the proving stay separate; emission carries security with no end date. An idea that needs one of these is marked dead in one line.
|
|
|
|
## 0. Progress, method and the four voices
|
|
|
|
| Time (UK) | State |
|
|
|---|---|
|
|
| 08:05 | Lane started; read CLAUDE.md, the horizon one page (sections 1 to 3), frontier.md (sections 0 and 3, all sixteen), new-pow.md (3, 4, 6, 7), class-v5-stored-state.md, finality-in-proof.md, work-stake.md, tail-emission.md (one page), vote-or-burn.md, latency-ladder.md, 51-percent.md, pool.md, spec 09, spec 10, phone-app.md, the four persona files, bench-log (rental cost, warp verify, aggregation, 5090 rows) |
|
|
| 08:35 | Prior art checked by WebFetch on primary pages (the session's WebSearch budget was already spent; every page that answered is in the sources list; four pages 404'd and those items are labelled approximate) |
|
|
| 08:51 | `invent_model.py` written and run in the lane's scratch (`mission-invent/out.md`); every table below marked "model" is printed by it |
|
|
| 08:59 | This file written (528 lines, 0 em dashes, not staged); final message to the coordinator |
|
|
|
|
**Method.** Three passes per candidate. (1) Prior art: the paper, project or repository that did it, with the year, and the one sentence of what differs. (2) Game theory: who gains from cheating, the attack, its cost, the bound; a short numeric model actually run. (3) The hostile review in the Monero or Kaspa developer's voice, then the prototype cost in agent hours, the first measurable gate, the per-tier consequence (home miner 8 / 12 / 16 / 24 to 32 GB, rig, pool user; Windows, Linux, macOS; NVIDIA, AMD, Apple) and four persona verdicts: do now, prototype, watch, never.
|
|
|
|
**The four voices.** The cryptographer, the consensus engineer and the miner (the miner-community lead) are the persona files in `.claude/agents/`. The fourth, the economist, is defined here from the economy lane's method (`docs/analysis/horizon/economy-and-utility.md`, `tail-emission.md`): every number is priced in rented hash at the measured USD 0.0117 per MH/s-hour (bench-log, "Rental cost of hash", 6 October 2026); an IGN price is an input never a prediction, shown at USD 0.005, 0.02 and 0.10; fees are never assumed to be the security budget; a mechanism that moves income is judged by who pays, who is paid, and whether the payer would rather leave; the per-tier consequence is stated before anyone asks.
|
|
|
|
**Price basis used throughout.** Subsidy 100 IGN a block at one block a second (the tail-emission recommendation; today's code pays 31.688). Rented hash USD 11.7 per GH/s-hour. CPU verify of one 32-lane unit: 0.441 ms class v3 steady (bench-log line 170), 5.06 ms class v4 cold on the box's core (horizon L2), 1.35 ms per pool share check in isolation (pool.md section 5); the gate is 10 ms. Header 400 B working figure (spec 10.9). Snapshot 114.8 MB (horizon rank 22). Groth16 proof 260 B (SP1 docs), public values with the finality extension 494 B (finality-in-proof section 1).
|
|
|
|
**What the measurement budget did not allow.** Nothing in this lane needed the box or a GPU pod to reach a verdict; where a first gate needs one, the gate names the command and the expected number and the final message lists it for the coordinator.
|
|
|
|
---
|
|
|
|
## 1. Hashing useful to the chain itself, without reopening the useful-work trap
|
|
|
|
The trap, restated from new-pow section 3.1 and frontier 3.10: a lottery needs a sampleable puzzle with a cheap verifier; any coupling of the puzzle to a scarce skill hands the lottery to the best at that skill (Aleo). The four variants below avoid the trap by keeping the hash kernel byte for byte as shipped and changing only what a miner must HOLD or must have DONE to build the dataset or to be paid. That is class v5's shape (new-pow scheme C: hash rate 63.083 against 63.088 MH/s on the 4090, build +1.4 ms, verifier +0.11 to 0.21 ms per unit), so the question for each is only: what does it add to class v5 that is measurable, and does the addition survive its own game.
|
|
|
|
### 1.1 What class v5 already delivers, so nothing below re-invents it
|
|
|
|
| Property | Delivered by class v5 | Where |
|
|
|---|---|---|
|
|
| Every mining operation holds the day's execution state | yes, by construction: `leaf(t) = D[t mod n]` keys every item; a stateless hasher is wrong on every item (the known-failed case) | class-v5 section 3, 4 |
|
|
| Every block names 128 random state leaves per lane any full node can open against `R_d` | yes; the opening RPC is new-pow rank 6 (4 hours, not built) | new-pow 3.3, 7 |
|
|
| The miner must know the chain to within the epoch lead | yes, already since class v3: the program is the 10-minute VDF of a certified checkpoint 20 minutes before the epoch (spec 04 4.3); a miner without the last hour of chain has the wrong program and every hash is wrong | spec 04 |
|
|
| The f = 0 recompute chip must hold the state | yes | new-pow 6 |
|
|
| The pool caveat | stated: a pool ships `D` once a day (6 KB today, 1 to 2 GiB on a used chain) | class-v5 section 3 |
|
|
|
|
### 1.2 (a) Proof of following: the day's leaves include the last N blocks
|
|
|
|
**The idea.** Widen class v5 so that the dataset derives from the state AND from the chain's recent blocks: the day's leaf array gains the hashes or receipts of the last N chain blocks before the cut, so a miner proves it relayed or held recent blocks, not only the state.
|
|
|
|
**Prior art.** Verthash (Vertcoin, January 2021, approximate: the vertcoin.org page 404'd this morning): a 1.2 GB dataset built from the chain's own block headers, random reads per hash. Ethash (2015): dataset from the epoch seed. Class v5 (this project, 7 October 2026): dataset from the execution state. Permacoin (Miller, Juels, Shi, Parno, Katz, IEEE S&P 2014): proof of retrievability of a dealer's file. The combination "state plus recent headers" is new in form; Verthash is the nearest in substance.
|
|
|
|
**Mechanism.**
|
|
|
|
| Item | Rule |
|
|
|---|---|
|
|
| Extra leaves | after the state records, one record per chain block in `(daa(C_d) - N, daa(C_d)]`: `0x04 ‖ block_hash ‖ state_root ‖ receipts_root` |
|
|
| Keyed by | `R_d` as every other leaf; the day's cut `C_d` is one hour before the day (class-v5 section 2) |
|
|
| What it forces | a builder must hold the last N headers and receipt roots before the cut |
|
|
| What class v5 forces already | the whole state after `C_d`, which commits to every one of those blocks through `R_d` |
|
|
|
|
**Game theory.** Nobody gains from cheating because there is nothing to cheat: the state root already commits to the chain. The only question is what a miner must HOLD. Under class v5 a miner holds `D` (the state sample); under 1.2 it also holds N header records it can fetch from any peer in one round trip. Model (section A of `invent_model.py`, the outsourcing row): a key with nothing answers a fetch in about 108 ms over a 100 ms link. The addition forces no holding that a pool's daily delivery does not already satisfy, and the "following" it proves is the following the epoch seed proves every hour at zero cost.
|
|
|
|
**What is measurable.** Nothing new per block. The receipts are a function of the state transition every executing node already computed; the day's cut already requires the chain to within an hour; the epoch seed requires it to within 80 minutes. The one measurable thing would be a per-block dataset change, and a per-block build is 32 ms on a 4090 (class-v5 section 2) against a 1,000 ms block: a 3.2 percent hash loss on every card every second for a property the program swap gives every hour for free.
|
|
|
|
**Hostile review (Kaspa voice).** "You have a dataset keyed by a state root that is itself a function of every block in the chain's past. Adding the last N block hashes as leaves adds information the root already carries. If you want 'following', the program swap is your following: a miner that is an hour behind has the wrong kernel. Do not add bytes to a build that already proves the thing."
|
|
|
|
**Cost and gate.** 0 hours: not built. If someone insists: the gate is the fast-time harness showing a stateful miner with stale headers is refused, which the state root already does.
|
|
|
|
**Per tier.** No change for any card, rig or pool user; the verifier's RAM unchanged.
|
|
|
|
**Verdicts.** Cryptographer: never (the root commits to the chain; redundant). Consensus engineer: never (bytes for nothing). The miner: never (nothing to see). Economist: never (no income moves). Verdict: never, with the sentence "proof of following is the epoch seed plus class v5" written into class-v5's litepaper paragraph.
|
|
|
|
### 1.3 (b) Proof of serving: a reward component for serving headers, snapshots and proofs
|
|
|
|
**The idea.** A slice of the producer's 80 points is paid only to keys that served data to peers in the window, verified by challenge-response sampled into blocks.
|
|
|
|
**Prior art.** Filecoin WindowPoSt (2020; spec.filecoin.io: 48 deadlines of 30 minutes a day, randomness from a beacon 20 epochs before the deadline, fee debt on a missed proof); Arweave SPoRA (version 2.4, February 2021, approximate: the docs page 404'd; mining reward requires random access to stored chunks); Sia storage proofs (2015, approximate) and Storj audits (2018, approximate); Celestia data availability sampling (2023, approximate); EigenDA (2024, approximate); Ethereum PeerDAS (EIP-7594, 2024: custody by node id, cell KZG proofs, and the EIP states no reward or penalty for serving); Kaspa archival nodes (a flag on kaspad, unrewarded; the README fetched this morning does not document it, approximate). What differs here: the data served is the chain's own state, the challenger is the next block producer and the randomness is the chain's, and the reward is a slice of the block subsidy to a miner key, not a storage market.
|
|
|
|
**Mechanism.**
|
|
|
|
| Item | Rule |
|
|
|---|---|
|
|
| Challenge | block B's producer draws `c` keys from the weight table at the last certified checkpoint in B's past, by weight, seeded by B's prehash; for each, 8 leaf indices of the day's `D` |
|
|
| Answer | the challenged key signs `(B, leaves, openings against R_d)` and any producer carries it within `T` blocks |
|
|
| Failure | no answer carried in `T` blocks after B |
|
|
| Reward | x of the 80 producer points conditional: a key with an unanswered challenge in the window is paid 80 - x on its next blocks until it answers one |
|
|
| Bytes | 8 leaves x (64 + 25 x 32) + 96 B signature = 6.8 KB per answer; 1 challenge per block = 0.61 GB a day on every node (model, table A2) |
|
|
|
|
**Game theory (model, section A).**
|
|
|
|
| Attack | Cost | Bound |
|
|
|---|---|---|
|
|
| Serve yourself from your own nodes | zero; the challenged key answers its own challenge from the state it already holds to mine under class v5 | the proof reduces to "I hold what class v5 already makes me hold" |
|
|
| Outsource the answer to a peer that holds the state | one fetch, about 108 ms on a 100 ms link; any deadline over one block (1,000 ms) admits it | the proof becomes "someone with the state answered"; Filecoin's answer is sealing (replicas slower to fetch than to read), which costs hours of CPU per sector and does not fit a daily dataset |
|
|
| Producer griefing: refuse to carry answers | an answer gossips to every producer; withholding for T blocks needs a majority of producers for T seconds | the same bound finality lives with |
|
|
| Sybil the draw | the draw is by weight; a dust key is never drawn; splitting a key splits its draws and its loss | nothing to gain |
|
|
| Loss to a key that never serves at x = 8 | 0.1 percent key: 691 IGN a day (USD 3.5 at 0.005); 10 percent key: 69,120 IGN a day | the price of not running a node, which a miner under class v5 must run anyway |
|
|
|
|
**Load per key.** At 10,000 keys and one challenge per block a key's share of challenges is its weight share: 8.64 a day for a mean key, 0.06 MB of upload a day, 0.006 kbit/s. At 128 leaves per challenge and 8 per block, 7.6 MB a day. Every home connection carries it (table A1). The cost is on the chain, not the key: 0.61 to 76.5 GB a day of answers on every node depending on the two parameters.
|
|
|
|
**Hostile review (Monero voice).** "You pay a miner for proving it holds the thing your own lottery forces it to hold. The challenge adds 0.6 GB a day to every node to learn nothing, and the fetch bound makes it 'someone served', which is what gossip already guarantees. Filecoin pays for storage because storage is the product; your product is blocks. The one honest version is unpaid: a light-client spot check of availability, which is your rank 6 RPC."
|
|
|
|
**Cost and gate.** 0 hours as a reward; 4 hours as new-pow rank 6 (the opening RPC, unpaid), whose gate is 128 openings verifying against `R_d` on the fast-time network.
|
|
|
|
**Per tier.** As a reward: every tier pays bytes (0.61 GB a day of chain) to prove what class v5 proves. As the unpaid RPC: a node serves 102 KB per request on demand; a light client gains a daily availability spot check; no card changes.
|
|
|
|
**Verdicts.** Cryptographer: never as a reward, do the RPC (the outsourcing bound makes the proof vacuous). Consensus engineer: never (0.61 to 76 GB a day for no new property). The miner: never (a line item nobody understands). Economist: never (it moves x points for a service already compelled). Verdict: never as protocol; new-pow rank 6 stands.
|
|
|
|
### 1.4 (c) Proof of propagation: signed receipts from peers in the next block
|
|
|
|
**The idea.** A block carries receipts, signed by peers' vote keys, that they received the previous block within t seconds; the producer is paid a slice for fast propagation.
|
|
|
|
**Prior art.** Bitcoin's Relay Network and FIBRE (Matt Corallo, 2016; bitcoinfibre.org: UDP, forward error correction, compact blocks; no protocol payment to relays). Kaspa's relay is the ordinary p2p flow with no receipts (approximate). "Proof of relay" papers: this lane found none that shipped; the arXiv search for "proof of latency" returned five unrelated papers (section 7.11). GHOSTDAG itself: a slow block is red and its subsidy goes to its merger (spec 02 2.5), which is the propagation reward the DAG already pays.
|
|
|
|
**Mechanism and why it dies.**
|
|
|
|
| Item | Problem |
|
|
|---|---|
|
|
| The time field | no consensus clock finer than Kaspa's timestamp window (a header at most 10 s ahead of the clock, spec 02; the DAG tolerance 132 s in frontier 3.1); a receipt's "within t seconds" is the signer's word |
|
|
| Sybil receipts | peers are keys; weight-drawn receipts cost the attacker nothing because its own keys sign its own receipts |
|
|
| Bytes | 8 receipts x 136 B = 1,088 B per block, 94 MB a day; 32 receipts 376 MB a day (model, section H) |
|
|
| What the DAG already does | at 1 block/s on Devnet 2 run B the red rate was under 2 percent from minute six (bench-log, "Block rate on Devnet 2"); a block that propagates slowly is red and its subsidy moves to its merger: the propagation reward exists and is measured in blue blocks, which are also the vote weight |
|
|
|
|
**Hostile review (Kaspa voice).** "GHOSTDAG is a proof of propagation. Blue means it arrived in time; red means it did not; the k parameter is the clock. Receipts signed by the people who benefit from them prove nothing and cost 94 MB a day."
|
|
|
|
**Verdicts.** All four: never. Cost 0.
|
|
|
|
### 1.5 (d) Proof of state availability with block-derived challenges and the producer's own next block
|
|
|
|
**The idea.** As 1.3 but the challenge is issued by the producer's own next block (so no trusted party), answered on demand, and the reward slice is paid only to keys that answered.
|
|
|
|
This is 1.3 with the challenger named. The trap the brief names ("who issues challenges without a trusted party") is answered correctly by block-derived randomness and the producer's next block, and the answer does not rescue the idea: the outsourcing bound (a fetch in 108 ms) and the self-serving bound (the key answers from the state class v5 makes it hold) are unchanged. The one new element, "the producer's own next block" as the carrier, makes the producer the judge of its own challenge and needs a second producer to carry the answer for fairness, which is 1.3's `T` blocks.
|
|
|
|
**Verdicts.** All four: never as a reward; the unpaid availability spot check (new-pow rank 6) is the whole of what survives. Cost 4 hours for the RPC.
|
|
|
|
### 1.6 Section 1 in one table
|
|
|
|
| Variant | Prior art | New? | Survives its game? | Cost | Verdict |
|
|
|---|---|---|---|---|---|
|
|
| (a) proof of following | Verthash 2021; class v5 2026 | in form only | yes, because it does nothing | 0 | never: the epoch seed and the state root already prove following |
|
|
| (b) proof of serving | Filecoin PoSt 2020; Arweave SPoRA 2021; PeerDAS 2024 (unrewarded) | the reward to a miner key is new | no: outsourced in 108 ms; self-answered under class v5 | 0 (4 for the unpaid RPC) | never as a reward |
|
|
| (c) proof of propagation | FIBRE 2016 (unpaid); GHOSTDAG's reds | no | no: time is unverifiable; receipts are Sybil-free | 0 | never |
|
|
| (d) state availability by the producer's next block | same as (b) | the challenger rule is new | no, same bounds as (b) | 4 (RPC) | never as a reward |
|
|
|
|
---
|
|
|
|
## 2. A block reward that pays for availability of the chain's state
|
|
|
|
**The exact split proposal, as asked.** Of the 80 producer points, x are conditional on the key having served state in the window, verified as in 1.5; the rest unconditional. The candidate x: 2, 4 or 8 (8 would mirror the signing bonus of vote-or-burn, which pays 8 of the 80 for signing).
|
|
|
|
**The attack: serve yourself.** The challenged key answers from the state it holds; the challenge is drawn by weight, so the key's own weight is the only thing that decides how often it is asked. A key that runs a node (every class v5 miner) passes every challenge at zero marginal cost. A key that runs no node and proxies to a pool passes every challenge at one fetch. Nobody fails except a key whose node is down, which is the signing bonus's case already (vote-or-burn section 1: the honest-silence classes), so the conditional slice is a second liveness bonus on the same event.
|
|
|
|
**The Sybil bound.** Vote-key weight as the challenge draw: a dust key is never drawn, a split key is drawn in proportion, so splitting gains nothing. Correct, and it also means the mechanism measures the keys that already mine, who already hold the state.
|
|
|
|
**Per-tier cost (model, table A1).** At 10,000 keys, one challenge per block, 8 leaves: a mean key uploads 0.06 MB a day; at 8 per block and 128 leaves, 7.6 MB a day, 0.7 kbit/s. Any home connection on any OS carries it. The chain pays 0.61 to 76.5 GB a day of answer bytes on every node for the two parameter corners.
|
|
|
|
**What it costs a key that never serves (model, table A3).** At x = 8: 0.01 percent key 69 IGN a day, 0.1 percent 691, 1 percent 6,912, 10 percent 69,120 (USD 0.3 to 346 at 0.005). The same shape as the signing bonus and for the same population.
|
|
|
|
**Hostile review (Monero voice).** "Two liveness bonuses on one event is one bonus with worse accounting. Your signing bonus already pays 8 points for 'my node is up and following'; this pays x more for 'my node is up and holds the state', which under class v5 is the same node. Merge them or drop this."
|
|
|
|
**The economist.** No payer wants it: the slice comes from the same producer share, so it is a transfer from keys whose nodes are down to keys whose nodes are up, which the signing bonus already does; the chain pays gigabytes a day for the second accounting.
|
|
|
|
**Verdicts.** Cryptographer: never (vacuous under the outsourcing bound). Consensus engineer: never (bytes). The miner: never (a second deduction line is read as a second fine; vote-or-burn's 93 to 97 percent respect for one bonus at genesis would not survive two). Economist: never. Cost 0.
|
|
|
|
---
|
|
|
|
## 3. Mining that is also a light-client service
|
|
|
|
**The idea.** Every miner's node serves finality-in-proof public values (494 B) and certificate bitmaps to phones; a reward slice or a fee market pays for it.
|
|
|
|
**Prior art.** Ethereum Portal Network (2021 to 2026; ethportal.net: history, state and beacon networks; clients Trin, Nimbus Portal (Fluffy), Ultralight, Shisui; the site states no reward for nodes). Helios (a16z, 2022, approximate for the year; github: weak-subjectivity checkpoints as the root of trust, sync-committee verification). Mina's snarkers (2021, approximate): a fee market for SNARK work inside the protocol. Celestia light nodes and bridges (2023, approximate). What Igneum has that none of these had: the serving node is a miner with a funded key, and the object served (494 B of public values plus a 260 B Groth16 proof, once the wrapper lands) is tiny and self-certifying.
|
|
|
|
**Whether it is a protocol item.** No. The object is public values a node already holds; serving it is one HTTP or wss endpoint (spec 10.7's read-only table); the phone app already reads nodes it pins (phone-app section 5). A fee market for 786 bytes is a transaction per fetch at 0.0051 IGN (frontier 3.13's transfer floor), which no phone will pay per refresh and no node needs. A reward slice is 1.3's reward with a different payload and the same vacuity.
|
|
|
|
**What it is: an Ember feature.** Ember in verify mode is frontier 3.8 (do now, 20 hours). The light-client serving side is a line in the node's RPC: `igneum_getLatestWrappedProof`, served to any client, rate-limited per IP, with the phone app pinning the user's own node by its card (phone-app section 5) or the seed list. Bytes per day per phone: 786 B per refresh, 2,880 refreshes a day if it polls every checkpoint = 2.3 MB (spec 10.5's phase-two figure, 2.30 MB, matches).
|
|
|
|
**Game theory.** A node that lies serves a proof that does not verify, which the phone refuses; a node that withholds is replaced by the next pinned node. No payment, so no cheating for pay. The one attack is topology: a phone pinned to one node is eclipsed by that node, which spec 10.6's N of M seed agreement bounds.
|
|
|
|
**Hostile review (Kaspa voice).** "Serving 786 bytes is not a service you price. It is a feature of a node. Put it in the app."
|
|
|
|
**Cost and gate.** 4 hours (the RPC and the rate limit) on top of frontier 3.8's 20; gate: a phone on cellular shows "locked, voter set verified in the proof" from a miner's Ember node with no other node asked, bytes counted on the Verify screen.
|
|
|
|
**Per tier.** Every miner's Ember serves phones by default behind a per-IP limit (a home upload of 786 B per request is nothing); a holder's phone gets its proof from any miner; a pool user's member process is the same Ember; no card or OS difference.
|
|
|
|
**Verdicts.** Cryptographer: do now (as the Ember line). Consensus engineer: do now, not a protocol item. The miner: do now ("my node serves my phone" is a sentence miners like). Economist: do now, unpaid; a fee market here would price a service below its transaction cost.
|
|
|
|
---
|
|
|
|
## 4. A decentralised pool in the protocol
|
|
|
|
### 4.1 The design, as asked
|
|
|
|
| Item | Rule |
|
|
|---|---|
|
|
| A share | a block header at a low difficulty, signed by the miner's own payout key, referencing the round `r` |
|
|
| The round | the window of blocks between two chain-block boundaries, e.g. 600 chain blocks (the record window of spec 7.8) |
|
|
| Carriage | any block carries shares it has seen; a share is valid if its header's PoW passes the share target and its parents are in the carrier's past |
|
|
| Payout | a coinbase rule every node computes: the producer share of blocks in round r is split by share weight (`2^-s`) over the shares carried in round r's blocks, PPLNS style, minus nothing (no operator, no fee) |
|
|
| Variance reduction | a miner is paid by its shares whether or not it found a block |
|
|
|
|
### 4.2 Prior art
|
|
|
|
| Name | Year | What it did | What differs |
|
|
|---|---|---|---|
|
|
| P2Pool (Bitcoin) | 2011 (Forrest Voight, approximate) | a sidechain of shares at a 10-s target; payouts in the coinbase of found blocks; no operator | the shares were off the main chain; nodes did not verify them |
|
|
| FruitChains | Pass and Shi, 2016 (eprint 2016/916) | "fruits" as low-difficulty PoW objects carried in blocks, rewarded fairly: any honest set with phi of the hash gets at least (1 - delta) phi of the reward | the exact in-protocol shape asked for here, published nine years ago; never shipped on a major chain |
|
|
| SmartPool | Luu, Velner, Teutsch, Saxena, 2017 (eprint 2017/019) | shares committed by Merkle root to an Ethereum contract, verified by sampling; miners paid 0.6 percent of block rewards in transaction fees | a contract, not a coinbase rule; the operator is the contract |
|
|
| Monero P2Pool | SChernykh, 2021 (github SChernykh/p2pool) | a 10-s share sidechain merge-mined with Monero, PPLNS over 2,160 shares (6 hours), no operator, payouts as coinbase outputs | off the main chain; Monero nodes do not verify shares |
|
|
| Stratum V2 job negotiation | Braiins, 2019 onward (approximate) | the miner builds its own template; the pool must pay shares on it | an operator remains; the vote and template are the miner's (spec 09 already takes this) |
|
|
| Ocean (Bitcoin) | 2023 (approximate) | an operator pool with on-chain payouts per block (TIDES) | an operator remains |
|
|
| Braidpool | 2021 onward (github braidpool/braidpool: in development, not production) | a DAG ("braid") of shares; miners build their own blocks; constant-size payouts | not shipped |
|
|
| Kaspa "SPECTRE shares" | none found | | Kaspa pools are Stratum bridges with operators (approximate) |
|
|
|
|
So the in-protocol pool is FruitChains (2016) with Igneum's payout key and round. It is not new.
|
|
|
|
### 4.3 The bytes and the verifier (model, section B)
|
|
|
|
| Miners | Share interval | Shares per block | Bytes per block (compact 169 B) | Per day on every node | Verifier cores at 1.35 / 5.06 / 10 ms per share |
|
|
|---|---|---|---|---|---|
|
|
| 1,000 | 10 s | 100 | 16.5 KB | 1.5 GB | 0.14 / 0.51 / 1.0 |
|
|
| 10,000 | 10 s | 1,000 | 165 KB | 14.6 GB | 1.35 / 5.06 / 10.0 |
|
|
| 100,000 | 10 s | 10,000 | 1,650 KB | 146 GB | 13.5 / 50.6 / 100 |
|
|
| 100,000 | 100 s | 1,000 | 165 KB | 14.6 GB | 1.35 / 5.06 / 10.0 |
|
|
| 100,000 | 1,000 s | 100 | 16.5 KB | 1.5 GB | 0.14 / 0.51 / 1.0 |
|
|
|
|
The full-header form (496 B) is 2.9x the bytes. The verifier at the class v4 cold figure (5.06 ms) needs 50 cores per node at 100,000 miners and a 10-s share interval, which no home node has; at a 1,000-s interval it fits one core and 1.5 GB a day, but then the variance reduction is the thing being bought and it has gone:
|
|
|
|
| Income source | Paying events per day | CV of a day's income | CV of a month |
|
|
|---|---|---|---|
|
|
| solo 17 MH/s at 1 TH/s | 1.5 | 82.5 percent | 15.1 percent |
|
|
| shares at 1 per 1,000 s | 86 | 10.8 percent | 2.0 percent |
|
|
| shares at 1 per 100 s | 864 | 3.4 percent | 0.6 percent |
|
|
| shares at 1 per 10 s | 8,640 | 1.1 percent | 0.2 percent |
|
|
|
|
At 100,000 miners the chain can afford one share per 1,000 s per miner (1.5 GB a day, one core), which gives a small card a 10.8 percent daily CV: a real improvement on 82.5 percent, at the cost of 1.5 GB a day on every node including every phone-class light client that would want to verify the coinbase. At 10,000 miners and 100 s the same bytes buy 3.4 percent.
|
|
|
|
### 4.4 Does the vote key and sortition machinery give a round for free?
|
|
|
|
Yes for the ROUND, no for the SHARES. W2 already counts blue blocks per key over 30 days, and the shard sortition already draws by that count (spec 7.2). A "round" and a per-key tally exist in every node. What does not exist is a sub-block unit of work, and that is the whole cost: every share is a PoW object every node verifies. The free version is to pay by BLOCKS over a window, which the protocol already does (every block pays its producer), so the free "pool" is the chain itself, and its variance is the solo row above.
|
|
|
|
### 4.5 The attacks
|
|
|
|
| Attack | Effect | Bound |
|
|
|---|---|---|
|
|
| Share withholding (find a block, publish only shares) | in an operator pool the withholder is paid shares and the pool loses the block; here the round's payout IS the blocks found, so a withheld block shrinks everyone's payout including the withholder's own share of it: the withholder loses `(1 - its share) x 80` points and gains nothing | self-defeating; FruitChains' fairness bound is the formal version |
|
|
| Share stuffing | every share is PoW at the share target, so a fake share costs its hash; stuffing is mining | none needed |
|
|
| Share grinding on the round boundary | a share's round is fixed by its parents; a share straddling a boundary is a DAG event nodes already order | none needed |
|
|
| A majority refusing to carry others' shares | it earns the majority a larger split of the round; this is red-flooding by another name, 26 to 28 percent of honest income at 51 percent (51-percent.md section 1) | the same bound as today's reds |
|
|
| Verifier DoS | a flood of invalid shares costs a node 5 ms each before rejection | the per-peer rate limits of the p2p layer; the ban score |
|
|
|
|
### 4.6 The honest verdict against docs/plans/pool.md
|
|
|
|
The shipped pool v0 (5 October 2026, rebased 6 October) already removes the two things an in-protocol pool is for: the operator holds no key and no vote (members sign their own votes through their own verifiers, spec 9.7), and the share rule is fixed by spec 9.8 so the member keeps its own ledger. The measured operator cost is 1.35 ms per share check (4,800 to 22,700 members per core) and 1 percent fee by default. What the operator still controls: transaction choice for mode A members who do not check (mode C fixes it), and the payout ledger's honesty (the member's own ledger plus the chain's blocks under its key bound it).
|
|
|
|
The finished form is therefore the pool design plus one addition the brief names: **a verifiable payout contract**, which is SmartPool (2017) on Igneum's EVM: the operator posts the round's share Merkle root and the payout list; any member can prove under-payment with its own share log against the root; the contract pays from the pool address. Cost 16 hours (contract 6, operator posting 4, member proof and the Ember line 6). Gate: a member whose share is dropped from the root proves it on the fast-time network and is paid; an honest round costs the operator one transaction. Bytes on chain: 32 B per round per pool. Verifier cost on nodes: nothing per share.
|
|
|
|
**Hostile review (Monero voice).** "P2Pool exists because we did not want shares on the main chain; your numbers say why: 14.6 to 146 GB a day. Our P2Pool is a sidechain nobody but miners runs. Build that if you want no operator; it costs your chain nothing." Answer: a Monero-style P2Pool sidechain for Igneum is an app a pool operator could ship (the share chain's only chain-side object is the coinbase payout list), and it is the same code as the pool v0 member minus the server; the lane recommends the contract first because it keeps every existing pool (HiveOS, WhatToMine listings) and makes them verifiable.
|
|
|
|
**Per tier.** Home miner on any card: nothing changes in the worker; under the contract a member can prove under-payment from its own log. Rig: one key per rig as today. Pool user: the pool's round is public. Node operator: 32 B per round per pool instead of 1.5 to 146 GB a day. Light clients: unchanged.
|
|
|
|
**Verdicts.** Cryptographer: never in protocol (FruitChains is the prior art and the bytes are the reason it never shipped); prototype the contract. Consensus engineer: never in protocol (50 cores per node at 100,000 miners on a 10-s share); the contract 16 hours. The miner: never in protocol (a chain that grows 14.6 GB a day from shares is the first thing a reviewer attacks); the contract is what listings want. Economist: the operator's 1 percent is already below SmartPool's 0.6 percent plus gas (approximate); the contract makes the 1 percent honest. Verdict: never in protocol; prototype the verifiable payout contract, 16 hours.
|
|
|
|
---
|
|
|
|
## 5. Heat as product
|
|
|
|
**The idea.** Ember's "heat mode" targets a room temperature or a schedule: the card mines when the room wants heat and idles when it does not; the chain does nothing.
|
|
|
|
**Prior art.** Heatbit (2022 launch, approximate; heatbit.com this morning lists Bitair at 25 W, 1.2 TH/s, USD 179 to 249, and names earlier Maxi and Trio models), 21energy (Austria; Ofen 3 heaters EUR 1,658 to 3,325, "7 to 10 kW" central-heating models coming, 21energy.com), Qarnot (France, founded 2010, approximate, the Wikipedia page 404'd; QRad computing heater 2013, approximate; sells HPC and heats buildings), MintGreen in North Vancouver (2021, approximate), the Finnish and French district-heat trials (approximate; no page fetched). Every one is an ASIC or HPC box sold as a heater. None is a GPU chain's own client with a thermostat. Ember's version is new as a client feature and nothing else.
|
|
|
|
**Numbers (model, section C).** A 300 W card delivers 300 W of heat at the card's electricity price. The competition is a gas boiler at 90 percent or a heat pump at COP 3.
|
|
|
|
| Region | Card per hour | Gas boiler, same 300 W | Heat pump COP 3 | Resistive electric | Card must earn per hour to match boiler / heat pump |
|
|
|---|---|---|---|---|---|
|
|
| UK (Ofgem, 1 Oct to 31 Dec 2026: 26.32 p electricity, 7.97 p gas) | 7.90 p | 2.66 p | 2.63 p | 7.90 p | 5.24 p / 5.26 p |
|
|
| EU (Eurostat H2 2025: EUR 0.2896; gas EUR 0.11 approximate) | 8.69 c | 3.67 c | 2.90 c | 8.69 c | 5.02 c / 5.79 c |
|
|
| US (EIA July 2026: 18.31 c; gas 5 c approximate) | 5.49 c | 1.67 c | 1.83 c | 5.49 c | 3.83 c / 3.66 c |
|
|
|
|
Against a resistive heater (a bedroom panel, a US baseboard) the mining heat is free and every IGN earned is profit. Against a boiler or a heat pump the card must earn about 5.3 p an hour in the UK.
|
|
|
|
| Network hash | IGN per hour, 100 MH/s card at 100 IGN a block | at USD 0.005 | at 0.02 | at 0.10 |
|
|
|---|---|---|---|---|
|
|
| 100 GH/s | 360 | USD 1.80 | 7.20 | 36.00 |
|
|
| 1 TH/s | 36 | 0.18 | 0.72 | 3.60 |
|
|
| 10 TH/s | 3.6 | 0.018 | 0.072 | 0.36 |
|
|
|
|
So at 1 TH/s and USD 0.02 a 5090-class card earns 72 US cents (about 55 p) an hour and heats for 7.9 p: a heater that pays. At 10 TH/s and USD 0.005 it earns 1.8 cents and the heat costs 5.3 p more than gas: a heater that costs 3.9 p an hour net, which is still under the resistive panel it replaces in a room without a radiator. The honest sentence for the app: "In heat mode your card is an electric heater that also earns; whether it beats your boiler depends on the network and the price, shown live."
|
|
|
|
**Game theory.** None on the chain: a heat-mode miner is a miner with a schedule. One effect to name: seasonal hash. If heat mode becomes a large share of hash, winter hash rises and summer hash falls in the northern hemisphere; the DAA absorbs it, and the 30-day weight window means a summer departure of heat miners is a slow slide, not a departure event (the 10 percent per hour rule is not touched by a thermostat that ramps over weeks).
|
|
|
|
**Hostile review (Monero voice).** "A thermostat in a miner is a feature every miner GUI has had since 2014 (approximate: temperature targets in miner software). Call it heat mode if it sells; it changes nothing about the chain." Correct.
|
|
|
|
**Cost and gate.** App feature, 6 hours: a target-temperature input, the schedule, a sensor source (the OS's, or the card's own temperature as a proxy with a stated error), the live "earns X, heats Y, your boiler would cost Z" line from the tariff the user enters (phone-app 4.1 already has the tariff field). Gate: a room sensor loop on PC 1 holds a set temperature within 1 degree over four hours while the hash rate follows the duty cycle, logged.
|
|
|
|
**Per tier.** An 8 GB card at 150 W is a 150 W heater (the small-room case); a 5090 at 326 to 575 W (the ladder page's TGP range) is a large-room heater; a rig is a space heater that should not be in a bedroom; a pool user's duty cycle shows as a share-rate pattern the pool sees; macOS: the M5 Max at low watts is a poor heater; Windows and Linux alike.
|
|
|
|
**Verdicts.** Cryptographer: do now (no protocol content). Consensus engineer: do now, 6 hours. The miner: do now (the one feature a home miner in a cold flat asks for first; the number line must show when it loses to gas). Economist: do now, with the tariff line mandatory so nobody reads "free heat".
|
|
|
|
---
|
|
|
|
## 6. Phone-verifiable everything
|
|
|
|
**What remains after finality-in-proof and the WASM verifier (horizon rank 19).** Finality-in-proof gives 494 B of public values that say "locked at checkpoint i by x of y weight" under one proof; rank 19 gives the Groth16 or Plonk wrapper verified in a tab. What is left is the last mile: carrying that object with no network, and a "verify this block" link on the explorer.
|
|
|
|
**Prior art.** Mina (2021, approximate): a constant-size recursive proof of the whole chain, verified on a phone, with proof-of-stake under it. zkSync's block proofs on Ethereum (2023, approximate): verified by a contract, not a phone. Helios (a16z, 2022): a light client in WASM, trust rooted in a weak-subjectivity checkpoint. No proof-of-work chain has a phone-verifiable finality object; after finality-in-proof Igneum does, and the QR is only packaging.
|
|
|
|
**The object (model, section D).** Groth16 proof 260 B (SP1 docs) + public values 494 B + verifying-key id 32 B = 786 B. A version 40 QR at level L holds 2,953 B; a version 25 at level M about 1,000 B (approximate). So one QR carries the proof with room for a block hash and a receipt path of up to about 2 KB, and a phone with the pinned verifying key verifies it with no network: one bn254 multi-pairing, of the order of 2 to 5 ms native on a phone (approximate; Helios and the xycloo WASM demos are the order-of-magnitude anchors, 10 to 50 ms in WASM, frontier 3.4). The URL form is the same bytes base64 in a fragment, 1,048 characters, under every browser's limit.
|
|
|
|
**What the phone learns with no network.** That some chain with this chain id, under this aggregator program, had checkpoint i locked by x of y weight, with state root R and history root H, and (with the receipt path) that transaction T is in a block at or below the lock. What it cannot learn offline: that this is the LATEST lock (staleness: the `lock_daa` field lets it show the age against its own clock, labelled "age by your clock").
|
|
|
|
**The wrapper's cost on a 5090.** SP1's docs give PLONK as about 1 min 30 s longer than a compressed proof and Groth16 as the recommended on-chain form at 260 B; the wrap runs on the CPU in gnark whatever the GPU (approximate, from memory of SP1's wrapper architecture). So the wrap is not per segment (8 s): one wrapper machine wraps one proof per 90 s, and the chain's "latest wrapped proof" is 38 segments behind the tip at a 300-s cadence or 8 behind at 60 s with two wrapper machines (model, table D). The measurement the design needs is the one frontier 3.4 names (R4): wrap the pinned aggregator proof on a 24 GB fleet card and the box's CPU, record seconds and RAM. Expected, approximate: 60 to 180 s and 16 to 32 GB of RAM.
|
|
|
|
**The explorer link.** "Verify this block" on the explorer renders the QR and the URL for the newest wrapped proof whose history covers the block, plus the block's MMR path; the tab verifies it with rank 19's WASM verifier and shows the milliseconds. 4 hours once rank 19 lands.
|
|
|
|
**Game theory.** A forged QR fails verification; a stale QR shows its age; a QR from another chain id is refused. A soundness bug in SP1 forges a lock on the phone and not on the chain (full nodes verify the BLS certificate natively, finality-in-proof 5.1), which is the stated light-client row.
|
|
|
|
**Hostile review (Kaspa voice).** "A QR that says 'locked' with no network says 'locked as of when the QR was made'. Say the age in big letters or you will have people paying against last week's lock." Correct; the age line is in the design.
|
|
|
|
**Cost and gate.** 8 hours (QR and URL packing 2, the phone verify call on the shared `igneum-light` engine 4, the explorer link 2) plus rank 19's 16. Gate: a phone in airplane mode scans a QR printed from the explorer and shows "locked at checkpoint i, x percent of weight, age 4 minutes by your clock, verified in N ms"; a QR with one byte changed is refused.
|
|
|
|
**Per tier.** Holders: a proof in their pocket. Miners: their node serves the wrapped proof (section 3). Rollup customers: the same 786 B is what their bridge verifies. Node operators: one wrapper machine per network at a 300-s cadence (a box, not a card).
|
|
|
|
**Verdicts.** Cryptographer: do now after rank 19 (the first offline-verifiable PoW finality). Consensus engineer: do now (nothing in consensus). The miner: prototype (nice, not what miners ask for). Economist: do now (the cheapest public proof of the phase-two claim; the wrapper machine is one box).
|
|
|
|
---
|
|
|
|
## 7. More candidates, generated and judged
|
|
|
|
Twelve more. The first four are this lane's own (7.1 to 7.4); the rest are the brief's list, judged.
|
|
|
|
### 7.1 A weight-backed peer directory in the coinbase (this lane's candidate)
|
|
|
|
**The idea.** A block producer may opt in to carry its node's reachable address (IPv6 plus port, 18 B) in its coinbase extra data, signed by the vote key the header already names. The chain becomes its own seed list: a fresh client draws its outbound peers from the last 30 days of carried addresses, weighted by the carrying keys' W2 weight. No DNS seed, no shipped seed list beyond genesis peers, no operator.
|
|
|
|
**Prior art.** Bitcoin's DNS seeds and `addr` gossip (2011 onward, approximate); Ethereum's ENR and discv5 (2019, approximate); Kaspa's dnsseeder (approximate); the eclipse attack paper (Heilman, Kendler, Zohar, Goldberg, USENIX Security 2015) and its address-bucket fixes. No chain this lane knows writes reachable addresses into blocks under the producer's key with weight-weighted draws. New in form; the pieces (addr gossip, weighted sampling) are old.
|
|
|
|
**Mechanism.**
|
|
|
|
| Item | Rule |
|
|
|---|---|
|
|
| Object | `IGNA`-style section: `0x05 ‖ ip16 ‖ port2`, opt-in, at most one per block, signed by the header's vote key (the key reveal already proves possession) |
|
|
| Directory | every node keeps the last window's entries keyed by vote key hash (one address per key, newest wins) |
|
|
| Draw | a client picks outbound peers by the key's W2 weight; keys under dust are not drawn |
|
|
| Bytes | 18 B per block = 1.56 MB a day on every node (model, section E); 30 days at most 2.6 M entries, far fewer after de-duplication by key |
|
|
|
|
**Game theory (model, table E).** An attacker with share a of the 30-day weight lists share a of the directory. With 8 outbound peers drawn by weight, the probability every peer is the attacker's is a^8: 2.6e-6 at 20 percent, 1.8e-4 at 34 percent, 4.6e-3 at 51 percent; with 16 peers 6.6e-12, 3.2e-8, 2.1e-5. Against this, a DNS seed is one operator and a shipped list is one release key. The attack that remains: listing honeypot addresses under honest-looking keys costs the attacker 30 days of mining per key, the same bound as every other weight-backed thing on this chain. Griefing: a producer lists a victim's address to draw traffic to it; bounded by one address per key per block and the signed key, so the lister is named on chain.
|
|
|
|
**Hostile review (Kaspa voice).** "Your reachable miners are the rigs and the seeds; home miners are behind NAT and will list nothing or list a dead address. The directory is a list of rigs weighted by rigs, which is the thing you said you wanted to avoid (frontier 3.8's Kaspa attack). Also a 30-day-old address is a dead address." Answer: the client draws from the newest entries first with the weight as the tie-break, a liveness probe before use is the ordinary `version` handshake, and the rigs-weighted list is still a list of parties that mined 30 days of public blocks rather than one DNS operator. The NAT point stands and is the measurement.
|
|
|
|
**Cost and gate.** 10 hours: the coinbase section and signature check (3), the directory and the weighted draw in the node (4), the client's use in Ember verify mode and the phone (3). Gate: a fresh node with no seed list and genesis peers only reaches 8 outbound peers from the directory on the fast-time network; an eclipse harness with a 34 percent attacker listing 34 percent of addresses eclipses the fresh node in under 0.1 percent of 1,000 starts (expected 1.8e-4 at 8 peers).
|
|
|
|
**Per tier.** Home miner: opt-in, off by default (NAT); a rig and a seed node opt in; a pool node opts in; the phone and Ember verify mode gain a seed list with no DNS; no card, OS or vendor difference; node operators store 1.56 MB a day.
|
|
|
|
**Verdicts.** Cryptographer: prototype (a weight-backed seed list is the right shape; measure the NAT fraction). Consensus engineer: prototype (10 hours, nothing in fork choice). The miner: watch (home miners will not opt in; rigs will; fine). Economist: prototype (removes one operator from the trust row for 1.56 MB a day).
|
|
|
|
### 7.2 Sign-in with Igneum: 30 days of public work as a login (this lane's candidate)
|
|
|
|
**The idea.** A vote key signs a challenge to prove its W2 weight to a third party: a rental marketplace, a forum, a faucet, an airdrop-free allowlist. The verifier reads the weight from any node or the finality-in-proof public values. Sybil cost is 30 days of mining per identity.
|
|
|
|
**Prior art.** Hashcash (Back, 1997): proof of work as an anti-spam stamp. Sign-In with Ethereum (EIP-4361, 2021): a signed message as a login. Proof-of-humanity and Gitcoin Passport (2021 onward, approximate): social Sybil resistance. No chain has a non-transferable, work-earned weight per key to sign with; Igneum does.
|
|
|
|
**Game theory.** A key's weight is worth its 30 days of pool income (work-stake section 5: 2,793 IGN for an 8 GB card at 100 GH/s), so lending it to a login is lending a reputation that cannot be split without halving each half. A marketplace that gates on weight gets a Sybil cost it cannot buy elsewhere. The attack: a key used as a login is a key whose secret is on a machine that talks to websites; the pool spec's one-signer rule (9.6 item 3) and the equivocation strip mean a stolen key is burned by its thief in one double vote. The login must therefore be a delegated session key signed once by the vote key, never the vote key online.
|
|
|
|
**Hostile review (Monero voice).** "You are building an identity out of a mining key. Miners do not want identities; that is why they mine." Answer: opt-in, delegated, and the first customer is the rental escrow of frontier 3.13, which already needs the key.
|
|
|
|
**Cost and gate.** 6 hours (the delegation message, the verifier library in `igneum-light`, an Ember button). Gate: a web page verifies a delegated signature against a node's weight for one key and refuses a key under dust.
|
|
|
|
**Per tier.** Any key above dust (100 blocks a window; 3.86 MH/s at 100 GH/s) can sign in; an 8 GB card qualifies at every network size up to about 440 GH/s (where 17 MH/s falls under dust, arithmetic on work-stake section 5); below that, nothing.
|
|
|
|
**Verdicts.** Cryptographer: watch (the delegation design is the whole risk). Consensus engineer: watch (not consensus). The miner: watch. Economist: prototype only with the rental escrow as the first user.
|
|
|
|
### 7.3 Public timestamping on the proof chain (this lane's candidate)
|
|
|
|
**The idea.** Any hash posted in an Igneum transaction is, 60 to 93 s later, inside a certified checkpoint and, after the segment proof, inside a 786 B offline-verifiable object (section 6). OpenTimestamps (Todd, 2016, approximate) does this on Bitcoin with hours of latency and a Merkle aggregator; Igneum does it with the lock latency and a proof a phone verifies.
|
|
|
|
**Game theory.** None: a transaction with a hash. The base fee burns; the priority fee pays. The product is the receipt path in the QR.
|
|
|
|
**Cost and gate.** 4 hours (a contract that emits the hash in a log, the receipt path in the explorer link of section 6). Gate: a timestamp verified offline on a phone from a QR.
|
|
|
|
**Verdicts.** All four: do now once section 6 lands; it is section 6's first use. The economist: a product with a fee a user pays, which is the kind the utility lane wants.
|
|
|
|
### 7.4 Hash-rate futures as an app (this lane's candidate, judged against ruling)
|
|
|
|
**The idea.** Braidpool's stated purpose: a miner sells its future shares forward for cash now. On Igneum a miner could sell its next window's pool income (the work-stake bond) forward.
|
|
|
|
**Why it dies.** A forward needs a counterparty and collateral; the collateral is a coin balance posted by the seller or buyer, which is a coin bond, which is refused by ruling for anything the protocol touches. As an app between consenting parties with their own escrow it is allowed and the chain is indifferent. Prior art: Braidpool (in development), NiceHash (2014, an operator market). Verdict: never in protocol; watch as a third-party app. 0 hours.
|
|
|
|
### 7.5 Finality as a service for other PoW chains
|
|
|
|
**The idea.** Another PoW chain posts its block hashes into Igneum and treats the Igneum lock as a checkpoint; its clients refuse reorgs below the last anchored, locked hash. Igneum relies on nothing; others relying on Igneum is allowed by ruling.
|
|
|
|
**Prior art.** Komodo dPoW (2018, approximate; the academy page 404'd): notary nodes write a chain's block hash into Bitcoin every 10 minutes (approximate) and protected chains refuse reorgs below it; VeriBlock Proof-of-Proof (2019, approximate; veriblock.org: "securing 1 chain", market cap USD 9 M); Babylon (Tas, Tse, Gai, Kannan, Maddah-Ali, Yu, 2022, IEEE S&P 2023: PoS chains checkpoint to Bitcoin; stake withdrawal from weeks to under 5 hours). Igneum's difference: the anchored chain gets a 90-s lock instead of Bitcoin's hour, and an offline-verifiable proof instead of an SPV path.
|
|
|
|
**Game theory.** For Igneum: none; an anchor is a transaction. For the anchored chain: its safety becomes Igneum's finality, which pauses whenever under two thirds of weight signs (spec 03 3.7); an anchored chain must fall back to its own PoW during a pause and say so, which Babylon's design also requires of its consumers. A hostile Igneum majority cannot forge an anchor (it would need two thirds of weight to lock a false chain) but a third of weight can pause anchoring. Market (model, section G): at Komodo's cadence (144 anchors a day) the fee is 0.73 IGN a day, under one cent at any listed price. Revenue to Igneum: nothing material; standing: a product no PoW chain offers with proof-carrying finality.
|
|
|
|
**Hostile review (Kaspa voice).** "Who are the customers? Komodo's dPoW protected a handful of Komodo-family chains and VeriBlock secures one chain worth USD 9 M. Small PoW chains that fear 51 percent (ETC, BTG, VTC in 2018 to 2020) chose checkpoints from their own developers over paying anyone." Correct; the demand is the gate.
|
|
|
|
**Cost and gate.** 16 hours: an anchor contract (4), a client library that reads the lock and the proof for an anchored hash (8), a reference patch for one open-source PoW node (4). Gate: one outside chain's testnet runs the patch for a week and refuses a staged deep reorg below an anchored lock.
|
|
|
|
**Per tier.** Nothing changes for any Igneum miner or holder; an anchored chain's miners get a 90-s checkpoint they did not vote for, which their community must accept (the Komodo precedent: accepted by chains that chose it).
|
|
|
|
**Verdicts.** Cryptographer: prototype (sound, and the first external use of the lock). Consensus engineer: watch (demand first). The miner: watch (no miner cares). Economist: watch (USD 0.004 a day per customer at the floor is standing, not income).
|
|
|
|
### 7.6 The hourly program as a standing public hardware benchmark with a leaderboard
|
|
|
|
Frontier 3.16 (do now, 10 hours) publishes the corpus; the leaderboard is the product on top: per card model, per vendor, per driver, the median rate and joules per hash across the hour's variants, from the fleet library and opt-in Ember submissions, with the bit-exact fingerprint per entry. Prior art: Geekbench (2007, approximate), hashrate.no and WhatToMine (2018 onward, approximate) as operator tables; none continuous on a random kernel stream. New as a continuous random-kernel benchmark. Game theory: a submitter lies about its rate; the fingerprint proves bit-exactness not speed, so self-reported rates are labelled and the fleet's measured rows are the reference tier. Cost 8 hours on top of 3.16. Gate: a public page with the eleven measured cards (prover-tiers-real-cards.md) as the reference tier and opt-in rows beneath. Verdicts: do now (all four; the miner: "a leaderboard is the first thing a mining YouTuber screenshots").
|
|
|
|
### 7.7 Proof of unique card: count machines, not keys
|
|
|
|
Dead, and the reason is the design's own: nothing in consensus counts nodes, keys or cards (spec 3.1 W6, ledger F17), so a count of machines would be a Sybil surface the design removed on purpose; and a chip emulates any fingerprint it has been shown (frontier 4.3's Monero attack). What the design does count is blocks, and a card's blocks are its weight. Verdict: never. 0 hours.
|
|
|
|
### 7.8 Shard proving as the on-ramp: a proving-only key earning pool income without a card
|
|
|
|
Dead by the sortition rule: shard assignees are drawn by W2 weight (spec 7.2 step 2); a key with no blocks has no weight and is never drawn. What a proving-only key can do today: claim shards after the exclusive window (spec 7.2 item 4) and prove external jobs under the pool protocol's bonded key route (work-stake section 5, the prover row). That is the on-ramp and it exists. Verdict: never as a rule change; the two existing routes stand. 0 hours.
|
|
|
|
### 7.9 Miner-signed release: 95 percent of weight signs the release hash
|
|
|
|
Compare horizon rank 13 (reproducible-build attestations, N of M builders, 12 hours). A weight signature says "we RUN this hash", not "we BUILT it", and running is what the 95 percent class signal already measures (the object byte in the header version). So the idea is the P2 signal applied to a binary hash instead of a class byte: a header bit per release. Prior art: BIP9's version bits (2015) for rules, not binaries; no chain signals binary hashes (approximate). What it adds: a chain-readable "share of weight on release X" that Ember can show beside rank 13's "N builders reproduced X". Cost 4 hours (a release-hash field in the coinbase, tallied by the explorer, no consensus effect). Game theory: lying costs nothing and buys nothing; it is a statistic. Verdict: watch, fold into rank 13's display. Cryptographer: watch. Consensus engineer: do as a coinbase field, 4 hours. The miner: watch. Economist: watch.
|
|
|
|
### 7.10 An energy-price oracle from miners' own signals
|
|
|
|
**The idea.** Each producer carries its electricity price in its coinbase; the window's weighted median is the chain's energy price, free of any oracle operator.
|
|
|
|
**Prior art.** Chainlink and the oracle networks (2017 onward, approximate); frontier 3.5's miner-voted dials (Ethereum's gas-limit vote, geth `VerifyGaslimit`); no PoW chain carries a price field (approximate).
|
|
|
|
**Game theory.** A field nobody is paid for and nobody is punished for lying in is noise; a field that feeds a price (the job reserve of horizon rank 7, "measured proving electricity per pgas at the published settlement rate") is a field miners overstate, bounded only by the customer's bid, which rank 7 already makes the price. So the oracle is either noise or a lever on the job price that the bid neutralises. The honest use is statistical: the miner community lead's hardware-economics model wants real tariffs, and Ember's opt-in telemetry (the tariff field of phone-app 4.1) gives them off-chain with no consensus bytes.
|
|
|
|
**Verdict.** Never in consensus; an opt-in Ember statistic. 2 hours for the telemetry line. All four personas: never in protocol.
|
|
|
|
### 7.11 A first-block bonus per new key, Sybil-bounded by dust
|
|
|
|
**The idea.** A key's first block above dust pays a bonus B, to welcome newcomers; the signing bonus of vote-or-burn exists, so this would be the second bonus.
|
|
|
|
**Game theory (model, section F).** Dust is 100 blocks a window. A 10 percent miner makes 259,200 blocks a window and can keep 2,592 keys above dust, each collecting B once: at B = 100 IGN that is 259,200 IGN a window, 1 percent of its subsidy, for free (weight and sortition are per block, so the split costs it nothing but its own vote's convenience; the pool spec's one-key rule is a client default, not a consensus rule). A bonus large enough to matter to a newcomer (10 blocks, 1,000 IGN) is a 10 percent raise for every miner willing to run 2,592 keys. The dust bound makes the Sybil expensive in KEYS and free in HASH, and keys are free. Verdict: never. 0 hours. The miner: "an instamine with extra steps".
|
|
|
|
### 7.12 A cross-vendor parity bounty
|
|
|
|
Dead by ruling (no device bounty): a payment conditioned on a card model is a device bounty whatever it is called. What the design does instead is measure (the eleven rented cards, the ladder's per-rung 5 percent rule) and publish. Verdict: never. 0 hours.
|
|
|
|
### 7.13 In-protocol insurance against reorgs for exchanges
|
|
|
|
**The idea.** An exchange that credited a deposit later reversed by a reorg is made whole from a protocol pool.
|
|
|
|
**Prior art.** None shipped in any protocol (this lane found no primary page; approximate). Off-chain: exchange confirmation policies; Nexus Mutual-style cover for contracts (2019, approximate), not for reorgs.
|
|
|
|
**Why it dies.** Who pays? A protocol pool is either emission (a transfer from miners to exchanges, which the miner persona rejects on the Decred and Ethereum precedents in vote-or-burn section 2) or the proving pool (a transfer from provers, who did nothing wrong). The design's own answer is stronger than insurance: a certified checkpoint cannot be reversed (51-percent.md section 2), the four-state rule credits on "finalised" (ledger P17), and the exchange guidance says confirm at the lock or at 12 hours during a pause (horizon rank 16). Insurance is only wanted where finality is paused, and during a pause the only reorg-capable party is a hash majority with no slashable bond, by ruling. Verdict: never; the guidance is the product. 0 hours.
|
|
|
|
### 7.14 Pause insurance from the proving pool
|
|
|
|
Dead: it pays the wrong people or nobody. During a pause the silent third earns its subsidy (51-percent.md: "free to hold while silent"); redirecting pool income to the signing keys is the signing bonus's job (8 of 80 points) and to holders is impossible (no mechanism pays holders). Vote-or-burn priced the pause at 3,103 to 6,206 IGN an hour at 34 percent silent and found a deposit worth attacking covers either; LEAVE and weight-gated fork choice close the line. Verdict: never. 0 hours.
|
|
|
|
### 7.15 Proof of latency: rewarding low-latency relays
|
|
|
|
The arXiv search for "proof of latency" this morning returned five unrelated papers and none on relay rewards; FIBRE (2016) relays unpaid. Timing is unverifiable in consensus (section 1.4) and the DAG already pays for latency in blue blocks (under 2 percent red at 1 block/s, run B). A relay reward would need a clock and a Sybil-proof receipt, and it has neither. Verdict: never. 0 hours.
|
|
|
|
---
|
|
|
|
## 8. Verdict table
|
|
|
|
Ranked. At most three "do now" and three "prototype"; the rest "watch" or "never" with the line that killed them. Persona order: cryptographer / consensus engineer / the miner / economist.
|
|
|
|
| Rank | Candidate | Prior art (name, year) | New? | Survives its game (bound) | Hostile review verdict | Hours | First gate | Four verdicts | Recommendation |
|
|
|---|---|---|---|---|---|---|---|---|---|
|
|
| 1 | 6 Phone-verifiable proof in a QR or URL, offline, plus the explorer link | Mina 2021 (approx.), Helios 2022, zkSync block proofs 2023 (approx.) | the offline PoW finality object is new | yes (a forged QR fails; staleness shown by `lock_daa`) | "show the age in big letters": accepted | 8 (+16 rank 19) | phone in airplane mode verifies a printed QR, refuses a one-byte change | do now / do now / prototype / do now | **do now** |
|
|
| 2 | 5 Heat mode in Ember | Heatbit 2022, 21energy (Austria), Qarnot 2010 (approx.) | new only as a chain client feature | yes (a schedule is a schedule; seasonal hash absorbed by the DAA and the 30-day window) | "every miner GUI has a thermostat": accepted | 6 | set temperature held within 1 degree for 4 h on PC 1 while hash follows the duty cycle | do now x4 | **do now** (UK break-even 5.3 p an hour against gas or a heat pump; free against a resistive panel) |
|
|
| 3 | 3 Miners' nodes serve the 786 B proof to phones (Ember line, unpaid) | Portal Network 2021 to 2026 (unrewarded), Helios 2022, Mina snarkers 2021 (approx.) | no | yes (a lie fails verification; eclipse bounded by N of M pins) | "not a service you price": accepted | 4 (+20 frontier 3.8) | a phone on cellular shows "locked, voter set verified" from a miner's node | do now x4 | **do now** |
|
|
| 4 | 7.1 Weight-backed peer directory in the coinbase | DNS seeds 2011, discv5 2019, Heilman 2015 (approx.) | new in form | yes: eclipse at 34 percent of weight 1.8e-4 with 8 peers, 3.2e-8 with 16 (model E) | "a list of rigs weighted by rigs; NAT": partly accepted, the NAT fraction is the measurement | 10 | fresh node with genesis peers only reaches 8 outbound from the directory; 34 percent attacker eclipses under 0.1 percent of 1,000 starts | prototype / prototype / watch / prototype | **prototype** |
|
|
| 5 | 4 Verifiable payout contract for existing pools (SmartPool shape) | SmartPool 2017; Ocean 2023 (approx.) | no | yes (a dropped share is provable from the member's log) | "P2Pool sidechain if you want no operator": accepted as the alternative | 16 | a member proves a dropped share on the fast-time network and is paid; 32 B per round on chain | prototype x4 | **prototype** |
|
|
| 6 | 7.5 Finality as a service for other PoW chains | Komodo dPoW 2018 (approx.), VeriBlock PoP 2019 (approx.), Babylon 2022 | the 90-s proof-carrying anchor is new | yes for Igneum (an anchor is a transaction); the anchored chain inherits Igneum's pauses | "who are the customers": demand is the gate | 16 | one outside testnet refuses a staged deep reorg below an anchored lock for a week | prototype / watch / watch / watch | **prototype** (demand-gated) |
|
|
| 7 | 7.6 Hardware leaderboard on the program corpus | Geekbench 2007, WhatToMine 2018 (approx.); frontier 3.16 | new as a continuous random-kernel benchmark | yes (self-reported rates labelled; the fleet's rows are the reference tier) | none | 8 (+10) | public page with the eleven measured cards as the reference tier | do now x4 | watch (frontier 3.16 is already "do now"; this is its page; the cap of three "do now" is spent) |
|
|
| 8 | 7.3 Public timestamping on the proof chain | OpenTimestamps 2016 (approx.) | the offline-verifiable receipt is new | yes | none | 4 | a timestamp verified offline from a QR | do now x4 | watch until rank 1 lands, then 4 hours |
|
|
| 9 | 7.2 Sign-in with Igneum (delegated weight as a login) | Hashcash 1997, EIP-4361 2021 | new (work-earned, non-transferable weight) | yes if delegated (a vote key online is a key a thief burns) | "miners do not want identities": opt-in | 6 | a page verifies a delegated signature against a node's weight; dust refused | watch / watch / watch / prototype | watch (first user: the rental escrow) |
|
|
| 10 | 7.9 Miner-signed release hash in the coinbase | BIP9 2015; horizon rank 13 | no | yes (a statistic) | fold into rank 13 | 4 | the explorer shows share of weight per release hash | watch / do / watch / watch | watch |
|
|
| 11 | 1.3 and 1.5 Proof of serving or state availability as a reward slice | Filecoin PoSt 2020, Arweave SPoRA 2021 (approx.), PeerDAS 2024 | the miner-key reward is new | no: outsourced in 108 ms; self-answered under class v5 | "pays for what the lottery compels" | 0 (4 for the unpaid RPC) | | never x4 | never: the unpaid RPC (new-pow rank 6) is all that survives |
|
|
| 12 | 2 x of 80 points conditional on serving | as 11 | no | no (same bounds; a second liveness bonus on the signing bonus's event) | "merge or drop" | 0 | | never x4 | never |
|
|
| 13 | 4 In-protocol pool (shares in blocks) | FruitChains 2016, P2Pool 2011, Monero P2Pool 2021, Braidpool (in development) | no | yes on incentives (withholding self-defeating), no on cost: 14.6 to 146 GB a day and 5 to 50 cores per node at 10,000 to 100,000 miners on a 10-s share | "we built a sidechain for this reason" | 0 | | never x4 | never in protocol |
|
|
| 14 | 1.2 Proof of following | Verthash 2021 (approx.), class v5 2026 | in form only | yes, by doing nothing new | "the root already commits to the chain" | 0 | | never x4 | never: the epoch seed plus class v5 is proof of following |
|
|
| 15 | 1.4 Proof of propagation receipts | FIBRE 2016 (unpaid) | no | no (time unverifiable; receipts Sybil-free; 94 to 376 MB a day) | "GHOSTDAG is a proof of propagation" | 0 | | never x4 | never |
|
|
| 16 | 7.10 Energy-price oracle from miners | Chainlink 2017, frontier 3.5 | no | no (noise, or a lever the bid neutralises) | | 2 (Ember telemetry) | | never x4 (in protocol) | never; opt-in statistic |
|
|
| 17 | 7.11 First-block bonus per key | the signing bonus (vote-or-burn) | no | no: a 10 percent miner collects it 2,592 times a window (model F) | "an instamine with extra steps" | 0 | | never x4 | never |
|
|
| 18 | 7.13 Reorg insurance for exchanges | none shipped (approx.) | yes | no (no slashable payer by ruling; the lock is the product) | | 0 | | never x4 | never |
|
|
| 19 | 7.14 Pause insurance from the proving pool | vote-or-burn's pricing | no | no (pays the wrong people) | | 0 | | never x4 | never |
|
|
| 20 | 7.15 Proof of latency | none found (arXiv, 7 Oct 2026) | yes | no (no consensus clock) | | 0 | | never x4 | never |
|
|
| 21 | 7.7 Proof of unique card | frontier 4.3 | no | no (nothing counts cards by design; a chip emulates a fingerprint) | | 0 | | never x4 | never |
|
|
| 22 | 7.8 Proving-only key earning pool income | spec 7.2 | no | dead by the sortition rule; open claims and the pool route exist | | 0 | | never x4 | never |
|
|
| 23 | 7.12 Cross-vendor parity bounty | | | dead by ruling (device bounty) | | 0 | | never x4 | never |
|
|
| 24 | 7.4 Hash-rate futures | Braidpool, NiceHash 2014 (approx.) | no | needs a coin bond: dead in protocol | | 0 | | never (protocol) x4 | never in protocol; a third-party app is the chain's indifference |
|
|
|
|
Three "do now": ranks 1, 2, 3 (34 hours in all, plus the 36 of rank 19 and frontier 3.8 they sit on). Three "prototype": ranks 4, 5, 6 (42 hours). Everything the brief hoped was a protocol invention in sections 1, 2 and 4 is dead on a number this lane ran: 108 ms (the outsourcing fetch), 0.61 to 76.5 GB a day (challenge answers), 14.6 to 146 GB a day and 5 to 50 cores (in-protocol shares).
|
|
|
|
---
|
|
|
|
## 9. The honest answer
|
|
|
|
Igneum's revolution is the combination already built, not any one new item. The pieces that exist in code or on a branch today and that no shipped proof-of-work chain has together: a random-program GPU hash whose dataset is the chain's own state (class v5, hash rate unchanged at 63.08 MH/s, verifier +0.11 to 0.21 ms), miner-only finality by 30 days of blue blocks with no stake (a lock 63 to 93 s after a checkpoint; 51 percent never reaches two thirds while honest miners mine), that finality carried inside the execution proof as 494 bytes a phone verifies (finality-in-proof), a bond for proving jobs made of 30 days of public work and no coin (work-stake: 2,793 IGN at risk for an 8 GB card at 100 GH/s against a 0.0015 IGN coin bond), a tail that keeps a 24-hour attack at about twelve days of emission in every year, and a pool protocol in which the operator holds no key and no vote.
|
|
|
|
This lane tested fourteen candidates for the next thing and found two small ones worth building now (the offline proof in a QR, 8 hours, and heat mode, 6 hours), one Ember line (miners' nodes serve the proof, 4 hours), and three prototypes (a weight-backed peer directory that bounds an eclipse at 1.8e-4 for a 34 percent attacker, a verifiable payout contract for pools, and finality as a service for other chains). Every candidate that would have changed consensus died on a measured number: proof of serving on a 108 ms fetch, in-protocol shares on 14.6 GB a day, propagation receipts on the absence of a clock. The next genuinely new thing is the first offline-verifiable proof-of-work finality object in a user's pocket, and it is packaging on what is already built.
|
|
|
|
---
|
|
|
|
## 10. Three headline findings for the coordinator
|
|
|
|
1. Every "hashing useful to the chain" variant beyond class v5 is dead on one number: a key with no state answers an availability challenge in about 108 ms over a 100 ms link, so any deadline over one block makes the proof "someone served", and the reward slice it would gate (2 to 8 of the 80 points, 17 to 69,120 IGN a day by key size) pays for what the lottery already compels.
|
|
2. An in-protocol pool is FruitChains (2016) and it costs every node 14.6 GB a day and 5 cores at 10,000 miners on a 10-s share (146 GB and 50 cores at 100,000), so the finished form is the shipped pool v0 plus a verifiable payout contract (SmartPool 2017 shape, 16 hours, 32 B per round on chain).
|
|
3. The three things worth doing now total 18 hours and change no consensus rule: an offline-verifiable 786 B finality object in a QR (260 B Groth16 + 494 B public values + 32 B key id, under a version-40 QR's 2,953 B), Ember heat mode (a 300 W card breaks even against a UK gas boiler or COP-3 heat pump at 5.3 p an hour earned, and is free against a resistive heater), and every miner's node serving that proof to phones.
|
|
|
|
---
|
|
|
|
## Sources (accessed 7 October 2026 unless stated)
|
|
|
|
Project files: `docs/analysis/horizon-2026-10.md`; `docs/analysis/horizon/frontier.md`; `docs/analysis/horizon/new-pow.md`; `docs/analysis/class-v5-stored-state.md` (branch class-v5); `docs/analysis/finality-in-proof.md` (branch fin-proof); `docs/analysis/work-stake.md` (branch work-stake); `docs/analysis/tail-emission.md`; `docs/analysis/vote-or-burn.md`; `docs/design/latency-ladder.md`; `docs/analysis/51-percent.md`; `docs/plans/pool.md`; `docs/spec/09-pool-protocol.md`; `docs/spec/10-light-client.md`; `docs/design/phone-app.md`; `docs/bench-log.md` (lines 170, 230, 685, 873 to 877, 1934, 2582 to 2635); `.claude/agents/*.md`. Model: `/private/tmp/claude-501/-Users-joshm/cd75457f-4858-4f86-9634-7481ee056b7b/scratchpad/mission-invent/invent_model.py` and `out.md`.
|
|
|
|
Primary pages fetched (WebFetch; the session's WebSearch budget was spent before this lane started, so every check is a direct fetch of a known primary page):
|
|
|
|
- FruitChains: A Fair Blockchain, Pass and Shi, 2016: https://eprint.iacr.org/2016/916
|
|
- SmartPool: Practical Decentralized Pooled Mining, Luu, Velner, Teutsch, Saxena, 2017: https://eprint.iacr.org/2017/019
|
|
- Monero P2Pool (SChernykh): https://github.com/SChernykh/p2pool
|
|
- Braidpool: https://github.com/braidpool/braidpool
|
|
- EIP-7594 PeerDAS (2024): https://eips.ethereum.org/EIPS/eip-7594
|
|
- Portal Network: https://ethportal.net/
|
|
- FIBRE: https://bitcoinfibre.org/
|
|
- Helios: https://github.com/a16z/helios
|
|
- Heatbit: https://www.heatbit.com/
|
|
- 21energy: https://21energy.com/
|
|
- Filecoin storage mining and WindowPoSt: https://spec.filecoin.io/systems/filecoin_mining/storage_mining/
|
|
- SP1 proof types (Groth16 about 260 B, PLONK about 1 min 30 s longer than compressed): https://docs.succinct.xyz/docs/sp1/generating-proofs/proof-types
|
|
- Ofgem energy price cap unit rates, 1 October to 31 December 2026 (26.32 p electricity, 7.97 p gas, direct debit, national average): https://www.ofgem.gov.uk/your-energy-supply/your-energy-bill/energy-price-cap-unit-rates-and-standing-charges
|
|
- EIA, average residential electricity price, July 2026 (18.31 cents per kWh): https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a
|
|
- Eurostat, electricity price statistics, H2 2025 (EUR 0.2896 per kWh household): https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Electricity_price_statistics
|
|
- Babylon: Bitcoin-Enhanced Proof-of-Stake Security, Tas, Tse, Gai, Kannan, Maddah-Ali, Yu, 2022: https://arxiv.org/abs/2207.08392
|
|
- VeriBlock Proof-of-Proof: https://www.veriblock.org/
|
|
- arXiv search "proof of latency" (no relevant paper): https://arxiv.org/search/?query=%22proof+of+latency%22&searchtype=all
|
|
|
|
Pages that returned 404 this morning, so the item is labelled approximate in the text: Arweave yellow paper and mining guide (SPoRA), vertcoin.org Verthash page, Komodo dPoW academy page, Qarnot's Wikipedia page, Ofgem's cap-levels page (the unit-rates page above answered instead). Figures from memory are labelled approximate where they appear: Heatbit's 2022 launch, Qarnot's 2010 founding and 2013 QRad, Komodo's 2018 dPoW and its 10-minute cadence, VeriBlock's 2019 launch, Verthash's January 2021 activation, Mina's 2021 phone verification, EU and US gas prices, phone-side pairing times, SP1's Groth16 wrap time and RAM, Geekbench and WhatToMine years, the Heilman 2015 eclipse paper's venue.
|