Site builds the engineering log, the FUD ledger and the journey feed from the repository on every deploy
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs
parent
ffa7d5de48
commit
14c6f8318e
7 changed files with 1196 additions and 16 deletions
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
use crate::group::Group;
|
||||
use crate::hash::{bytes_to_int, hash_prime, signed_to_bytes};
|
||||
use rug::ops::{NegAssign, RemRounding};
|
||||
use rug::ops::{DivRounding, NegAssign, RemRounding};
|
||||
use rug::Integer;
|
||||
use std::cmp::Ordering;
|
||||
|
||||
|
|
@ -35,6 +35,8 @@ pub struct ClassGroup {
|
|||
/// Negative discriminant.
|
||||
pub d: Integer,
|
||||
pub d_bits: u32,
|
||||
/// L = floor(|D|^(1/4)), the NUDUPL partial-gcd bound (chiavdf: root(-D, 4)).
|
||||
pub l: Integer,
|
||||
}
|
||||
|
||||
impl ClassGroup {
|
||||
|
|
@ -42,13 +44,14 @@ impl ClassGroup {
|
|||
/// Mirrors chiavdf CreateDiscriminant(seed, length) = -HashPrime(seed, length, {0,1,2,length-1}).
|
||||
pub fn from_seed(seed: &[u8], bits: u32) -> ClassGroup {
|
||||
let p = hash_prime(seed, bits, &[0, 1, 2, bits - 1]);
|
||||
ClassGroup { d: -p, d_bits: bits }
|
||||
Self::from_discriminant(-p)
|
||||
}
|
||||
|
||||
pub fn from_discriminant(d: Integer) -> ClassGroup {
|
||||
assert!(d.cmp0() == Ordering::Less);
|
||||
let d_bits = d.significant_bits();
|
||||
ClassGroup { d, d_bits }
|
||||
let l = Integer::from(d.abs_ref()).root(4);
|
||||
ClassGroup { d, d_bits, l }
|
||||
}
|
||||
|
||||
/// (a, b, c) from a, b with c = (b^2 - D) / 4a, reduced. None if not integral.
|
||||
|
|
@ -184,6 +187,140 @@ impl ClassGroup {
|
|||
self.reduce(f);
|
||||
}
|
||||
|
||||
/// NUDUPL (Shanks; Atkin's variant), ported from chiavdf `qfb_nudupl` in
|
||||
/// vendor/chiavdf/src/nucomp.h (itself from William Hart's FLINT/Antic qfb code).
|
||||
/// The partial extended gcd stops once the remainder drops below L = |D|^(1/4), so the
|
||||
/// intermediate coefficients stay near sqrt(|D|) instead of growing to |D|, and the final
|
||||
/// reduction is one or two steps. Output is reduced.
|
||||
pub fn nudupl(&self, f: &mut Form) {
|
||||
let mut a1 = f.a.clone();
|
||||
let mut c1 = f.c.clone();
|
||||
// s = gcd(|b|, a) with v2 |b| = s (mod a); fix the sign so v2 b = s (mod a).
|
||||
let b_abs = Integer::from(f.b.abs_ref());
|
||||
let (s, mut v2, _) = b_abs.extended_gcd(a1.clone(), Integer::new());
|
||||
if f.b.cmp0() == Ordering::Less {
|
||||
v2.neg_assign();
|
||||
}
|
||||
// k = -(c inv(b)) mod a
|
||||
let mut k = Integer::from(&v2 * &c1);
|
||||
k.neg_assign();
|
||||
if s != 1 {
|
||||
a1 /= &s;
|
||||
c1 *= &s;
|
||||
}
|
||||
let k = k.rem_floor(&a1);
|
||||
if a1 < self.l {
|
||||
let t = Integer::from(&a1 * &k);
|
||||
let new_a = Integer::from(&a1 * &a1);
|
||||
let cb = Integer::from(&t << 1u32) + &f.b;
|
||||
let new_c = (Integer::from(&f.b + &t) * &k + &c1).div_floor(&a1);
|
||||
f.a = new_a;
|
||||
f.b = cb;
|
||||
f.c = new_c;
|
||||
} else {
|
||||
let mut r2 = a1.clone();
|
||||
let mut r1 = k;
|
||||
let (co2, co1) = xgcd_partial(&mut r2, &mut r1, &self.l);
|
||||
// m2 = (b r1 - c1 co1) / a1
|
||||
let mut m2 = Integer::from(&f.b * &r1);
|
||||
m2 -= Integer::from(&c1 * &co1);
|
||||
let m2 = m2.div_exact(&a1);
|
||||
// new_a = r1^2 - co1 m2, negated when co1 >= 0
|
||||
let mut new_a = Integer::from(&r1 * &r1);
|
||||
new_a -= Integer::from(&co1 * &m2);
|
||||
if co1.cmp0() != Ordering::Less {
|
||||
new_a.neg_assign();
|
||||
}
|
||||
// cb = 2 (a1 r1 - new_a co2) / co1 - b, then mod 2 new_a (floor remainder)
|
||||
let mut cb = Integer::from(&a1 * &r1);
|
||||
cb -= Integer::from(&new_a * &co2);
|
||||
cb <<= 1u32;
|
||||
let mut cb = cb.div_exact(&co1);
|
||||
cb -= &f.b;
|
||||
let temp = Integer::from(&new_a << 1u32);
|
||||
let cb = cb.rem_floor(&temp);
|
||||
// new_c = (cb^2 - D) / (4 new_a)
|
||||
let mut new_c = Integer::from(&cb * &cb);
|
||||
new_c -= &self.d;
|
||||
let mut new_c = new_c.div_exact(&new_a);
|
||||
new_c >>= 2u32;
|
||||
if new_a.cmp0() == Ordering::Less {
|
||||
new_a.neg_assign();
|
||||
new_c.neg_assign();
|
||||
}
|
||||
f.a = new_a;
|
||||
f.b = cb;
|
||||
f.c = new_c;
|
||||
}
|
||||
self.reduce(f);
|
||||
}
|
||||
|
||||
/// NUCOMP (Shanks; Atkin's variant), ported from chiavdf `qfb_nucomp` in
|
||||
/// vendor/chiavdf/src/nucomp.h (William Hart, FLINT/Antic). Same idea as NUDUPL for two
|
||||
/// different forms. Output is reduced.
|
||||
pub fn nucomp(&self, f: &Form, g: &Form) -> Form {
|
||||
let (f, g) = if f.a > g.a { (g, f) } else { (f, g) };
|
||||
let mut a1 = f.a.clone();
|
||||
let mut a2 = g.a.clone();
|
||||
let mut c2 = g.c.clone();
|
||||
let ss = Integer::from(&f.b + &g.b) >> 1u32;
|
||||
let m = Integer::from(&f.b - &g.b) >> 1u32;
|
||||
let t = Integer::from(&a2).rem_floor(&a1);
|
||||
let (sp, v1) = if t.cmp0() == Ordering::Equal {
|
||||
(a1.clone(), Integer::new())
|
||||
} else {
|
||||
let (sp, v1, _) = t.extended_gcd(a1.clone(), Integer::new());
|
||||
(sp, v1)
|
||||
};
|
||||
let mut k = Integer::from(&m * &v1).rem_floor(&a1);
|
||||
if sp != 1 {
|
||||
// s = v2 ss + u2 sp
|
||||
let (s, v2, u2) = ss.clone().extended_gcd(sp.clone(), Integer::new());
|
||||
k *= &u2;
|
||||
k -= Integer::from(&v2 * &c2);
|
||||
if s != 1 {
|
||||
a1 = a1.div_exact(&s);
|
||||
a2 = a2.div_exact(&s);
|
||||
c2 *= &s;
|
||||
}
|
||||
k = k.rem_floor(&a1);
|
||||
}
|
||||
let mut out = if a1 < self.l {
|
||||
let t = Integer::from(&a2 * &k);
|
||||
let ca = Integer::from(&a2 * &a1);
|
||||
let cb = Integer::from(&t << 1u32) + &g.b;
|
||||
let cc = (Integer::from(&g.b + &t) * &k + &c2).div_exact(&a1);
|
||||
Form { a: ca, b: cb, c: cc }
|
||||
} else {
|
||||
let mut r2 = a1.clone();
|
||||
let mut r1 = k;
|
||||
let (co2, co1) = xgcd_partial(&mut r2, &mut r1, &self.l);
|
||||
let t = Integer::from(&a2 * &r1);
|
||||
let m1 = (Integer::from(&m * &co1) + &t).div_exact(&a1);
|
||||
let m2 = (Integer::from(&ss * &r1) - Integer::from(&c2 * &co1)).div_exact(&a1);
|
||||
let r1m1 = Integer::from(&r1 * &m1);
|
||||
let co1m2 = Integer::from(&co1 * &m2);
|
||||
let mut ca = if co1.cmp0() == Ordering::Less { r1m1 - co1m2 } else { co1m2 - r1m1 };
|
||||
let mut cb = Integer::from(&t - Integer::from(&ca * &co2));
|
||||
cb <<= 1u32;
|
||||
let mut cb = cb.div_exact(&co1);
|
||||
cb -= &g.b;
|
||||
let temp = Integer::from(&ca << 1u32);
|
||||
let cb = cb.rem_floor(&temp);
|
||||
let mut cc = Integer::from(&cb * &cb);
|
||||
cc -= &self.d;
|
||||
let mut cc = cc.div_exact(&ca);
|
||||
cc >>= 2u32;
|
||||
if ca.cmp0() == Ordering::Less {
|
||||
ca.neg_assign();
|
||||
cc.neg_assign();
|
||||
}
|
||||
Form { a: ca, b: cb, c: cc }
|
||||
};
|
||||
self.reduce(&mut out);
|
||||
out
|
||||
}
|
||||
|
||||
fn coeff_width(&self) -> usize {
|
||||
// Reduced forms have a, |b| <= sqrt(|D|/3) < 2^(d_bits/2 + 1). Keep a full d_bits
|
||||
// width so unreduced but valid forms still round-trip during tests.
|
||||
|
|
@ -191,6 +328,92 @@ impl ClassGroup {
|
|||
}
|
||||
}
|
||||
|
||||
/// Partial extended Euclid, plain-division form. Reference for the test suite only.
|
||||
/// On return co2 r1 - co1 r2 = +-(original r2), and r1 <= L.
|
||||
pub fn xgcd_partial_simple(r2: &mut Integer, r1: &mut Integer, l: &Integer) -> (Integer, Integer) {
|
||||
let mut co2 = Integer::new();
|
||||
let mut co1 = Integer::from(-1);
|
||||
while r1.cmp0() != Ordering::Equal && *r1 > *l {
|
||||
let (q, r) = r2.clone().div_rem_floor(r1.clone());
|
||||
*r2 = std::mem::replace(r1, r);
|
||||
co2 -= Integer::from(&co1 * &q);
|
||||
std::mem::swap(&mut co2, &mut co1);
|
||||
}
|
||||
(co2, co1)
|
||||
}
|
||||
|
||||
/// Top 63 bits of a non-negative integer, from bit `shift` upward.
|
||||
fn top_word(x: &Integer, shift: u32) -> i64 {
|
||||
if shift == 0 {
|
||||
return x.to_u64_wrapping() as i64;
|
||||
}
|
||||
Integer::from(x >> shift).to_u64_wrapping() as i64
|
||||
}
|
||||
|
||||
/// Partial extended Euclid with Lehmer acceleration, ported from chiavdf's
|
||||
/// `mpz_xgcd_partial` (vendor/chiavdf/src/xgcd_partial.c, William Hart, FLINT). Each outer
|
||||
/// round runs as many Euclid steps as the top 63 bits of r2, r1 allow in machine words
|
||||
/// (Collins/Jebelean exit tests), then applies the 2x2 cofactor matrix to the big numbers.
|
||||
/// Produces the same (r2, r1, co2, co1) as `xgcd_partial_simple`.
|
||||
pub fn xgcd_partial(r2: &mut Integer, r1: &mut Integer, l: &Integer) -> (Integer, Integer) {
|
||||
let mut co2 = Integer::new();
|
||||
let mut co1 = Integer::from(-1);
|
||||
while r1.cmp0() != Ordering::Equal && *r1 > *l {
|
||||
let bits2 = r2.significant_bits() as i64;
|
||||
let bits1 = r1.significant_bits() as i64;
|
||||
let bits = (bits2.max(bits1) - 64 + 1).max(0) as u32;
|
||||
let mut rr2 = top_word(r2, bits);
|
||||
let mut rr1 = top_word(r1, bits);
|
||||
let bb = top_word(l, bits);
|
||||
let (mut aa2, mut aa1, mut bb2, mut bb1): (i64, i64, i64, i64) = (0, 1, 1, 0);
|
||||
let mut i: u32 = 0;
|
||||
while rr1 != 0 && rr1 > bb {
|
||||
let qq = rr2 / rr1;
|
||||
let t1 = rr2 - qq * rr1;
|
||||
let t2 = aa2 - qq * aa1;
|
||||
let t3 = bb2 - qq * bb1;
|
||||
if i & 1 == 1 {
|
||||
if t1 < -t3 || rr1 - t1 < t2 - aa1 {
|
||||
break;
|
||||
}
|
||||
} else if t1 < -t2 || rr1 - t1 < t3 - bb1 {
|
||||
break;
|
||||
}
|
||||
rr2 = rr1;
|
||||
rr1 = t1;
|
||||
aa2 = aa1;
|
||||
aa1 = t2;
|
||||
bb2 = bb1;
|
||||
bb1 = t3;
|
||||
i += 1;
|
||||
}
|
||||
if i == 0 {
|
||||
let (q, r) = r2.clone().div_rem_floor(r1.clone());
|
||||
*r2 = std::mem::replace(r1, r);
|
||||
co2 -= Integer::from(&co1 * &q);
|
||||
std::mem::swap(&mut co2, &mut co1);
|
||||
} else {
|
||||
let r = Integer::from(&*r2 * bb2) + Integer::from(&*r1 * aa2);
|
||||
let new_r1 = Integer::from(&*r1 * aa1) + Integer::from(&*r2 * bb1);
|
||||
*r2 = r;
|
||||
*r1 = new_r1;
|
||||
let r = Integer::from(&co2 * bb2) + Integer::from(&co1 * aa2);
|
||||
let new_co1 = Integer::from(&co1 * aa1) + Integer::from(&co2 * bb1);
|
||||
co2 = r;
|
||||
co1 = new_co1;
|
||||
if r1.cmp0() == Ordering::Less {
|
||||
co1.neg_assign();
|
||||
r1.neg_assign();
|
||||
}
|
||||
if r2.cmp0() == Ordering::Less {
|
||||
co2.neg_assign();
|
||||
r2.neg_assign();
|
||||
}
|
||||
}
|
||||
}
|
||||
(co2, co1)
|
||||
}
|
||||
|
||||
impl Group for ClassGroup {
|
||||
type Elem = Form;
|
||||
|
||||
|
|
@ -203,11 +426,11 @@ impl Group for ClassGroup {
|
|||
}
|
||||
|
||||
fn square(&self, x: &mut Form) {
|
||||
self.square_form(x);
|
||||
self.nudupl(x);
|
||||
}
|
||||
|
||||
fn mul(&self, a: &Form, b: &Form) -> Form {
|
||||
self.compose(a, b)
|
||||
self.nucomp(a, b)
|
||||
}
|
||||
|
||||
/// a and b, each as sign byte + fixed-width magnitude. c is recomputed.
|
||||
|
|
|
|||
|
|
@ -102,6 +102,47 @@ fn selftest() {
|
|||
assert_eq!(g.deserialize(&g.serialize(a)).unwrap(), *a);
|
||||
}
|
||||
println!("identity, inverse, commutativity, {} associativity triples, square==compose, exponent laws, serialization: PASS", checks);
|
||||
// Lehmer partial xgcd against the plain-division version on random 512-bit pairs.
|
||||
for i in 0..2000u32 {
|
||||
let a = Integer::from_digits(&[sha256(&[b"xa", &i.to_be_bytes()]), sha256(&[b"xb", &i.to_be_bytes()])].concat(), rug::integer::Order::MsfBe);
|
||||
let b = Integer::from_digits(&[sha256(&[b"xc", &i.to_be_bytes()]), sha256(&[b"xd", &i.to_be_bytes()])].concat(), rug::integer::Order::MsfBe);
|
||||
let (hi, lo) = if a > b { (a, b) } else { (b, a) };
|
||||
let (mut r2a, mut r1a) = (hi.clone(), lo.clone());
|
||||
let (mut r2b, mut r1b) = (hi.clone(), lo.clone());
|
||||
let (c2a, c1a) = classgroup::xgcd_partial_simple(&mut r2a, &mut r1a, &g.l);
|
||||
let (c2b, c1b) = classgroup::xgcd_partial(&mut r2b, &mut r1b, &g.l);
|
||||
assert!((r2a, r1a, c2a, c1a) == (r2b, r1b, c2b, c1b), "lehmer xgcd_partial differs at {}", i);
|
||||
}
|
||||
println!("2000 random pairs: Lehmer partial xgcd == plain partial xgcd: PASS");
|
||||
// NUDUPL against the plain duplication formula and against compose, along a long walk.
|
||||
let mut walk = gen.clone();
|
||||
for i in 0..3000 {
|
||||
let mut a = walk.clone();
|
||||
g.square_form(&mut a);
|
||||
let b = g.compose(&walk, &walk);
|
||||
g.nudupl(&mut walk);
|
||||
assert_eq!(walk, a, "nudupl != simple square at step {}", i);
|
||||
assert_eq!(walk, b, "nudupl != compose at step {}", i);
|
||||
assert!(g.is_valid(&walk));
|
||||
}
|
||||
println!("3000 successive squarings: NUDUPL == plain duplication == compose(f, f), all outputs reduced with discriminant D: PASS");
|
||||
// NUCOMP against Cohen 5.4.7 on pairs drawn from two independent walks, plus identity
|
||||
// and inverse cases, plus near-equal pairs (a1 == a2 branch).
|
||||
let mut p = gen.clone();
|
||||
let mut q = g.pow(&gen, &Integer::from(7919u32));
|
||||
let mut nucomp_checks = 0;
|
||||
for i in 0..2000 {
|
||||
g.nudupl(&mut p);
|
||||
q = g.nucomp(&q, &gen);
|
||||
let want = g.compose(&p, &q);
|
||||
assert_eq!(g.nucomp(&p, &q), want, "nucomp != compose at {}", i);
|
||||
assert_eq!(g.nucomp(&q, &p), want, "nucomp order at {}", i);
|
||||
assert_eq!(g.nucomp(&p, &p), g.compose(&p, &p));
|
||||
assert_eq!(g.nucomp(&p, &g.inverse(&p)), id);
|
||||
assert_eq!(g.nucomp(&p, &id), p);
|
||||
nucomp_checks += 5;
|
||||
}
|
||||
println!("{} NUCOMP cases (random pairs, both orders, f*f, f*f^-1, f*1) agree with Cohen 5.4.7: PASS", nucomp_checks);
|
||||
|
||||
println!("== RSA stand-in group ==");
|
||||
let r = RsaGroup::from_public_seed("selftest");
|
||||
|
|
|
|||
81
site/bench.html
Normal file
81
site/bench.html
Normal file
|
|
@ -0,0 +1,81 @@
|
|||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
|
||||
<title>Engineering log</title>
|
||||
<meta name="description" content="Every Igneum benchmark and test, with the commands that produced it.">
|
||||
<meta name="theme-color" content="#0C0C0E">
|
||||
<link rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'%3E%3Cpolygon points='50,4 74,34 67,58 80,54 61,96 39,96 20,54 33,58 26,34' fill='%23F2541B'/%3E%3C/svg%3E">
|
||||
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Unbounded:wght@500;700;900&family=IBM+Plex+Sans:wght@400;500;600&family=IBM+Plex+Mono:wght@400;500&display=swap">
|
||||
<style>
|
||||
:root{--obsidian:#0C0C0E;--graphite:#16161A;--line:#2A2A30;--ember:#F2541B;--molten:#FFB35C;--bone:#F4F1EC;--ash:#9A9A9E;--ink-2:#C9C7C2}
|
||||
*{box-sizing:border-box}body{margin:0;background:var(--obsidian);color:var(--bone);font-family:'IBM Plex Sans',system-ui,sans-serif;font-size:16px;line-height:1.6;padding-inline:clamp(16px,4vw,32px)}
|
||||
a{color:var(--ember);text-decoration:none}a:hover{text-decoration:underline}
|
||||
.wrap{max-width:1180px;margin:0 auto}
|
||||
header{display:flex;flex-wrap:wrap;justify-content:space-between;align-items:center;gap:16px;padding-block:18px;border-bottom:1px solid var(--line)}
|
||||
.brand{display:flex;align-items:center;gap:10px;color:var(--bone)}.brand b{font-family:'Unbounded',sans-serif;font-weight:900;letter-spacing:.06em;font-size:18px}
|
||||
header nav{display:flex;flex-wrap:wrap;gap:18px;font-size:14px}header nav a{color:var(--ink-2)}
|
||||
h1{font-family:'Unbounded',sans-serif;font-weight:900;font-size:clamp(28px,5vw,48px);line-height:1.05;margin:36px 0 10px}
|
||||
.note{color:var(--ash);font-size:15px;max-width:72ch;margin-bottom:28px}
|
||||
.layout{display:grid;grid-template-columns:minmax(0,1fr);gap:32px;padding-bottom:80px}
|
||||
@media(min-width:960px){.layout{grid-template-columns:240px minmax(0,1fr);gap:56px}}
|
||||
.toc{align-self:start;font-size:14px}@media(min-width:960px){.toc{position:sticky;top:24px}}
|
||||
.toc ol{list-style:none;margin:0;padding:0;display:flex;flex-direction:column;gap:2px}.toc a{display:block;padding:6px 10px;border-radius:8px;color:var(--ink-2)}.toc a:hover{background:var(--graphite);text-decoration:none;color:var(--bone)}
|
||||
article{max-width:78ch;min-width:0}
|
||||
article h2{font-family:'Unbounded',sans-serif;font-weight:700;font-size:clamp(20px,2.6vw,26px);margin:44px 0 12px;padding-top:24px;border-top:1px solid var(--line)}
|
||||
article h3{font-family:'Unbounded',sans-serif;font-weight:500;font-size:16px;margin:26px 0 8px}
|
||||
article h4{font-size:15px;margin:20px 0 6px;color:var(--molten)}
|
||||
article p{margin:0 0 14px}article ul,article ol{margin:0 0 14px;padding-left:22px}article li{margin-bottom:6px}
|
||||
code{font-family:'IBM Plex Mono',monospace;font-size:.92em;background:var(--graphite);padding:1px 5px;border-radius:4px}
|
||||
pre{margin:0 0 16px;padding:14px 16px;background:var(--graphite);border-radius:12px;font-family:'IBM Plex Mono',monospace;font-size:13px;line-height:1.55;overflow-x:auto}
|
||||
.tbl{overflow-x:auto;margin:14px 0 20px;border:1px solid var(--line);border-radius:12px;background:var(--graphite)}
|
||||
table{border-collapse:collapse;width:100%;min-width:560px;font-size:14px}th,td{padding:10px 12px;text-align:left;vertical-align:top;border-bottom:1px solid var(--line)}
|
||||
th{font-family:'IBM Plex Mono',monospace;font-size:11px;letter-spacing:.12em;text-transform:uppercase;color:var(--ash);font-weight:500;background:var(--obsidian)}tr:last-child td{border-bottom:0}
|
||||
footer{border-top:1px solid var(--line);padding-block:24px 48px;font-size:13px;color:var(--ash)}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="wrap">
|
||||
<header><a class="brand" href="/"><svg viewBox="0 0 100 100" width="26" height="26" aria-hidden="true"><polygon points="50,4 74,34 67,58 80,54 61,96 39,96 20,54 33,58 26,34" fill="#F2541B"></polygon><polygon points="50,42 59,58 50,82 41,58" fill="#0C0C0E"></polygon></svg><b>IGNEUM</b></a><nav><a href="/">Home</a><a href="/litepaper">Litepaper</a><a href="/bench">Engineering log</a><a href="/ledger">FUD ledger</a><a href="https://github.com/[second-owner-login]/igneum" rel="noopener">GitHub</a></nav></header>
|
||||
<h1>Engineering log</h1>
|
||||
<p class="note">Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.</p>
|
||||
<div class="layout">
|
||||
<nav class="toc" aria-label="Contents"><ol><li><a href="#2026-10-03-proto-metal-igneum-bench-first-run">2026-10-03 proto-metal / igneum-bench, first run</a></li><li><a href="#2026-10-03-proto-cuda-program-pack-export-mac-side-only-rtx-5090-run-pending">2026-10-03 proto-cuda / program pack export (Mac side only; RTX 5090 run pending)</a></li><li><a href="#2026-10-03-sim-finality-sim-py-sustained-mining-finality-vote-weight-model-not-hardware">2026-10-03 sim/finality_sim.py, sustained-mining finality vote weight (model, not hardware)</a></li><li><a href="#2026-10-03-proto-metal-hardening-tests-correctness-and-soundness-of-the-lottery-hash-metal-only">2026-10-03 proto-metal hardening tests (correctness and soundness of the lottery hash, Metal only)</a></li><li><a href="#3-october-2026-rtx-5090-first-run-[user]-s-pc-windows-cuda-12-8-runtime-driver-13-4-visual-studio-2026-with-the-14-30-toolset-selected-via-vcvarsall-vcvars-ver-14-30">3 October 2026, RTX 5090 first run (the project lead's PC, Windows, CUDA 12.8 runtime, driver 13.4, Visual Studio 2026 with the 14.30 toolset selected via vcvarsall -vcvars_ver=14.30)</a></li><li><a href="#2026-10-03-sim-finality-v2-py-finality-rule-v2-with-latency-partitions-and-eclipses-model-not-hardware">2026-10-03 sim/finality_v2.py, finality rule V2 with latency, partitions and eclipses (model, not hardware)</a></li><li><a href="#2026-10-03-proto-metal-memory-hard-dataset-cache-8-dependent-reads-metal-only-cuda-pack-emulated">2026-10-03 proto-metal memory-hard dataset (cache + 8 dependent reads), Metal only; CUDA pack emulated</a></li><li><a href="#2026-10-03-rusty-kaspa-base-build-and-3-node-devnet-on-the-mac-consensus-engineer-pre-fork-proof">2026-10-03 rusty-kaspa base build and 3-node devnet on the Mac (consensus-engineer, pre-fork proof)</a></li><li><a href="#3-october-2026-rtx-5090-memory-hard-dataset-pack-igneum-genesis-mh">3 October 2026, RTX 5090, memory-hard dataset (pack igneum-genesis-mh)</a></li></ol></nav>
|
||||
<article><h1 id="igneum-bench-log">Igneum bench log</h1>
|
||||
<p>Append-only. Every number here was measured on the machine named, on the date given.</p>
|
||||
<h2 id="2026-10-03-proto-metal-igneum-bench-first-run">2026-10-03 proto-metal / igneum-bench, first run</h2>
|
||||
<p>Machine: Apple M5 Max, 40 GPU cores, 64 GB unified memory, macOS Darwin 25.6.0, Swift 5.8.1, Metal 4. Build: <code>swiftc -O -o igneum-bench main.swift -framework Metal</code>. Source: <code>proto-metal/main.swift</code>. Setup: 1 GiB dataset (2^28 uint32), 64 instructions x 8 iterations, threadgroup 32 (threadExecutionWidth 32), 4 timed batches x 2^22 nonces after one warm-up batch. Verification: 3 warps per program, CPU interpreter vs GPU.</p>
|
||||
<div class="tbl"><table><thead><tr><th>Seed</th><th>Loads/hash</th><th>Compile ms</th><th>Mhash/s</th><th>GB/s useful</th><th>CPU verify ms/warp</th><th>Verify</th></tr></thead><tbody><tr><td>igneum-genesis</td><td>104</td><td>49.6 (cold)</td><td>45.2</td><td>18.8</td><td>0.015</td><td>PASS</td></tr><tr><td>igneum-genesis/epoch1</td><td>104</td><td>20.3</td><td>48.4</td><td>20.1</td><td>0.019</td><td>PASS</td></tr><tr><td>igneum-second-seed</td><td>104</td><td>46.6 (cold)</td><td>35.5</td><td>14.8</td><td>0.016</td><td>PASS</td></tr><tr><td>igneum-second-seed/epoch1</td><td>144</td><td>18.7</td><td>35.4</td><td>20.4</td><td>0.017</td><td>PASS</td></tr><tr><td>igneum-hourly</td><td>128</td><td>52.0 (cold)</td><td>36.6</td><td>18.7</td><td>0.021</td><td>PASS</td></tr><tr><td>igneum-hourly/epoch1</td><td>128</td><td>21.6</td><td>37.5</td><td>19.2</td><td>0.017</td><td>PASS</td></tr><tr><td>igneum-hourly/epoch2</td><td>120</td><td>23.7</td><td>36.6</td><td>17.6</td><td>0.016</td><td>PASS</td></tr></tbody></table></div>
|
||||
<p>Dataset size sweep (seed igneum-genesis): 4 MiB 569 Mhash/s, 64 MiB 183, 256 MiB 94, 512 MiB 69, 1 GiB 44. Dataset fill 1 GiB: 2.34 ms GPU time (427 GB/s) warm, 5.57 ms on first run of a process. Result: 21 warps, 672 hashes, zero mismatches. OVERALL PASS. Reading: memory bound at 1 GiB (12.8x drop from cache-resident), limited by random access rather than bandwidth, CPU verify roughly 250x under the 10 ms gate with a cheap dataset element. Apple silicon only. Details in <code>proto-metal/README.md</code>.</p>
|
||||
<h2 id="2026-10-03-proto-cuda-program-pack-export-mac-side-only-rtx-5090-run-pending">2026-10-03 proto-cuda / program pack export (Mac side only; RTX 5090 run pending)</h2>
|
||||
<p>Machine: the same Apple M5 Max. No CUDA toolchain exists on it, so nothing below is an NVIDIA measurement. Added <code>--export-pack <dir></code> to <code>proto-metal/main.swift</code>. It writes, per seed, the CUDA kernel (<code>kernel.cu</code>), C headers (<code>program.h</code>, <code>vectors.h</code>), JSON twins, and the Metal source, into <code>proto-cuda/packs/<seed>/</code>. Vectors: 3 warps (base nonces 0, 4096, 1000000), 96 x 64-bit outputs from the CPU interpreter, plus dataset words 0..15 and word [MASK]. The exporter runs the Metal kernel for the same warps and refuses to write unless all 96 match.</p>
|
||||
<div class="tbl"><table><thead><tr><th>Pack</th><th>Loads/hash</th><th>Op mix</th><th>CPU interpreter vs Metal GPU (3 warps)</th><th>CUDA text in CPU emulation (clang, 32 threads/warp)</th></tr></thead><tbody><tr><td>igneum-genesis</td><td>104</td><td>load=13 xor=13 sub=7 shfl=6 add=5 mulhi=5 mad=4 rotr=4 mul=3 rotl=3 or=1</td><td>PASS 3/3</td><td>PASS: dataset self-test, 3/3 warps standalone, warps 0 and 4096 in batch at 1 and 2 warps/block</td></tr><tr><td>igneum-hourly</td><td>128</td><td>load=16 add=8 xor=7 mad=5 mul=5 mulhi=5 shfl=5 rotl=4 or=3 rotr=3 sub=3</td><td>PASS 3/3</td><td>PASS: dataset self-test, 3/3 warps standalone, warps 0 and 4096 in batch at 1 warp/block</td></tr></tbody></table></div>
|
||||
<p>Sweep sizes 4, 64, 256, 512 MiB in the emulation: dataset self-test PASS at each (vectors only apply at 1 GiB). The regular Metal bench was re-run after the change: igneum-genesis 44.8 Mhash/s and igneum-hourly 36.3 Mhash/s at 1 GiB with 2 x 2^20 batches, PASS 3/3 warps each (consistent with the first-run table above, not a new figure). Harness: <code>proto-cuda/host.cu</code>, <code>build.sh</code>, <code>build.bat</code>, <code>README.md</code>, <code>CHECKLIST.md</code>, <code>emu/</code>. Pending: build and run on the project lead's RTX 5090 (CUDA 12.8 or newer, <code>-arch=sm_120</code>). No NVIDIA hash rate exists yet. Emulation rates are not recorded because they measure the Mac's CPU, not a GPU.</p>
|
||||
<h2 id="2026-10-03-sim-finality-sim-py-sustained-mining-finality-vote-weight-model-not-hardware">2026-10-03 sim/finality_sim.py, sustained-mining finality vote weight (model, not hardware)</h2>
|
||||
<p>Model: 1 day steps, 86,400 Poisson blocks/day, 1,000 Pareto honest keys (top key 17%), perfect retarget, every block blue, no latency, no VRF noise. Seed 7, seed 11 agrees. Rule: weight = 30-day sum of counted blocks, counted = min(actual, 2 x yesterday + f). Lock at 2/3 of total. Floors f in {1, 10, 100, 1000}. A: weight tracks hashrate at steady state (corr 1.00000); full weight from zero history on day 41 (f=1) to 32 (f=1000). B: 60% renter on one key takes 59.9% of rewards on day 1, crosses 1/3 of weight on day 20 to 26, 50% on day 27 to 34, never 2/3. 75% renter reaches 2/3 on day 29 to 34, day 27 with the cap removed. C: splitting defeats the cap. 10,000 fresh keys at f=1 move the 50% crossing from day 34 to 27 (no-cap figure 26); at f=10 they match no-cap exactly. The 30-day trickle buys 2 more days for 11.6% of the network. D: honest doubling is under-weighted 28 to 31 days; old miners lock alone for 20 to 23 days. E: 30% churn leaves 71% live, lock never lost. Threshold is 1/3: 35% stalls 1 day, 50% stalls 10 to 11 days. Active-24h total removes every stall. F: 51% patient owner holds 51.0% weight from day 45, vetoes from day 7 to 20, never locks alone. 67% owner locks alone from day 34 to 44. Recommend: f=1, cap 2x, window 30 (the window is the defence, the cap is worth 1 to 8 days), total = all keys with weight in the window. Details in sim/results.md.</p>
|
||||
<h2 id="2026-10-03-proto-metal-hardening-tests-correctness-and-soundness-of-the-lottery-hash-metal-only">2026-10-03 proto-metal hardening tests (correctness and soundness of the lottery hash, Metal only)</h2>
|
||||
<p>Machine: the same Apple M5 Max. Added <code>--fuzz</code>, <code>--edge</code>, <code>--stats</code>, <code>--determinism</code>, <code>--memcheck</code>, <code>--inline-dataset</code> to <code>proto-metal/main.swift</code>. Full tables and commands in <code>proto-metal/TESTS.md</code>. Fuzz: 10,200 random programs (200 + 10,000, cold compiles 13.6 to 48.5 ms), 4 random full-range warps each, dataset drawn from 64 MiB / 256 MiB / 1 GiB: 40,800 warps, 1,305,600 hashes, 0 mismatches, 0 compile failures, 0 static mask failures, generator contract (rotl 1..31, mask in {1,2,4,8,16}, src != dst) held on every instruction. 196 s for the 10,000 run. Edge: 14 hand-built cases (rotr by register 0 / 32 / -32 / 31 / 63, rotl 1 and 31, mulhi max operands, shfl masks 1..16, loads at index 0 and MASK via in-range and out-of-range registers, add/sub/mul/mad wraparound, zero loads, 64 loads) with operand values proven by a traced interpreter: 14/14 PASS, 128/128 lanes each. rotl by 0 (never generated) agreed too, recorded as informational only. Stats (3 seeds, 2^20 nonces each): bit frequency max deviation 2.90 sigma over 192 bit positions; avalanche 16,000 flips mean 31.99 to 32.04 (expect 32), std 3.98 to 4.01 (expect 4), every output bit flips with probability 0.490 to 0.508; chi-square on four 16-bit windows all within 2.3 sigma; 0 duplicates. Looks uniform. Not a security proof. Determinism: 5 runs and 3 compiles (one forced cold, 30 ms) of 2^20 hashes gave fingerprint 933787e8cfefccb7 every time; dataset fill deterministic (0b1a77899ee60493 twice) and 4,096 sampled words incl. 0 and MASK match the CPU closed form. Memcheck: every <code>dataset[</code> in the MSL is <code>dataset[rN & MASK]</code> (13/13 at 3 sizes), CUDA twin 13/13 plus one guarded fill write; 4 MiB run with nonces up to 0xffffffff completed and 4 wrapping warps matched the CPU; 416/416 load indices exceeded MASK before masking. Bench re-run after the changes: igneum-genesis 44.56 Mhash/s, epoch1 47.74 Mhash/s at 1 GiB, PASS 3/3 warps each (within 2 percent of the first-run table). <code>--export-pack igneum-genesis</code> re-run is byte-identical to the existing pack. SHORTCUT MEASURED: <code>--inline-dataset</code> replaces every load with the six-op closed form ds_elem and never reads memory: 4,888 Mhash/s wall (6,274 GPU time) vs 44.6 honest at 1 GiB, about 110x, and about 9x the cache-resident honest rate. With a closed-form dataset the hash is not memory-hard; an expensive dataset derivation is required, not optional. Not demonstrated: cryptographic strength, weak-program frequency and rejection, NVIDIA/AMD bit-exactness (CUDA run still pending), CPU verify gate with an expensive dataset element. Next three tests for the cryptographer are listed in TESTS.md section 8.</p>
|
||||
<h2 id="3-october-2026-rtx-5090-first-run-[user]-s-pc-windows-cuda-12-8-runtime-driver-13-4-visual-studio-2026-with-the-14-30-toolset-selected-via-vcvarsall-vcvars-ver-14-30">3 October 2026, RTX 5090 first run (the project lead's PC, Windows, CUDA 12.8 runtime, driver 13.4, Visual Studio 2026 with the 14.30 toolset selected via vcvarsall -vcvars_ver=14.30)</h2>
|
||||
<p>Pack igneum-genesis, dataset 1024 MiB, 5 batches x 2^24 hashes, 1 warp per block.</p>
|
||||
<div class="tbl"><table><thead><tr><th>Card</th><th>Mhash/s at 1 GiB</th><th>GB/s useful</th><th>random loads/s</th><th>dataset fill</th><th>vectors</th></tr></thead><tbody><tr><td>NVIDIA RTX 5090 (170 SMs, 32 GB)</td><td>228.1</td><td>94.9</td><td>23.7 G</td><td>0.66 ms, 1638 GB/s</td><td>96/96 PASS, standalone and in batch</td></tr><tr><td>Apple M5 Max (40 GPU cores, same program, same day)</td><td>45.2</td><td>18.8</td><td>4.6 G</td><td>2.34 ms, 427 GB/s</td><td>96/96 PASS</td></tr></tbody></table></div>
|
||||
<p>Result: the same hourly program, generated on the Mac, compiled by Apple's Metal and NVIDIA's CUDA, produced identical hashes on both vendors. Vendor independence of the lottery program is demonstrated for one program; igneum-hourly and the dataset sweep are the next runs. The ratio 5090 to M5 Max is about 5x on hashes and on random loads per second, approximate, consistent with a memory-bound program (random-access bound, not bandwidth bound: the 5090 writes the dataset at 1638 GB/s but hashes at 95 GB/s of useful 4-byte loads). Caveat unchanged: the prototype dataset is closed-form and not yet memory-hard (see TESTS.md), so these are prototype numbers, not mining numbers.</p>
|
||||
<p>Build note for Windows: CUDA 12.8 crashes (cudafe++ access violation) under Visual Studio 2026's 14.51 toolset even with -allow-unsupported-compiler. Fix: install the MSVC v143 (14.30) component and open the environment with <code>"C:\Program Files\Microsoft Visual Studio\18\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 -vcvars_ver=14.30</code>, then build normally.</p>
|
||||
<h3 id="rtx-5090-dataset-sweep-and-second-program-same-session">RTX 5090, dataset sweep and second program (same session)</h3>
|
||||
<div class="tbl"><table><thead><tr><th>dataset MiB</th><th>Mhash/s</th><th>GB/s useful</th><th>random loads/s (G)</th></tr></thead><tbody><tr><td>4</td><td>1339.8</td><td>557</td><td>139.3</td></tr><tr><td>64</td><td>1352.7</td><td>563</td><td>140.7</td></tr><tr><td>256</td><td>269.8</td><td>112</td><td>28.1</td></tr><tr><td>512</td><td>241.8</td><td>101</td><td>25.2</td></tr><tr><td>1024</td><td>228.7</td><td>95</td><td>23.8</td></tr></tbody></table></div>
|
||||
<p>Second program igneum-hourly (128 loads per hash): 96/96 vectors PASS, 185.3 Mhash/s at 1 GiB, 23.7 G random loads/s.</p>
|
||||
<p>Reading: the 5090 carries 96 MiB of L2. At 4 and 64 MiB the dataset sits inside it and the program runs about 5.8x faster than at 1 GiB. Past the L2 the rate settles at about 23.7 G random loads/s for both programs regardless of loads per hash (104 vs 128 loads gives 228 vs 185 Mhash/s, proportional), so the program is random-access bound once the dataset exceeds on-chip cache. Each 4-byte random load moves a 32-byte sector, so DRAM traffic is roughly 760 GB/s, approximate, against a quoted peak near 1.8 TB/s for this card. Design consequence: the dataset must stay well above any plausible on-chip cache, which the 2 GB genesis size and the growth schedule provide; a chip would need gigabytes of on-chip memory to escape the random-access limit. Still prototype numbers: dataset derivation remains closed-form until the 256 MB cache construction lands.</p>
|
||||
<h2 id="2026-10-03-sim-finality-v2-py-finality-rule-v2-with-latency-partitions-and-eclipses-model-not-hardware">2026-10-03 sim/finality_v2.py, finality rule V2 with latency, partitions and eclipses (model, not hardware)</h2>
|
||||
<p>Model: 30-s slots, Poisson(30) blocks/slot, 1,000 Pareto honest keys in 3 regions (45/35/20), 2-s inter-region delay (0.5 and 5 swept), uptime 97% (99.5% for pools over 1%), warm 30-day start for B to G. Seed 7, seed 11 agrees on B and E. Run time 5 min. Details in sim/results_v2.md. Rule: weight = flat 30-day blue blocks, dust 100, checkpoint per 30 blocks, lock at 2/3 of ACTIVE (participation over 240 checkpoints) vs TOTAL weight. A: weight = hashrate (corr 1.00000), full weight day 30, all keys over dust by day 20, lock median 2.5 s / p99 4.6 s at 2 s delay, 14 s max at 5 s, 0 stalls in 60 days except 17 at genesis. B: share(t) = (t/30) x a/(1+a) holds to 0.04 points; 1/3 crossed at day 20.0 / 15.0 / 12.5 / 11.1 and 2/3 at never / 30.0 / 25.0 / 22.2 for a = 1 / 2 / 4 / 9; dust hands a 9x renter 1.3 extra points. C: silent set that keeps mining: active recovers in 0 / 13 / 20 / 29 / 38 min at 34 / 40 / 45 / 50 / 55%; total never (silent weight never ages out). D: churn: active 2 min (35%) and 31 min (50%); total 41 h and 10.1 days. E: active FAILS the partition test: 50/50 honest split, no attacker, both sides lock after 60 min (30 with DAA retarget), 60/40 after 121 min; first-lock time = presence x (1 - 1.5 s)/s slots, confirmed. Total: 0 conflicts in every honest partition. 34% attacker breaks every variant at 50/50 (67% per side). F: delayed eclipse of a 20% pool is harmless (participation 0 after 2 h, back in 2 h, 0 conflicts); a 34% attacker poisoning that pool finalises a private fork in 49 min under active, never under total. Floor hybrid: active denominator never below 0.85 x total (lock needs 56.7% of total) gives 0 conflicts in every partition and eclipse, recovers in 0 / 13 min at 34 / 40% silent and 2 min at 35% churn; costs 4.1 days at 50% churn and liveness ends near 42% silent. Floor 0.80 does not stop the eclipse (54% > 53.3%). Recommend: active/cert + floor 0.85, presence 240, dust 100, quorum 2/3, grace at least 3x worst delay. Not modelled: real GHOSTDAG merge and post-heal fork choice, DAA lag, VRF aggregators, certificate revocation.</p>
|
||||
<h2 id="2026-10-03-proto-metal-memory-hard-dataset-cache-8-dependent-reads-metal-only-cuda-pack-emulated">2026-10-03 proto-metal memory-hard dataset (cache + 8 dependent reads), Metal only; CUDA pack emulated</h2>
|
||||
<p>Machine: the same Apple M5 Max (one performance core for the CPU figures). Construction, every table and the commands are in <code>proto-metal/MEMHARD.md</code>. Default dataset is now memory-hard; <code>--closed-form</code> keeps the original for comparison. Construction: 256 MiB cache = 2^22 lines of 64 B in 2^16 chains of 64 ChaCha12 blocks with feed-forward (in_j = prev ^ (sigma || K[8] || seg || j || tag)); item t = 16 words, 8 rounds of (seed-parameterised ARX-multiply mixer, read cache line s[0] & (2^22-1), xor) plus a final mixer; dataset[w] = item(w >> 4)[w & 15]. Hash kernel unchanged. Cache fill: 2.0 ms GPU (0.6 to 2.1 across runs), 185 ms one CPU core (Swift), 162 ms C++ host reference. Dataset build 1 GiB: 20.6 ms GPU (29.4 first in process), 814 M items/s, 6.5 G cache-line reads/s. GPU cache == CPU cache on all 2^26 words every run (FNV-1a 64 48c4f5bf24166b2e for day 2026-10-03). Shortcut ratio, seed igneum-genesis, 1 GiB: honest 45.2 Mhash/s in both constructions. Inline kernel (never reads the dataset): closed form 5,014 Mhash/s (111x FASTER than honest); memory-hard 9.49 Mhash/s (0.21 of honest, 4.8x SLOWER). At a 256 MiB dataset: honest 94.8, inline 9.48 (0.10). CPU verify per 32-lane warp (holds only the cache, derives every word on demand, 32 lanes interleaved): 0.649 / 0.631 / 0.701 ms for igneum-genesis, /epoch1, /epoch2 (104, 104, 112 loads; 3,328 to 3,584 items); 0.801 ms igneum-second-seed (104 loads); 1.205 ms igneum-second-seed/epoch1 (144 loads, 4,608 items). Cold single warps 1.16 to 2.11 ms. Closed form was 0.017 ms. 10 ms GATE MET, margin about 8x steady. Levers (implemented, measured, OFF by default; default generator unchanged): (a) --load-weight 17: 72 to 80 loads/hash, CPU 0.457 to 0.512 ms/warp, GPU 55.0 to 73.4 Mhash/s. (b) --wide-frac 50 (warp-coalesced 128 B loads): CPU 0.233 to 0.489 ms/warp, GPU 56.1 to 135.2 Mhash/s and useful bandwidth up to 56 GB/s, so (b) erodes the random-access bound. (a)+(b): CPU 0.223 to 0.276, GPU 106 to 139. Recommendation: no lever; (a) is the fallback if a slower verifier ever threatens the gate; (b) not recommended. Tests re-run on the new dataset: fuzz 200/200 (800 warps, 25,600 hashes, 0 mismatches, CPU interpreter 1.23 s), edge 14/14, determinism PASS (fingerprint 62a4f0eb018df273), memcheck PASS, stats PASS (3 seeds, no obvious bias). 3 warps x 3 seeds bit-exact in the bench run. CUDA: new pack proto-cuda/packs/igneum-genesis-mh (kernel.cu with cache-fill and build kernels, memhard.h shared by device and host, vectors incl. cache head/last/FNV and 64 sampled words). host.cu handles both modes; old packs unchanged (closed-form export re-run is byte-identical in kernel.cu and program.metal). clang emulation (emu/emu.sh igneum-genesis-mh): cache check PASS (all words, FNV == Mac), dataset self-test PASS at 1 GiB, 3/3 vectors standalone and 2/2 in batch at 2 warps/block. RTX 5090 and AMD runs of this pack PENDING; no NVIDIA figure for the memory-hard dataset exists. Not demonstrated: cross-vendor results for the new dataset; the shortcut ratio on a discrete GPU; time-memory trade-offs between the two measured points; cryptographic strength of the mixer and the chained cache; distinct-lines-per-hash census.</p>
|
||||
<h2 id="2026-10-03-rusty-kaspa-base-build-and-3-node-devnet-on-the-mac-consensus-engineer-pre-fork-proof">2026-10-03 rusty-kaspa base build and 3-node devnet on the Mac (consensus-engineer, pre-fork proof)</h2>
|
||||
<p>Machine: Apple M5 Max (18 CPU cores), 64 GB, macOS 26.6.2. Toolchain: Homebrew rust 1.69.0 was too old (repo needs 1.91.0), so rustup 1.29.1 was installed non-interactively and gives rustc 1.99.0 and cargo 1.99.0; protobuf 36.2 added via <code>brew install protobuf</code> (protoc was missing); Apple clang 14.0.3 already present. Nothing else was needed. Source: <code>vendor/rusty-kaspa</code> at commit <code>01b532e8b553523216471682649693af92f0fd16</code> (v2.1.0, 2026-09-22). <code>cargo build --release --bin kaspad</code>: 2 min 36 s cold, binary 35,405,104 bytes (34 MB), 131 compiler warnings, zero errors. Devnet: three <code>kaspad --devnet --nodnsseed --disable-upnp --enable-unsynced-mining --yes --loglevel=info</code> nodes, separate <code>--appdir</code>, P2P 16611/16621/16631, gRPC 16610/16620/16630, nodes 2 and 3 <code>--connect</code> to node 1 (node 3 to node 2 never came up because both started at once, so the topology was a star through node 1). Network params: 10 BPS (100 ms blocks), GHOSTDAG k 124, merge depth 36,000 blocks, finality depth 432,000, pruning depth 1,080,000, DAA window 661 samples x 40 blocks, genesis bits 0x1e21bc1c (about 248,663 hashes per block). Miner: kaspad ships none, so a 150-line CPU miner on <code>kaspa-pow::State</code> (real kHeavyHash, 16 threads, 300 ms template refresh) submitted to node 1 only: 27.2 MH/s sustained, 5,718 blocks in 180 s, 0 rejected. Blocks per second over the 180 s run: 31.76 on all three nodes (1,691 to 7,409 blocks each). Two phases: 56 to 62 blocks/s while difficulty sat at genesis (first 6,000 blocks, min window 150 samples), then the DAA raised difficulty to 1.12 M at block 6,018 and the rate fell to 14 to 15 blocks/s, still converging toward the 10 BPS target when the run ended. Propagation: block counts, DAA scores and sink hash were identical on all three nodes at 18 of 19 ten-second samples; the one miss was node 2 trailing by a single block for one sample. Tips stayed at 1 because a single serial miner never produced parallel blocks, so GHOSTDAG k was not exercised; a second miner is the next step for that. Earlier 30 s warm-up run: 1,690 blocks, 56.3 blocks/s on all three nodes, 28.1 MH/s. Fork points mapped with line numbers in <code>docs/fork-map.md</code> (hash, coinbase, DAA, header, depth constants, BPS and k). All nodes stopped at the end. Miner source kept outside the repo (scratchpad); re-create from <code>testing/integration/src/common/utils.rs:271</code> if needed.</p>
|
||||
<h2 id="3-october-2026-rtx-5090-memory-hard-dataset-pack-igneum-genesis-mh">3 October 2026, RTX 5090, memory-hard dataset (pack igneum-genesis-mh)</h2>
|
||||
<div class="tbl"><table><thead><tr><th>Check</th><th>Result</th></tr></thead><tbody><tr><td>256 MiB cache, GPU vs host, all 67,108,864 words</td><td>PASS, FNV-1a 48c4f5bf24166b2e matches the Mac</td></tr><tr><td>Cache fill</td><td>0.67 ms GPU, 223 ms one host thread</td></tr><tr><td>Dataset build from the cache, 1 GiB</td><td>13.4 ms, 1,253 M items/s</td></tr><tr><td>Vectors, 3 warps, standalone and in batch</td><td>96/96 PASS</td></tr><tr><td>Hash rate at 1 GiB</td><td>228.95 Mhash/s, 95.2 GB/s useful, 23.8 G random loads/s</td></tr></tbody></table></div>
|
||||
<p>Reading: the memory-hard construction is now bit-exact across Apple Metal, NVIDIA CUDA and the CPU reference, cache and dataset included. Hash rate is unchanged from the closed-form dataset on both vendors, as expected, since the hash kernel only loads; what changed is that computing items on the fly is now slower than loading them (4.8x slower measured on Apple, not yet measured on NVIDIA). Still unmeasured: the inline shortcut ratio on NVIDIA, and AMD on any dataset.</p></article>
|
||||
</div>
|
||||
<footer>© 2026 Igneum. Generated from the repository at build time. Nothing on this page is an offer to sell anything.</footer>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
131
site/build.mjs
Normal file
131
site/build.mjs
Normal file
|
|
@ -0,0 +1,131 @@
|
|||
// Igneum site build: renders the engineering log and the FUD ledger from the repository's
|
||||
// markdown into branded pages, and merges the log's dated entries into the journey feed.
|
||||
// Runs on every deploy (Vercel build command) and locally with `node build.mjs`.
|
||||
import { readFileSync, writeFileSync, existsSync } from 'node:fs';
|
||||
import { join, dirname } from 'node:path';
|
||||
import { fileURLToPath } from 'node:url';
|
||||
|
||||
const here = dirname(fileURLToPath(import.meta.url));
|
||||
const repo = join(here, '..');
|
||||
const docs = join(repo, 'docs');
|
||||
|
||||
function esc(s) { return s.replace(/&/g, '&').replace(/</g, '<').replace(/>/g, '>'); }
|
||||
function inline(s) {
|
||||
s = esc(s);
|
||||
s = s.replace(/`([^`]+)`/g, '<code>$1</code>');
|
||||
s = s.replace(/\*\*([^*]+)\*\*/g, '<strong>$1</strong>');
|
||||
s = s.replace(/\[([^\]]+)\]\((https?:[^)]+)\)/g, '<a href="$2" rel="noopener">$1</a>');
|
||||
return s;
|
||||
}
|
||||
function md(src) {
|
||||
const lines = src.split('\n'); const out = []; let i = 0; let toc = [];
|
||||
const slug = t => t.toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-|-$/g, '');
|
||||
while (i < lines.length) {
|
||||
const l = lines[i];
|
||||
if (/^```/.test(l)) { const buf = []; i++; while (i < lines.length && !/^```/.test(lines[i])) buf.push(lines[i++]); i++; out.push('<pre>' + esc(buf.join('\n')) + '</pre>'); continue; }
|
||||
const h = /^(#{1,4})\s+(.*)$/.exec(l);
|
||||
if (h) { const lvl = h[1].length; const t = h[2].trim(); const id = slug(t); if (lvl <= 2) toc.push({ lvl, t, id }); out.push(`<h${lvl} id="${id}">${inline(t)}</h${lvl}>`); i++; continue; }
|
||||
if (/^\|/.test(l)) {
|
||||
const rows = []; while (i < lines.length && /^\|/.test(lines[i])) rows.push(lines[i++]);
|
||||
const cells = r => r.replace(/^\||\|$/g, '').split('|').map(c => c.trim());
|
||||
const head = cells(rows[0]); const body = rows.slice(1).filter(r => !/^\|\s*-{2,}/.test(r));
|
||||
out.push('<div class="tbl"><table><thead><tr>' + head.map(c => `<th>${inline(c)}</th>`).join('') + '</tr></thead><tbody>' + body.map(r => '<tr>' + cells(r).map(c => `<td>${inline(c)}</td>`).join('') + '</tr>').join('') + '</tbody></table></div>');
|
||||
continue;
|
||||
}
|
||||
if (/^\s*[-*]\s+/.test(l)) { const items = []; while (i < lines.length && /^\s*[-*]\s+/.test(lines[i])) items.push(lines[i++].replace(/^\s*[-*]\s+/, '')); out.push('<ul>' + items.map(x => `<li>${inline(x)}</li>`).join('') + '</ul>'); continue; }
|
||||
if (/^\s*\d+\.\s+/.test(l)) { const items = []; while (i < lines.length && /^\s*\d+\.\s+/.test(lines[i])) items.push(lines[i++].replace(/^\s*\d+\.\s+/, '')); out.push('<ol>' + items.map(x => `<li>${inline(x)}</li>`).join('') + '</ol>'); continue; }
|
||||
if (/^\s*$/.test(l)) { i++; continue; }
|
||||
const buf = []; while (i < lines.length && !/^\s*$/.test(lines[i]) && !/^(#|\||```|\s*[-*]\s|\s*\d+\.\s)/.test(lines[i])) buf.push(lines[i++]);
|
||||
out.push('<p>' + inline(buf.join(' ')) + '</p>');
|
||||
}
|
||||
return { html: out.join('\n'), toc };
|
||||
}
|
||||
|
||||
const mark = `<svg viewBox="0 0 100 100" width="26" height="26" aria-hidden="true"><polygon points="50,4 74,34 67,58 80,54 61,96 39,96 20,54 33,58 26,34" fill="#F2541B"></polygon><polygon points="50,42 59,58 50,82 41,58" fill="#0C0C0E"></polygon></svg>`;
|
||||
function page(title, desc, bodyHtml, toc, note) {
|
||||
const nav = toc.filter(t => t.lvl === 2).map(t => `<li><a href="#${t.id}">${esc(t.t)}</a></li>`).join('');
|
||||
return `<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
|
||||
<title>${esc(title)}</title>
|
||||
<meta name="description" content="${esc(desc)}">
|
||||
<meta name="theme-color" content="#0C0C0E">
|
||||
<link rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'%3E%3Cpolygon points='50,4 74,34 67,58 80,54 61,96 39,96 20,54 33,58 26,34' fill='%23F2541B'/%3E%3C/svg%3E">
|
||||
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Unbounded:wght@500;700;900&family=IBM+Plex+Sans:wght@400;500;600&family=IBM+Plex+Mono:wght@400;500&display=swap">
|
||||
<style>
|
||||
:root{--obsidian:#0C0C0E;--graphite:#16161A;--line:#2A2A30;--ember:#F2541B;--molten:#FFB35C;--bone:#F4F1EC;--ash:#9A9A9E;--ink-2:#C9C7C2}
|
||||
*{box-sizing:border-box}body{margin:0;background:var(--obsidian);color:var(--bone);font-family:'IBM Plex Sans',system-ui,sans-serif;font-size:16px;line-height:1.6;padding-inline:clamp(16px,4vw,32px)}
|
||||
a{color:var(--ember);text-decoration:none}a:hover{text-decoration:underline}
|
||||
.wrap{max-width:1180px;margin:0 auto}
|
||||
header{display:flex;flex-wrap:wrap;justify-content:space-between;align-items:center;gap:16px;padding-block:18px;border-bottom:1px solid var(--line)}
|
||||
.brand{display:flex;align-items:center;gap:10px;color:var(--bone)}.brand b{font-family:'Unbounded',sans-serif;font-weight:900;letter-spacing:.06em;font-size:18px}
|
||||
header nav{display:flex;flex-wrap:wrap;gap:18px;font-size:14px}header nav a{color:var(--ink-2)}
|
||||
h1{font-family:'Unbounded',sans-serif;font-weight:900;font-size:clamp(28px,5vw,48px);line-height:1.05;margin:36px 0 10px}
|
||||
.note{color:var(--ash);font-size:15px;max-width:72ch;margin-bottom:28px}
|
||||
.layout{display:grid;grid-template-columns:minmax(0,1fr);gap:32px;padding-bottom:80px}
|
||||
@media(min-width:960px){.layout{grid-template-columns:240px minmax(0,1fr);gap:56px}}
|
||||
.toc{align-self:start;font-size:14px}@media(min-width:960px){.toc{position:sticky;top:24px}}
|
||||
.toc ol{list-style:none;margin:0;padding:0;display:flex;flex-direction:column;gap:2px}.toc a{display:block;padding:6px 10px;border-radius:8px;color:var(--ink-2)}.toc a:hover{background:var(--graphite);text-decoration:none;color:var(--bone)}
|
||||
article{max-width:78ch;min-width:0}
|
||||
article h2{font-family:'Unbounded',sans-serif;font-weight:700;font-size:clamp(20px,2.6vw,26px);margin:44px 0 12px;padding-top:24px;border-top:1px solid var(--line)}
|
||||
article h3{font-family:'Unbounded',sans-serif;font-weight:500;font-size:16px;margin:26px 0 8px}
|
||||
article h4{font-size:15px;margin:20px 0 6px;color:var(--molten)}
|
||||
article p{margin:0 0 14px}article ul,article ol{margin:0 0 14px;padding-left:22px}article li{margin-bottom:6px}
|
||||
code{font-family:'IBM Plex Mono',monospace;font-size:.92em;background:var(--graphite);padding:1px 5px;border-radius:4px}
|
||||
pre{margin:0 0 16px;padding:14px 16px;background:var(--graphite);border-radius:12px;font-family:'IBM Plex Mono',monospace;font-size:13px;line-height:1.55;overflow-x:auto}
|
||||
.tbl{overflow-x:auto;margin:14px 0 20px;border:1px solid var(--line);border-radius:12px;background:var(--graphite)}
|
||||
table{border-collapse:collapse;width:100%;min-width:560px;font-size:14px}th,td{padding:10px 12px;text-align:left;vertical-align:top;border-bottom:1px solid var(--line)}
|
||||
th{font-family:'IBM Plex Mono',monospace;font-size:11px;letter-spacing:.12em;text-transform:uppercase;color:var(--ash);font-weight:500;background:var(--obsidian)}tr:last-child td{border-bottom:0}
|
||||
footer{border-top:1px solid var(--line);padding-block:24px 48px;font-size:13px;color:var(--ash)}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="wrap">
|
||||
<header><a class="brand" href="/">${mark}<b>IGNEUM</b></a><nav><a href="/">Home</a><a href="/litepaper">Litepaper</a><a href="/bench">Engineering log</a><a href="/ledger">FUD ledger</a><a href="https://github.com/[second-owner-login]/igneum" rel="noopener">GitHub</a></nav></header>
|
||||
<h1>${esc(title)}</h1>
|
||||
<p class="note">${note}</p>
|
||||
<div class="layout">
|
||||
<nav class="toc" aria-label="Contents"><ol>${nav}</ol></nav>
|
||||
<article>${bodyHtml}</article>
|
||||
</div>
|
||||
<footer>© 2026 Igneum. Generated from the repository at build time. Nothing on this page is an offer to sell anything.</footer>
|
||||
</div>
|
||||
</body>
|
||||
</html>`;
|
||||
}
|
||||
|
||||
let built = [];
|
||||
if (existsSync(join(docs, 'bench-log.md'))) {
|
||||
const src = readFileSync(join(docs, 'bench-log.md'), 'utf8');
|
||||
const { html, toc } = md(src);
|
||||
writeFileSync(join(here, 'bench.html'), page('Engineering log', 'Every Igneum benchmark and test, with the commands that produced it.', html, toc,
|
||||
'Every measurement the project has made, newest at the bottom, written by the people and agents who ran it, with the commands and hardware. Prototype numbers are not mining numbers and say so.'));
|
||||
built.push('bench.html');
|
||||
// journey feed: dated headings become log entries
|
||||
const entries = [];
|
||||
for (const m of src.matchAll(/^##+\s+(\d{1,2}\s+\w+\s+\d{4})[,:]?\s*(.*)$/gm)) {
|
||||
const d = new Date(m[1]); if (isNaN(d)) continue;
|
||||
const iso = d.toISOString().slice(0, 10);
|
||||
const text = m[2].replace(/\(.*?\)/g, '').replace(/\s+/g, ' ').trim();
|
||||
if (text) entries.push({ date: iso, text: text.charAt(0).toUpperCase() + text.slice(1) });
|
||||
}
|
||||
const jp = join(here, 'journey.json');
|
||||
const j = JSON.parse(readFileSync(jp, 'utf8'));
|
||||
const seen = new Set(j.log.map(e => e.date + '|' + e.text));
|
||||
for (const e of entries.reverse()) { const k = e.date + '|' + e.text; if (!seen.has(k)) { j.log.unshift(e); seen.add(k); } }
|
||||
j.log.sort((a, b) => (a.date < b.date ? 1 : a.date > b.date ? -1 : 0));
|
||||
j.log = j.log.slice(0, 40);
|
||||
j.updated = j.log[0] ? j.log[0].date : j.updated;
|
||||
writeFileSync(jp, JSON.stringify(j, null, 2) + '\n');
|
||||
built.push('journey.json (' + j.log.length + ' entries)');
|
||||
}
|
||||
if (existsSync(join(docs, 'fud-ledger.md'))) {
|
||||
const src = readFileSync(join(docs, 'fud-ledger.md'), 'utf8');
|
||||
const { html, toc } = md(src);
|
||||
writeFileSync(join(here, 'ledger.html'), page('FUD ledger', 'Every serious criticism of Igneum, with the evidence-backed answer or the honest open item.', html, toc,
|
||||
'Every criticism a serious person would make, written before they make it, with the answer, the evidence, or the admission that it is open and the experiment that settles it. Overclaims found in our own text are listed too. Submissions are welcome and will be added with the same honesty.'));
|
||||
built.push('ledger.html');
|
||||
}
|
||||
console.log('built: ' + built.join(', '));
|
||||
|
|
@ -2,18 +2,81 @@
|
|||
"updated": "2026-10-03",
|
||||
"stage": "phase-2",
|
||||
"phases": [
|
||||
{ "id": "phase-1", "name": "Specification", "when": "Oct to Nov 2026", "status": "active", "line": "Mining generator, shard proving, finality rules, written for external review" },
|
||||
{ "id": "phase-2", "name": "Prove the proving", "when": "Nov 2026 to Jan 2027", "status": "active", "line": "Mining program prototype on GPU and CPU, shard proving benchmark on consumer cards", "gate": "A mid-range GPU proves a shard in under 20 s and a CPU verifies a hash in 10 ms" },
|
||||
{ "id": "phase-3", "name": "Devnet", "when": "Feb to Mar 2027", "status": "next", "line": "BlockDAG node with the new mining program and EVM execution, 20 nodes", "gate": "1 block a second held with proofs under 60 s behind the tip" },
|
||||
{ "id": "phase-4", "name": "Finality and job market", "when": "Apr to Jul 2027", "status": "next", "line": "Sustained-mining finality, external proving jobs, miner client with auto-switching", "gate": "Finality design passes external review and one rollup signs for testnet" },
|
||||
{ "id": "phase-5", "name": "Public testnet", "when": "Aug to Oct 2027", "status": "next", "line": "One-click miner app on Windows, macOS and Linux, HiveOS, pools, the first rollup as a proving customer, no coin yet", "gate": "1,000 independent miners run 30 days and rollup proofs are delivered on time" },
|
||||
{ "id": "phase-6", "name": "Mainnet fair launch", "when": "Nov 2027", "status": "next", "line": "Genesis with no premine, 30-day ramp, exchange listings after" }
|
||||
{
|
||||
"id": "phase-1",
|
||||
"name": "Specification",
|
||||
"when": "Oct to Nov 2026",
|
||||
"status": "active",
|
||||
"line": "Mining generator, shard proving, finality rules, written for external review"
|
||||
},
|
||||
{
|
||||
"id": "phase-2",
|
||||
"name": "Prove the proving",
|
||||
"when": "Nov 2026 to Jan 2027",
|
||||
"status": "active",
|
||||
"line": "Mining program prototype on GPU and CPU, shard proving benchmark on consumer cards",
|
||||
"gate": "A mid-range GPU proves a shard in under 20 s and a CPU verifies a hash in 10 ms"
|
||||
},
|
||||
{
|
||||
"id": "phase-3",
|
||||
"name": "Devnet",
|
||||
"when": "Feb to Mar 2027",
|
||||
"status": "next",
|
||||
"line": "BlockDAG node with the new mining program and EVM execution, 20 nodes",
|
||||
"gate": "1 block a second held with proofs under 60 s behind the tip"
|
||||
},
|
||||
{
|
||||
"id": "phase-4",
|
||||
"name": "Finality and job market",
|
||||
"when": "Apr to Jul 2027",
|
||||
"status": "next",
|
||||
"line": "Sustained-mining finality, external proving jobs, miner client with auto-switching",
|
||||
"gate": "Finality design passes external review and one rollup signs for testnet"
|
||||
},
|
||||
{
|
||||
"id": "phase-5",
|
||||
"name": "Public testnet",
|
||||
"when": "Aug to Oct 2027",
|
||||
"status": "next",
|
||||
"line": "One-click miner app on Windows, macOS and Linux, HiveOS, pools, the first rollup as a proving customer, no coin yet",
|
||||
"gate": "1,000 independent miners run 30 days and rollup proofs are delivered on time"
|
||||
},
|
||||
{
|
||||
"id": "phase-6",
|
||||
"name": "Mainnet fair launch",
|
||||
"when": "Nov 2027",
|
||||
"status": "next",
|
||||
"line": "Genesis with no premine, 30-day ramp, exchange listings after"
|
||||
}
|
||||
],
|
||||
"log": [
|
||||
{ "date": "2026-10-03", "text": "RTX 5090 ran two generated programs and matched the Apple M5 Max hash for hash, 192 of 192. Vendor independence measured on two vendors." },
|
||||
{ "date": "2026-10-03", "text": "Fuzzing: 10,200 random programs, 1.3 million hashes, zero GPU to CPU mismatches on Apple silicon." },
|
||||
{ "date": "2026-10-03", "text": "Second hostile review of the finality rule. Two fatal flaws found and fixed. Rule version 2 published in the design doc." },
|
||||
{ "date": "2026-10-03", "text": "First prototype of the random-program lottery hash ran on an Apple M5 Max. GPU and CPU agreed bit for bit." },
|
||||
{ "date": "2026-10-03", "text": "Igneum named. Litepaper, brand and wallet designs published." }
|
||||
{
|
||||
"date": "2026-10-03",
|
||||
"text": "RTX 5090 ran two generated programs and matched the Apple M5 Max hash for hash, 192 of 192. Vendor independence measured on two vendors."
|
||||
},
|
||||
{
|
||||
"date": "2026-10-03",
|
||||
"text": "Fuzzing: 10,200 random programs, 1.3 million hashes, zero GPU to CPU mismatches on Apple silicon."
|
||||
},
|
||||
{
|
||||
"date": "2026-10-03",
|
||||
"text": "Second hostile review of the finality rule. Two fatal flaws found and fixed. Rule version 2 published in the design doc."
|
||||
},
|
||||
{
|
||||
"date": "2026-10-03",
|
||||
"text": "First prototype of the random-program lottery hash ran on an Apple M5 Max. GPU and CPU agreed bit for bit."
|
||||
},
|
||||
{
|
||||
"date": "2026-10-03",
|
||||
"text": "Igneum named. Litepaper, brand and wallet designs published."
|
||||
},
|
||||
{
|
||||
"date": "2026-10-02",
|
||||
"text": "RTX 5090 first run"
|
||||
},
|
||||
{
|
||||
"date": "2026-10-02",
|
||||
"text": "RTX 5090, memory-hard dataset"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
|
|||
636
site/ledger.html
Normal file
636
site/ledger.html
Normal file
|
|
@ -0,0 +1,636 @@
|
|||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
|
||||
<title>FUD ledger</title>
|
||||
<meta name="description" content="Every serious criticism of Igneum, with the evidence-backed answer or the honest open item.">
|
||||
<meta name="theme-color" content="#0C0C0E">
|
||||
<link rel="icon" href="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 100 100'%3E%3Cpolygon points='50,4 74,34 67,58 80,54 61,96 39,96 20,54 33,58 26,34' fill='%23F2541B'/%3E%3C/svg%3E">
|
||||
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Unbounded:wght@500;700;900&family=IBM+Plex+Sans:wght@400;500;600&family=IBM+Plex+Mono:wght@400;500&display=swap">
|
||||
<style>
|
||||
:root{--obsidian:#0C0C0E;--graphite:#16161A;--line:#2A2A30;--ember:#F2541B;--molten:#FFB35C;--bone:#F4F1EC;--ash:#9A9A9E;--ink-2:#C9C7C2}
|
||||
*{box-sizing:border-box}body{margin:0;background:var(--obsidian);color:var(--bone);font-family:'IBM Plex Sans',system-ui,sans-serif;font-size:16px;line-height:1.6;padding-inline:clamp(16px,4vw,32px)}
|
||||
a{color:var(--ember);text-decoration:none}a:hover{text-decoration:underline}
|
||||
.wrap{max-width:1180px;margin:0 auto}
|
||||
header{display:flex;flex-wrap:wrap;justify-content:space-between;align-items:center;gap:16px;padding-block:18px;border-bottom:1px solid var(--line)}
|
||||
.brand{display:flex;align-items:center;gap:10px;color:var(--bone)}.brand b{font-family:'Unbounded',sans-serif;font-weight:900;letter-spacing:.06em;font-size:18px}
|
||||
header nav{display:flex;flex-wrap:wrap;gap:18px;font-size:14px}header nav a{color:var(--ink-2)}
|
||||
h1{font-family:'Unbounded',sans-serif;font-weight:900;font-size:clamp(28px,5vw,48px);line-height:1.05;margin:36px 0 10px}
|
||||
.note{color:var(--ash);font-size:15px;max-width:72ch;margin-bottom:28px}
|
||||
.layout{display:grid;grid-template-columns:minmax(0,1fr);gap:32px;padding-bottom:80px}
|
||||
@media(min-width:960px){.layout{grid-template-columns:240px minmax(0,1fr);gap:56px}}
|
||||
.toc{align-self:start;font-size:14px}@media(min-width:960px){.toc{position:sticky;top:24px}}
|
||||
.toc ol{list-style:none;margin:0;padding:0;display:flex;flex-direction:column;gap:2px}.toc a{display:block;padding:6px 10px;border-radius:8px;color:var(--ink-2)}.toc a:hover{background:var(--graphite);text-decoration:none;color:var(--bone)}
|
||||
article{max-width:78ch;min-width:0}
|
||||
article h2{font-family:'Unbounded',sans-serif;font-weight:700;font-size:clamp(20px,2.6vw,26px);margin:44px 0 12px;padding-top:24px;border-top:1px solid var(--line)}
|
||||
article h3{font-family:'Unbounded',sans-serif;font-weight:500;font-size:16px;margin:26px 0 8px}
|
||||
article h4{font-size:15px;margin:20px 0 6px;color:var(--molten)}
|
||||
article p{margin:0 0 14px}article ul,article ol{margin:0 0 14px;padding-left:22px}article li{margin-bottom:6px}
|
||||
code{font-family:'IBM Plex Mono',monospace;font-size:.92em;background:var(--graphite);padding:1px 5px;border-radius:4px}
|
||||
pre{margin:0 0 16px;padding:14px 16px;background:var(--graphite);border-radius:12px;font-family:'IBM Plex Mono',monospace;font-size:13px;line-height:1.55;overflow-x:auto}
|
||||
.tbl{overflow-x:auto;margin:14px 0 20px;border:1px solid var(--line);border-radius:12px;background:var(--graphite)}
|
||||
table{border-collapse:collapse;width:100%;min-width:560px;font-size:14px}th,td{padding:10px 12px;text-align:left;vertical-align:top;border-bottom:1px solid var(--line)}
|
||||
th{font-family:'IBM Plex Mono',monospace;font-size:11px;letter-spacing:.12em;text-transform:uppercase;color:var(--ash);font-weight:500;background:var(--obsidian)}tr:last-child td{border-bottom:0}
|
||||
footer{border-top:1px solid var(--line);padding-block:24px 48px;font-size:13px;color:var(--ash)}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="wrap">
|
||||
<header><a class="brand" href="/"><svg viewBox="0 0 100 100" width="26" height="26" aria-hidden="true"><polygon points="50,4 74,34 67,58 80,54 61,96 39,96 20,54 33,58 26,34" fill="#F2541B"></polygon><polygon points="50,42 59,58 50,82 41,58" fill="#0C0C0E"></polygon></svg><b>IGNEUM</b></a><nav><a href="/">Home</a><a href="/litepaper">Litepaper</a><a href="/bench">Engineering log</a><a href="/ledger">FUD ledger</a><a href="https://github.com/[second-owner-login]/igneum" rel="noopener">GitHub</a></nav></header>
|
||||
<h1>FUD ledger</h1>
|
||||
<p class="note">Every criticism a serious person would make, written before they make it, with the answer, the evidence, or the admission that it is open and the experiment that settles it. Overclaims found in our own text are listed too. Submissions are welcome and will be added with the same honesty.</p>
|
||||
<div class="layout">
|
||||
<nav class="toc" aria-label="Contents"><ol><li><a href="#what-this-is">What this is</a></li><li><a href="#1-mining-and-asic-claims">1. Mining and ASIC claims</a></li><li><a href="#2-finality-and-attacks">2. Finality and attacks</a></li><li><a href="#3-proving-and-the-zkevm">3. Proving and the zkEVM</a></li><li><a href="#4-economics-and-the-coin">4. Economics and the coin</a></li><li><a href="#5-governance-and-the-founders">5. Governance and the founders</a></li><li><a href="#6-comparisons">6. Comparisons</a></li><li><a href="#7-legal-and-regulatory">7. Legal and regulatory</a></li><li><a href="#8-launch-and-community">8. Launch and community</a></li><li><a href="#count-by-status">Count by status</a></li><li><a href="#overclaims-to-remove-from-public-text-now">Overclaims to remove from public text now</a></li></ol></nav>
|
||||
<article><h1 id="igneum-fud-ledger">Igneum FUD ledger</h1>
|
||||
<p>Version 0.1, 3 October 2026. A living document. Published alongside the litepaper.</p>
|
||||
<h2 id="what-this-is">What this is</h2>
|
||||
<p>Every serious criticism or attack we expect against Igneum, written the way it will be posted, with the honest answer next to it. Where the answer is a measurement, the file that holds the measurement is named. Where the answer is a design rule, the rule is quoted. Where there is no answer yet, the entry says "Open" and names the experiment that will settle it and when. Where the critic is right, the entry says so.</p>
|
||||
<p>The ledger exists because the only way a design survives public scrutiny is for every pick to have been answered in public before anyone else makes it. It is written against litepaper v0.1 and the design document as of 3 October 2026. Entries are never deleted. When the status of an entry changes, the old status stays in the history of this file.</p>
|
||||
<p>Statuses used:</p>
|
||||
<div class="tbl"><table><thead><tr><th>Status</th><th>Meaning</th></tr></thead><tbody><tr><td>Answered with evidence</td><td>A measurement, simulation or cited precedent exists and is named</td></tr><tr><td>Answered by design</td><td>A consensus rule or a design decision answers it; no measurement is needed or possible yet</td></tr><tr><td>Open, experiment scheduled</td><td>We do not know. The experiment and its date are named</td></tr><tr><td>Conceded</td><td>The critic is right. "Stated" means the litepaper already says so; "not yet stated" means the litepaper must change, and the fix is in the overclaims list at the end</td></tr></tbody></table></div>
|
||||
<p>Submitting a criticism: open an issue on the repository once it is public (January 2027, with the benchmark), or use the contact route on igneum.network. Anything that is not already in this ledger, or that shows an entry here is wrong, gets added with credit if wanted.</p>
|
||||
<p>Evidence locations referenced below: <code>docs/bench-log.md</code>, <code>proto-metal/TESTS.md</code>, <code>sim/results.md</code>, <code>sim/finality_sim.py</code>, <code>proto-cuda/</code>, the design document section "Finality rule, version 2, after the second hostile review" (called "design doc, Finality v2" here), its "Security model" table, and its "What the hostile review changed" table.</p>
|
||||
<p>---</p>
|
||||
<h2 id="1-mining-and-asic-claims">1. Mining and ASIC claims</h2>
|
||||
<h3 id="m1-the-program-space-is-tiny">M1. The program space is tiny</h3>
|
||||
<p>"Eleven integer ops, 64 instructions, 8 iterations, a splitmix register init. That is not RandomX. RandomX leans on a superscalar out-of-order CPU with floating point and branches. Yours is a sea of 32-bit ALUs and a memory bus. A chip for that is a weekend."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Correct that the arithmetic is simple on purpose. Integer only, because floating point rounds differently per vendor and would split the chain (design doc, hostile review table, row 2). The defence is not the ALU work. It is random 4-byte reads over a dataset larger than any on-chip cache: the RTX 5090 runs the same program 5.8x faster when the dataset fits in its 96 MiB L2 (1,352 Mhash/s at 64 MiB against 229 at 1 GiB, bench-log, RTX 5090 sweep). A chip has to buy the same gigabytes of memory and loses the same latency. The honest target for a chip's gain is under 2x and it is a target, not a measurement. The experiment that tests it is the standing bounty for any chip design beating a GPU by more than 2x, live with the public benchmark in January 2027 (design doc, decisions table, row 1). Until a bounty has gone unclaimed for years the claim is a target.</p>
|
||||
<p>Evidence: <code>docs/bench-log.md</code> (RTX 5090 dataset sweep), <code>proto-metal/TESTS.md</code> section 8 "Not demonstrated" item 2. Bounty: not yet.</p>
|
||||
<h3 id="m2-your-own-prototype-is-not-memory-hard">M2. Your own prototype is not memory-hard</h3>
|
||||
<p>"Your TESTS.md says computing the dataset inline runs 110x faster than loading it. You put the 228 Mhash/s number on the website anyway."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: True. The prototype dataset is a six-operation closed form, and <code>--inline-dataset</code> measured 4,888 Mhash/s against 44.6 honest on the M5 Max, about 110x. The litepaper quotes the 228 and 45 Mhash/s figures without that caveat. The fix is the 256 MB RandomX-style cache with eight dependent reads per item (design doc, Finality v2, Lottery seeds item 3), which is the next thing to build. The number that matters afterwards is the shortcut ratio, which must fall to about 1. The litepaper must carry the caveat until then.</p>
|
||||
<p>Evidence: <code>proto-metal/TESTS.md</code> section 7. Fix: overclaims list, item 23.</p>
|
||||
<h3 id="m3-kaspa-said-asic-resistant-too">M3. Kaspa said ASIC resistant too</h3>
|
||||
<p>"Every GPU coin promised this. IceRiver shipped a Kaspa chip in eighteen months. Why are you different?"</p>
|
||||
<p>Status: Answered by design, with a correction to our own text.</p>
|
||||
<p>Answer: First the correction: Kaspa did not promise ASIC resistance. kHeavyHash was designed to be friendly to specialised and optical hardware, and the Kaspa community expected chips (approximate, from memory; cite the Kaspa docs before quoting). Our litepaper's "Kaspa said ASIC resistant too" misstates them and will be reworded. What differs here: the program changes hourly and is compiled from a generator fixed at genesis, the dataset is derived daily and grows on a fixed schedule, and instruction families unlock by height from a genesis reserve. A chip that handles the whole program space is a GPU with the graphics parts removed. Precedent: RandomX has run on Monero since November 2019 with no chip publicly shipped (approximate).</p>
|
||||
<p>Evidence: design doc, "ASIC resistance" section. Fix: overclaims list, items 11 and 49.</p>
|
||||
<h3 id="m4-progpow-already-did-this-and-you-do-not-mention-it">M4. ProgPoW already did this and you do not mention it</h3>
|
||||
<p>"A GPU program whose random maths changes every few blocks shipped on Ravencoin as KAWPOW in 2020. Your 'first' table says the GPU version was 'designed, discussed, never shipped'. That is false."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: Correct. ProgPoW, and KAWPOW on Ravencoin since May 2020 (approximate), regenerate a random maths sequence per period on GPUs. The design doc cites ProgPoW's fixed-footprint rule; the litepaper's firsts table does not. What Igneum adds over ProgPoW: a full kernel per hour compiled to native code, warp shuffles as the unit of work and verification, a daily dataset derived from a 256 MB cache, a verifiable delay between seed and program, automatic era draws from a genesis reserve, and a growing dataset. The row must be rewritten to name ProgPoW and KAWPOW as the closest precedent.</p>
|
||||
<p>Evidence: none in the repository yet; the ProgPoW specification and the Ravencoin repository should be cloned into <code>vendor/</code> and cited. Fix: overclaims list, item 5.</p>
|
||||
<h3 id="m5-your-load-count-varies-6x-between-programs">M5. Your load count varies 6x between programs</h3>
|
||||
<p>"TESTS.md: loads per hash ranged 40 to 232 across 10,000 programs. A 40-load program is ALU-bound and favours a chip for that hour. Your litepaper says the memory footprint and instruction count are fixed."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Correct and a real gap. The instruction count is fixed (64 x 8); the load count is not, and the hash rate scales with it (104 loads gave 228 Mhash/s, 128 loads gave 185 on the 5090). The generator must fix the load count per program, or bound it tightly, so every hour is equally memory-bound and difficulty does not whiplash on the hour. This goes into the specification in phase 1 and is re-fuzzed. Until then the litepaper's sentence about fixed footprint is ahead of the prototype.</p>
|
||||
<p>Evidence: <code>proto-metal/TESTS.md</code> section 1 (loads per hash 40 to 232), <code>docs/bench-log.md</code> (104 vs 128 loads). Fix: overclaims list, item 15.</p>
|
||||
<h3 id="m6-weak-programs">M6. Weak programs</h3>
|
||||
<p>"Some hours the generator will emit a program whose OR chain saturates a register or whose load addresses collapse. That hour is both biased and shortcut-able. You have measured 3 seeds for bias out of an infinite population."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Correct. Three seeds were measured for bias (max deviation 2.90 sigma over 192 bit positions, avalanche mean 32.0, std 4.0, zero duplicates) and the population was not. Nothing yet rejects a weak program. The scheduled experiment is a weak-program census of at least 10^5 programs on the CPU interpreter measuring bias, distinct load addresses, OR saturation and nonce-independent registers, then a rejection rule written into the generator. Phase 1, before the spec is final.</p>
|
||||
<p>Evidence: <code>proto-metal/TESTS.md</code> section 3 and section 8, "next three tests" item 1.</p>
|
||||
<h3 id="m7-no-cryptographic-analysis-at-all">M7. No cryptographic analysis at all</h3>
|
||||
<p>"splitmix32(nonce ^ seed) ^ seed per register, then add-rotate-xor-multiply with OR. Nobody has looked at preimage, collision or seed-influence resistance. This is a toy hash that happens to be slow."</p>
|
||||
<p>Status: Conceded, stated in the test report, not yet in the litepaper.</p>
|
||||
<p>Answer: Correct. TESTS.md section 8 says exactly this. The lottery hash needs only to be a fair lottery: unpredictable output per nonce, no shortcut cheaper than honest evaluation, no bias a miner can exploit. It does not need to be a general-purpose cryptographic hash, and the design should say that explicitly and then prove the narrower property. The ad-hoc seed derivation (FNV-1a plus SplitMix) is to be replaced with a standard hash so the seed-to-program mapping is auditable. External review in phase 1.</p>
|
||||
<p>Evidence: <code>proto-metal/TESTS.md</code> section 8, "Not demonstrated" item 1 and "next three tests" item 3.</p>
|
||||
<h3 id="m8-only-two-vendors-two-programs-one-day">M8. Only two vendors, two programs, one day</h3>
|
||||
<p>"'Any card, any vendor, bit-exact' rests on 192 vectors across two programs on one Apple chip and one NVIDIA card, all run on the same day. AMD is untested. Intel is unmentioned."</p>
|
||||
<p>Status: Answered with evidence for what was measured; Open for AMD and Intel.</p>
|
||||
<p>Answer: 192 of 192 vectors matched across Metal and CUDA on two programs, standalone and in batch. That is the measurement and it is small. AMD (ROCm or OpenCL) is the next run, then the full 10,200-program fuzz set on NVIDIA and AMD with the 14 edge-case programs, and the shuffle, mulhi and shift semantics must agree bit for bit on every vendor. Intel Arc after that. The litepaper says "Any card, any vendor" and should say what was measured.</p>
|
||||
<p>Evidence: <code>docs/bench-log.md</code> (RTX 5090 first run), <code>proto-metal/TESTS.md</code> section 8 "next three tests" item 3. Fix: overclaims list, items 20 and 59.</p>
|
||||
<h3 id="m9-the-10-ms-cpu-verification-gate-is-unmeasured">M9. The 10 ms CPU verification gate is unmeasured</h3>
|
||||
<p>"0.02 ms per warp is with a six-op dataset formula. With a 256 MB cache and eight dependent reads per item it will be a different number, and you call it 'the measured gate'."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: Correct. The 0.015 to 0.021 ms figures are with the cheap closed-form dataset. The design bounds a warp to at most 4,096 distinct dataset items, each from eight dependent cache reads, so the verifier does about 32,000 random reads in 256 MB per warp. At roughly 100 ns per miss that is about 3 ms, approximate, which is why 10 ms is the gate. It has not been measured, and the design doc lists it as a promise until measured. The experiment is scheduled on an M5 Max and on a 2019-class laptop core.</p>
|
||||
<p>Evidence: <code>docs/bench-log.md</code> (first run, CPU verify column), design doc Finality v2 "Residual risks" last bullet and "Three experiments before gate 3". Fix: overclaims list, items 16 and 21.</p>
|
||||
<h3 id="m10-bound-by-memory-bandwidth-is-wrong">M10. "Bound by memory bandwidth" is wrong</h3>
|
||||
<p>"Your own log says random-access bound. The 5090 moves 95 GB/s of useful loads against 1,638 GB/s sequential. HBM cards and chips with wide random-access memory will beat consumer GDDR here."</p>
|
||||
<p>Status: Answered with evidence, with a wording fix.</p>
|
||||
<p>Answer: The log is right and the litepaper's word is wrong: the limit is random access latency, about 23.7 billion random 4-byte loads per second on the 5090 regardless of program. The wording will change. On the substance: a chip or a datacentre card still needs gigabytes of memory and still pays the random-access cost; HBM improves bandwidth more than it improves random 32-byte sector latency, approximate. Whether an H100-class card beats a 5090 per dollar on this workload is a measurement we have not made, and it belongs on the January 2027 leaderboard.</p>
|
||||
<p>Evidence: <code>docs/bench-log.md</code>, RTX 5090 sections. Fix: overclaims list, item 14.</p>
|
||||
<h3 id="m11-hourly-jit-on-real-rigs">M11. Hourly JIT on real rigs</h3>
|
||||
<p>"50 ms compile is a Mac number. On a HiveOS rig the miner has to ship NVRTC or a ROCm compiler, compile for eight cards of mixed generation, and do it every hour without crashing. Every miner that tried runtime codegen had a bad year."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Correct that the compile figures (18 to 52 ms) are Metal on one Mac. The 5090 run used an offline nvcc build. Runtime compile with NVRTC and with ROCm on a multi-card rig is unmeasured. KAWPOW miners do ship runtime kernel generation on both vendors, so the problem is known to be solvable (approximate, from memory). Measured in phase 2 with the miner client prototype.</p>
|
||||
<p>Evidence: <code>docs/bench-log.md</code> compile columns. Rig measurement: not yet.</p>
|
||||
<h3 id="m12-rentable-hashrate-is-not-just-nicehash">M12. Rentable hashrate is not just NiceHash</h3>
|
||||
<p>"You say rental is priced by the hour. Cloud GPUs are priced by the hour too. A thousand 5090-class cards for a day is a few thousand dollars."</p>
|
||||
<p>Status: Answered by design for finality, Conceded for the lottery.</p>
|
||||
<p>Answer: Both halves true. NiceHash and MiningRigRentals cannot list an algorithm whose kernel changes hourly without a stratum for it, so classic hashrate rental does not exist at launch. Cloud GPUs do, and they can out-mine a small chain's lottery cheaply. That is why finality is weighted by 30 days of blocks, not by today's hashrate: a renter with 60% of the network earns 59.9% of block rewards on day 1 and holds 0.0% of vote weight (sim, table B). What rental can do is take block rewards and stall finality after about three weeks. See F1 for the launch window, where this answer does not yet hold.</p>
|
||||
<p>Evidence: <code>sim/results.md</code> table B.</p>
|
||||
<h3 id="m13-macs-mine-too-is-marketing">M13. Macs mine too is marketing</h3>
|
||||
<p>"An M5 Max does 45 Mhash/s against 228 on a 5090 and costs more. 'Macs mine too' is a line for people who will lose money."</p>
|
||||
<p>Status: Conceded, partly stated.</p>
|
||||
<p>Answer: The measured ratio is about 5x in the 5090's favour, so a Mac is a poor miner per dollar. The litepaper says Macs mine; it should say Macs mine at about a fifth of a flagship card and that the one-click app shows projected earnings before it starts.</p>
|
||||
<p>Evidence: <code>docs/bench-log.md</code>, two-card table.</p>
|
||||
<p>---</p>
|
||||
<h2 id="2-finality-and-attacks">2. Finality and attacks</h2>
|
||||
<h3 id="f1-finality-is-attackable-for-the-first-month">F1. Finality is attackable for the first month</h3>
|
||||
<p>"Vote weight is 30 days of blocks. At genesis there are zero days. For the first weeks weight equals hashrate share, so anyone with two thirds of a tiny launch hashrate locks checkpoints alone. You say 'no certificate in the first hour'. An hour."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper. Experiment and rule change scheduled.</p>
|
||||
<p>Answer: Correct, and this is the most dangerous entry in the ledger. With the active-weight denominator and a one-day honest head start, an attacker producing 75% of blocks from day 2 holds 0.75k/(1+k) of weight after k days and crosses two thirds on day 9 of the chain's life; an attacker arriving in hour two crosses it the same day. The window is empty, so the defence is absent. The 30-day emission ramp (10% to 100%) lowers the incentive without removing the attack. The design doc's answer, the one-hour merge-depth bound protecting the first month, bounds the damage of a reorg and does nothing about a bad lock. The rule under consideration: no certificate may form until the window has 30 days of history, so the chain runs plain GHOSTDAG under the one-hour merge-depth bound for its first month, exchanges are told to treat it so, and listings follow launch in any case. This goes to the gate 3 simulation and the litepaper will state it either way.</p>
|
||||
<p>Evidence: arithmetic above (not yet in <code>sim/</code>); design doc, hostile review table row "No stake exists in the first month". Simulation of the launch month: not yet.</p>
|
||||
<h3 id="f2-the-two-hour-presence-window-is-an-eclipse-vector">F2. The two-hour presence window is an eclipse vector</h3>
|
||||
<p>"Cut the big pools' vote gossip for two hours, not their blocks, and the remaining keys become 100% of active weight. A faction with a fifth of the weight locks alone. You chose liveness over safety and called it a feature."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Correct that the presence window trades safety for liveness. The design doc says so: "any event that keeps honest keys from signing (eclipse, partition, targeted DoS) shrinks the denominator and lets a smaller faction lock," and the simulation recommends the fail-safe all-keys denominator while the design chose the presence window as the working default. The mitigation in the rule is that a lock requires the certificate's unscaled weight to reach two thirds of active weight, so an eclipsed set still has to be out for most of the 240 checkpoints before the denominator moves far, and votes travel in blocks as well as as their own messages. That is an argument, not a measurement. The gate 3 experiment is a devnet with regional latency and a single-node eclipse recording whether conflicting locks appear, plus the choice between a 2-hour and a 7-day silent-key rule. Until it runs, this entry stays open.</p>
|
||||
<p>Evidence: <code>sim/results.md</code> table E and "What the simulation cannot tell us"; design doc Finality v2, Quorum item 4 and the "Simulation of the first version" paragraph.</p>
|
||||
<h3 id="f3-participation-grinding-through-the-bitmap">F3. Participation grinding through the bitmap</h3>
|
||||
<p>"The aggregator picks which votes go in the certificate once quorum is reached. A block producer carries the certificate it likes. Drop a rival pool's votes from your bitmaps for two hours and its participation factor falls, your share rises."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: This is a new finding from writing this ledger and it is not in the design doc. The participation factor is "observed certified votes over P divided by expected votes". If "observed" means votes present in certificates carried in blocks, then whoever aggregates and whoever produces blocks can shape it. Candidate fixes: participation computed from all votes seen in blocks (votes as transactions, not only certificates), or a certificate must include every valid vote the aggregator received above a size bound, or participation falls only on checkpoints where the key's vote appears in no certificate and no block. Goes to the cryptographer for phase 1 and to the gate 3 simulation.</p>
|
||||
<p>Evidence: design doc Finality v2, Quorum item 2 and Checkpoints item 3. Fix: not yet.</p>
|
||||
<h3 id="f4-it-is-proof-of-stake-with-extra-steps">F4. It is proof of stake with extra steps</h3>
|
||||
<p>"A two-thirds BLS committee that overrides the heaviest chain is a checkpoint committee. Bitcoin's entire point is that nothing overrides work. You built a PoS finality gadget and weighted it by past work instead of coins."</p>
|
||||
<p>Status: Answered by design, with the concession stated.</p>
|
||||
<p>Answer: The committee's weight is blocks mined in the last 30 days. There is no coin to buy, stake, delegate or slash, and the weight cannot be acquired faster than by mining in public. The design concedes what follows: pools hold their hashers' votes, so vote concentration equals pool concentration, as on Bitcoin, and a 51% owner who drives half the honest miners away for a month owns finality thereafter, "same as Bitcoin, with a month's warning". It is a finality overlay on proof of work. Calling it that in the litepaper is more honest than "powered by miners alone".</p>
|
||||
<p>Evidence: design doc Finality v2, "Residual risks" bullets 3 and 4; <code>sim/results.md</code> table F.</p>
|
||||
<h3 id="f5-the-headline-arithmetic-is-misread-on-purpose">F5. The headline arithmetic is misread on purpose</h3>
|
||||
<p>"'An attacker who brought the whole network's hashrate needs ten days for a third.' If I bring hashrate equal to the network I have half the blocks and need twenty days for a third and never reach two thirds. Your ten days assumes honest miners produce nothing."</p>
|
||||
<p>Status: Conceded, wording to fix.</p>
|
||||
<p>Answer: Correct reading. The 10 and 20 day figures assume the attacker produces 100% of blocks, which is the strongest attacker and therefore a true lower bound, and the sentence should say "an attacker producing every block on the chain". With half the blocks: 1/3 at day 20 and 2/3 never. With 60%: 1/3 on day 18 to 26 depending on the (now removed) cap, 2/3 never. With 75%: 2/3 on day 27 to 34.</p>
|
||||
<p>Evidence: <code>sim/results.md</code> tables B and C. Fix: overclaims list, item 32.</p>
|
||||
<h3 id="f6-equivocation-costs-nothing-that-matters">F6. Equivocation costs nothing that matters</h3>
|
||||
<p>"A pool that signs two checkpoints loses its vote for 30 days. Not its blocks, not its coins. If two thirds of pools collude to double-spend an exchange, the penalty is a month of not voting."</p>
|
||||
<p>Status: Conceded, stated in the litepaper and the design doc.</p>
|
||||
<p>Answer: True. "Equivocation costs history, not coins." There is nothing to slash without stake, and the design refuses stake. What bounds the damage is the one-hour merge-depth rule (a bad lock cannot reorganise deeper than an hour) and that two thirds of weight takes 20 days of 100% hashrate in public to acquire. A colluding two-thirds of pools is the same actor set that can attack Bitcoin, and the litepaper says so.</p>
|
||||
<p>Evidence: design doc Finality v2, Checkpoints item 4 and Residual risks bullet 1.</p>
|
||||
<h3 id="f7-a-2-minute-checkpoint-on-a-dag-with-a-1-hour-merge-bound">F7. A 2-minute checkpoint on a DAG with a 1-hour merge bound</h3>
|
||||
<p>"Kaspa treats an hour as the merge-depth bound at 1 bps. You vote on the selected-chain block at blue score 30i once the tip is 60 blocks past. Under real latency honest nodes will disagree on that block often enough to split votes at the same index and lose quorum."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Fair. The depth d is "set from the devnet reorg-depth distribution, 60 at one block a second", and that distribution has not been measured. The devnet experiment in gate 3 runs with regional latency and records the reorg-depth distribution at each block rate; d is chosen so that a vote split at one index is rare and self-heals at the next. Until then 60 is a placeholder. The chain also runs without the finality module (plain GHOSTDAG) so a wrong d can be corrected without a stop.</p>
|
||||
<p>Evidence: design doc Finality v2, Checkpoints item 1 and "Three experiments before gate 3".</p>
|
||||
<h3 id="f8-the-simulation-has-no-network-in-it">F8. The simulation has no network in it</h3>
|
||||
<p>"No latency, no DAG, no red blocks, no partitions, no VRF noise, perfect retarget. You published 'ten days' and 'twenty days' from that."</p>
|
||||
<p>Status: Conceded, stated in the simulation report.</p>
|
||||
<p>Answer: Correct. <code>sim/results.md</code> lists every one of those omissions under "What the simulation cannot tell us". The day counts are arithmetic on the window and hold for any model where blocks are counted; the things the model cannot see (red blocks, partitions, eclipse) are what gate 3's devnet is for. The litepaper quotes the day counts as design facts; it should attribute them to the model.</p>
|
||||
<p>Evidence: <code>sim/results.md</code>, final section.</p>
|
||||
<h3 id="f9-half-the-hashrate-leaves-and-finality-stalls-for-ten-days">F9. Half the hashrate leaves and finality stalls for ten days</h3>
|
||||
<p>"Your own sim: 50% churn stalls the lock 10 to 11 days under the fail-safe rule. GPU coins lose half their hashrate in a week when the price halves. That is routine, not an attack."</p>
|
||||
<p>Status: Answered by design.</p>
|
||||
<p>Answer: That table is the all-keys denominator, which the simulation recommended for safety. Finality v2 chose the active-weight denominator with a 2-hour presence window instead, under which no churn level stalls more than two hours (sim table E, "active" column: 100% live share from day +1 at 30%, 35% and 50% churn). The price of that choice is F2. The two experiments in gate 3 decide the final rule; the litepaper states the 2-hour figure.</p>
|
||||
<p>Evidence: <code>sim/results.md</code> table E; design doc Finality v2, Quorum item 4.</p>
|
||||
<h3 id="f10-pools-hold-the-votes">F10. Pools hold the votes</h3>
|
||||
<p>"Two pools at 70% of hashrate is normal on a GPU coin. On Igneum that is two operators holding finality."</p>
|
||||
<p>Status: Conceded, stated in the design doc, not in the litepaper.</p>
|
||||
<p>Answer: True. The vote key is named in the block header by whoever builds the block, which in a pool is the pool. The design doc states "Pools hold their hashers' votes. Vote concentration equals pool concentration, as on Bitcoin, and is public." Stratum v2 lets a hasher choose transactions when its pool supports it, and does nothing for the vote key. Solo mining is viable at one block a second (86,400 blocks a day), which widens the key set in a way Bitcoin's block rate does not, and the dust threshold of 100 blocks per 30 days is about 0.004% of hashrate. The litepaper's "governed by the people who power it, and by nobody else" must carry the pool sentence.</p>
|
||||
<p>Evidence: design doc Finality v2, Residual risks bullet 3. Fix: overclaims list, item 44.</p>
|
||||
<h3 id="f11-vdfs-are-exotic">F11. VDFs are exotic</h3>
|
||||
<p>"A class-group VDF with Wesolowski proofs in a consensus-critical path, in a project with no cryptographer. Chia needed years and still got timelord ASICs."</p>
|
||||
<p>Status: Answered by design, with the dependency conceded.</p>
|
||||
<p>Answer: The VDF is used for one thing: making the hourly program unknowable within the roughly two seconds a miner has to decide whether to publish a block, closing a withhold-or-publish grind the review measured at about 130 to 1 for a 30% miner. The VDF input is a certified checkpoint at least one epoch before the epoch starts, so honest nodes have about 50 minutes of slack to evaluate a 10-minute VDF, and an evaluator 300x faster than reference would still be needed to beat the two-second decision window. Chia has run class-group VDFs in production since 2021, with faster hardware evaluators existing and not breaking it (approximate, from memory). The design doc lists the VDF as a new dependency and ships the evaluator in every node. The grinding simulation with and without the VDF is scheduled before gate 3.</p>
|
||||
<p>Evidence: design doc Finality v2, Lottery seeds items 1 and 2, Residual risks bullet 5, "Three experiments before gate 3".</p>
|
||||
<h3 id="f12-nothing-outside-the-chain-except">F12. Nothing outside the chain, except</h3>
|
||||
<p>"No Bitcoin anchoring, you say. You depend on Succinct's SP1, BLS12-381, a class-group VDF, NVIDIA's compiler and a fork of Kaspa's node."</p>
|
||||
<p>Status: Answered by design.</p>
|
||||
<p>Answer: Those are code dependencies, chosen because each is open source and replaceable, and none is another chain's consensus. "Nothing outside Igneum" in the litepaper means no other chain's state is read, and the sentence should be scoped that way. A soundness bug in the proof system is the one dependency that can hurt consensus; see P7.</p>
|
||||
<p>Evidence: CLAUDE.md design paragraph; design doc "Decided" paragraph.</p>
|
||||
<h3 id="f13-why-prove-every-block-if-every-node-executes-anyway">F13. Why prove every block if every node executes anyway</h3>
|
||||
<p>"Every node runs the transactions natively, so full nodes do not need the proof. You pay 20% of emission for a proof that your own nodes ignore."</p>
|
||||
<p>Status: Answered by design.</p>
|
||||
<p>Answer: Full nodes execute natively so users see state in about a second. The proof is for everyone who is not a full node: light clients, bridges, exchanges syncing from a checkpoint, and the external market, which needs a standing prover population with hardware already running. It is also what lets a new node sync from a proven checkpoint instead of replaying history. The 20% is paid for capacity as much as for the proofs themselves, and the litepaper should say that.</p>
|
||||
<p>Evidence: design doc, "Proving speed on consumer GPUs" risk item and "Who needs" paragraph.</p>
|
||||
<p>---</p>
|
||||
<h2 id="3-proving-and-the-zkevm">3. Proving and the zkEVM</h2>
|
||||
<h3 id="p1-the-20-second-shard-is-a-number-you-made-up">P1. The 20-second shard is a number you made up</h3>
|
||||
<p>"'A 12 GB card proves one shard in about 20 seconds, measured on a mid-range card before launch.' So it is not measured. You wrote a target in the past tense."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: Correct. It is the phase 2 gate, to be measured on a 3060-class card, and no SP1 shard has been proven on any card in this repository yet. The sentence must be rewritten as a target.</p>
|
||||
<p>Evidence: <code>site/journey.json</code> phase 2 gate. Measurement: not yet. Fix: overclaims list, item 27.</p>
|
||||
<h3 id="p2-real-time-proving-needs-a-hundred-gpus-per-block">P2. Real-time proving needs a hundred GPUs per block</h3>
|
||||
<p>"Succinct needed on the order of 160 consumer GPUs to prove Ethereum blocks in real time in 2025. You have one block a second. Your gas throughput will be a rounding error or your proofs will fall behind."</p>
|
||||
<p>Status: Conceded, stated in the litepaper, with the dial explained.</p>
|
||||
<p>Answer: True, and the litepaper says a full block needs a cluster of 100 to 200 consumer GPUs, approximate. Igneum's gas budget per block is a consensus constant set from measured prover throughput, so throughput is a function of how many cards are proving. With few provers at launch the chain carries little gas. The design treats that as a dial, not a failure, and the litepaper should publish the launch budget as a formula (cards proving times shards per card per minute) so builders can see it. Proving costs have fallen roughly an order of magnitude a year for three years, approximate, and the interface is swappable.</p>
|
||||
<p>Evidence: design doc "Unit economics of a proof"; litepaper "What Igneum does not claim" item 1.</p>
|
||||
<h3 id="p3-a-phone-verifies-in-milliseconds-is-a-snark-wrapper-claim">P3. A phone verifies in milliseconds is a SNARK-wrapper claim</h3>
|
||||
<p>"Hash-based STARK proofs are hundreds of kilobytes and take real work to verify. Milliseconds on a phone means a Groth16 or Plonk wrapper, and wrapping SP1 proofs needs a big machine for minutes."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: Correct. The light-client proof is the aggregated block proof wrapped once into a small curve-based proof, and wrapping is the aggregator's job. The cost and latency of that wrapper on consumer hardware is unmeasured and belongs in the phase 2 benchmark alongside the shard time. Until measured, the litepaper should say "wrapped for light clients".</p>
|
||||
<p>Evidence: not yet. Fix: overclaims list, item 25.</p>
|
||||
<h3 id="p4-trustless-light-clients-need-a-consensus-proof-you-do-not-have">P4. Trustless light clients need a consensus proof you do not have</h3>
|
||||
<p>"Checking 'one proof and one locked checkpoint' means verifying a BLS certificate against two thirds of active 30-day weight. Computing that weight needs 30 days of headers. Your own review scoped the consensus proof as phase two. The litepaper sells it at launch."</p>
|
||||
<p>Status: Conceded, stated in the design doc, overclaimed in the litepaper.</p>
|
||||
<p>Answer: Correct. The hostile review table says "One-proof light clients and committee-free bridges need a consensus proof, not just an execution proof. Scoped as phase two with honest cost." At launch a light client trusts a recent certificate it is given (as Ethereum light clients trust a sync committee checkpoint) and verifies execution from there. The firsts table row and the "Trustless light clients" paragraph must be re-scoped.</p>
|
||||
<p>Evidence: design doc, hostile review table rows "Slashing an external prover" and "One-proof light clients". Fix: overclaims list, items 9 and 38.</p>
|
||||
<h3 id="p5-evm-unchanged-on-a-dag-is-false">P5. EVM "unchanged" on a DAG is false</h3>
|
||||
<p>"block.number, block.timestamp, blockhash, coinbase, prevrandao. On a DAG none of these mean what Solidity assumes. Plus your 2D fee market: wallets estimate one gas, you charge two."</p>
|
||||
<p>Status: Open, specification scheduled.</p>
|
||||
<p>Answer: Correct. The review listed this and the answer is "to be defined over the ordered sequence in the spec", phase 1. Timestamp and number come from the ordered sequence; blockhash and coinbase need a definition; prevrandao can be derived from the epoch VDF. The proving-cost dimension is folded into the quoted gas price by the node so <code>eth_estimateGas</code> keeps working, and a contract heavy in pairing or modexp precompiles will cost more here than on Ethereum. "Unchanged" should become "same bytecode, with these documented differences".</p>
|
||||
<p>Evidence: design doc, hostile review table row "EVM semantics on a DAG". Fix: overclaims list, items 35 and 36.</p>
|
||||
<h3 id="p6-the-proving-market-is-tiny">P6. The proving market is tiny</h3>
|
||||
<p>"Total rollup proving spend is low millions a year and Boundless, Succinct and the rollups' own clusters already fight for it. 'Igneum gives the proving market its cheapest supplier' is a line for miners who have not seen the numbers."</p>
|
||||
<p>Status: Conceded, stated in the litepaper, with one overclaim to fix.</p>
|
||||
<p>Answer: The litepaper says the market is small three times and calls external proving "upside, not a promise". The design doc estimates total spend at low millions of dollars a year, approximate, and says a GPU fleet of any size swamps it. Igneum does not depend on it: in-chain proving is paid from emission and gas regardless. The overclaim is "cheapest supplier": Boundless already admits home GPUs, and Succinct's and Boundless's provers must stake their own tokens, which an Igneum miner would also have to hold to bid there. "Marginal cost close to power" is defensible; "cheapest" is not.</p>
|
||||
<p>Evidence: design doc "Market size, honestly" and "Existing prover networks" table (labelled from memory). Fix: overclaims list, items 12 and 58.</p>
|
||||
<h3 id="p7-a-soundness-bug-in-sp1-is-a-consensus-failure">P7. A soundness bug in SP1 is a consensus failure</h3>
|
||||
<p>"SP1 has had disclosed soundness bugs. On Igneum a forged proof means 'a block with a wrong state cannot exist' becomes a wrong state that exists, and your upgrade path is a 90% miner vote with three months' notice."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: Correct that a live soundness bug cannot wait for a three-month release train. Full nodes execute natively, so a forged proof disagreeing with native execution is detectable by every full node, and the rule must be that a full node rejects a proof whose claimed state root differs from its own execution. That turns a soundness bug into a light-client problem rather than a chain split, and it must be written into the spec. The emergency path for the proof system version is a human one and the litepaper should say so, alongside the "nothing needs a human" sentence.</p>
|
||||
<p>Evidence: design doc "Proof system churn" risk item. Rule: not yet. Fix: overclaims list, items 3 and 26.</p>
|
||||
<h3 id="p8-fastest-prover-wins-all-the-shards">P8. Fastest prover wins all the shards</h3>
|
||||
<p>"Aleo's lesson was that proving as a race centralises to the fastest. Your shards are claimed first-come with a bond. The lowest-latency datacentre claims every shard before a home card sees it."</p>
|
||||
<p>Status: Open, design change scheduled.</p>
|
||||
<p>Answer: Fair, and the lottery/proving separation does not by itself fix it. If claims are first-come, latency wins. The candidate rule is sortition of shards: a VRF keyed to the block assigns each shard to a set of eligible provers, weighted by past proving or by a lottery, with fallback to open claiming after a timeout. This is a phase 1 specification item and a phase 4 devnet measurement. The 20% proving pool is paid per block as a fixed amount divided by consensus proving cost, so a prover's income is bounded by the shards it is assigned, not by how many it can grab.</p>
|
||||
<p>Evidence: design doc "Proving speed on consumer GPUs" risk item and Finality v2 "Fees". Rule: not yet.</p>
|
||||
<h3 id="p9-shard-griefing">P9. Shard griefing</h3>
|
||||
<p>"Claim a shard with a small bond and never prove it. Repeat. Finality waits on you."</p>
|
||||
<p>Status: Answered by design, parameters open.</p>
|
||||
<p>Answer: The bond is slashed and the shard reopens; the proving fee rises until someone proves it (security model table, "Prover cartel withholding proofs"). The open parameters are the bond size, the timeout, and whether an un-proven block delays only the proof (it does; execution and the 30-second lock do not wait for the proof). Set in phase 4.</p>
|
||||
<p>Evidence: design doc, Security model table row 3.</p>
|
||||
<h3 id="p10-external-jobs-are-paid-off-chain-so-where-is-the-burn">P10. External jobs are paid off-chain, so where is the burn</h3>
|
||||
<p>"The Economics section says every outside customer pays in IGN and part is burned. The miner section says rollups pay in their own money and the income does not move with the IGN price. Both cannot be true."</p>
|
||||
<p>Status: Conceded, contradiction to fix.</p>
|
||||
<p>Answer: The litepaper contradicts itself. The design is: at launch external jobs are paid on the customer's chain, in the customer's currency, to a payout contract keyed by miner address, because Igneum cannot yet see Ethereum. The 10% burn in IGN applies when the job market settles on Igneum, which needs the proof bridge. The Economics section must say so.</p>
|
||||
<p>Evidence: design doc "The first six months" risk item and hostile review table row "Slashing an external prover". Fix: overclaims list, item 55.</p>
|
||||
<p>---</p>
|
||||
<h2 id="4-economics-and-the-coin">4. Economics and the coin</h2>
|
||||
<h3 id="e1-hard-cap-plus-burn-is-a-security-budget-cliff">E1. Hard cap plus burn is a security budget cliff</h3>
|
||||
<p>"Monero chose tail emission so miners are paid for ever. You chose a 4 billion cap, halvings every two years, and you burn fees on top. By year twelve emission is under 1% a year and shrinking. Who pays for hashrate then?"</p>
|
||||
<p>Status: Conceded by decision, stated in the design doc.</p>
|
||||
<p>Answer: True, and the design doc records the choice: "A 1% tail is the Monero model and the safer choice for security on its own." The argument for the cap is that Igneum miners keep earning from in-chain proving fees and external jobs after emission fades, which Monero's miners cannot, and that a hard cap is the number miners trust. Emission in years 9 and 10 is 62.5 million IGN a year, 1.6% of supply; in years 11 and 12 it is 31.25 million, 0.8%. Bitcoin's inflation at its own year 10 was about 3.7%, approximate. Whether fee income replaces emission is unknowable today. A tail could be added by a 90% miner-signalled upgrade; nothing in the design prevents it.</p>
|
||||
<p>Evidence: design doc "Decision: hard cap". Litepaper: "Supply" section states the cap, not the trade-off.</p>
|
||||
<h3 id="e2-half-the-coins-in-two-years-is-an-insider-schedule">E2. Half the coins in two years is an insider schedule</h3>
|
||||
<p>"Nearly a quarter of supply in year one, half by year two, founders mining from genesis with the software they wrote and a month's head start on the benchmark. That is a premine with a GPU."</p>
|
||||
<p>Status: Answered by design, with the founder's edge conceded.</p>
|
||||
<p>Answer: The schedule (1 billion a year halving every two years, 30-day ramp from 10% to 100%) is public, fixed at genesis and the same for every miner. The founders' only edge is familiarity with software that is public a month before launch with pools live on testnet. The founders mine from disclosed addresses, which nobody else is asked to do. What this does not answer is that early adopters of any fair launch hold a disproportionate share, as on Bitcoin and Kaspa. The litepaper says "the people who show up early get the most", which is both true and a sentence a lawyer will read twice (see L2).</p>
|
||||
<p>Evidence: litepaper "Supply" and "Fair launch, announced".</p>
|
||||
<h3 id="e3-the-15-developer-share-enables-wash-gas">E3. The 15% developer share enables wash gas</h3>
|
||||
<p>"Deploy a contract, spam it with your own transactions, collect 15% of your own priority fee back. If you also mine the block you collect 80%."</p>
|
||||
<p>Status: Answered by design, with a metrics caveat.</p>
|
||||
<p>Answer: The base fee is burned in full, so every wash transaction loses its whole base fee. Of the priority fee a developer alone gets back 15% and loses 85%. A developer who also mines the block including its own transaction gets 65% plus 15% and loses 20% of the priority fee plus the full base fee. Wash gas is a guaranteed loss. What it can do is inflate an app's "gas earned" figure on a leaderboard at a cost of 20% of the priority fee, so no explorer ranking should be built on raw developer share without a self-dealing filter. Attribution is per call frame by gas consumed, with factory-deployed contracts inheriting the factory's registration.</p>
|
||||
<p>Evidence: design doc Finality v2 "Fees"; litepaper "What a builder gets for being early".</p>
|
||||
<h3 id="e4-5-of-gas-to-the-dev-fund-is-a-tax">E4. 5% of gas to the dev fund is a tax</h3>
|
||||
<p>"You say 100% of emission to miners, then take 5% of gas. Users are taxed instead."</p>
|
||||
<p>Status: Answered by design, wording fix needed.</p>
|
||||
<p>Answer: The fund takes 5% of the priority fee (the base fee is burned in full), and 5% of external job fees, and no emission. Spending needs 60% of hashrate signalling over two weeks. The litepaper says "5% of gas" and should say "5% of the priority fee". Whether a fee-funded, miner-controlled fund is a "tax" is a word choice; the number is 5% of tips.</p>
|
||||
<p>Evidence: design doc Finality v2 "Fees". Fix: overclaims list, item 56.</p>
|
||||
<h3 id="e5-not-one-coin-to-a-founder-is-false">E5. "Not one coin to a founder" is false</h3>
|
||||
<p>"The official miner carries a 1% dev fee to the founder's company. That is 1% of all hashrate paid to one company for as long as miners run it, which is a founder allocation with better PR."</p>
|
||||
<p>Status: Conceded, partly stated, homepage overclaims.</p>
|
||||
<p>Answer: Correct in substance. The litepaper discloses the 1% dev fee and says any other client is welcome. The homepage says "Not one coin to a founder, a fund or a stake", which is true of emission and false of the dev fee. The design doc also says the founder's company carries development from that fee, its pool and its proving business until usage funds the development fund. All of that must be in one place in the litepaper under a heading a critic can quote.</p>
|
||||
<p>Evidence: design doc "Funding development for ever without taxing miners". Fix: overclaims list, item 63.</p>
|
||||
<h3 id="e6-two-year-halvings-bleed-hashrate">E6. Two-year halvings bleed hashrate</h3>
|
||||
<p>"Every GPU coin that halved fast lost its miners at the second halving. You halve every two years for ever."</p>
|
||||
<p>Status: Conceded, no experiment possible.</p>
|
||||
<p>Answer: True that a halving halves emission income overnight if price and fees do nothing. The schedule was chosen for the cap and for front-loading the fair launch. Kaspa's smooth monthly reduction is a precedent for a steep schedule that kept hashrate while price rose (approximate). Igneum's in-chain proving pay does not halve with emission since it is paid from gas as well. Nothing here is a measurement; it is a bet, and the litepaper should present it as one.</p>
|
||||
<p>Evidence: none; decision in design doc "Supply".</p>
|
||||
<h3 id="e7-no-stablecoin-liquidity-without-a-trusted-bridge">E7. No stablecoin liquidity without a trusted bridge</h3>
|
||||
<p>"USDC and USDT 'bridged through the proof bridge at genesis'. The bridge needs a consensus proof you have scoped as phase two. So genesis stablecoins either wait or run on a multisig you said you would never have."</p>
|
||||
<p>Status: Open, design decision scheduled.</p>
|
||||
<p>Answer: Correct. The Ethereum-side bridge contract verifying Igneum state at launch has to verify a lock certificate, which means knowing the voter set and weights; that is the consensus proof scoped as phase two. Options: a committee-attested bridge at launch, clearly labelled as such, with the proof bridge replacing it; or no bridged stablecoins at genesis. The litepaper must stop presenting the proof bridge as a genesis feature until the decision is made. Phase 4.</p>
|
||||
<p>Evidence: design doc, hostile review table row "One-proof light clients and committee-free bridges". Fix: overclaims list, item 71.</p>
|
||||
<h3 id="e8-founders-seeding-the-dex-is-market-making-by-insiders">E8. Founders seeding the DEX is market making by insiders</h3>
|
||||
<p>"The founders seed the DEX with their own mined coins. That sets the first price and they hold the first liquidity."</p>
|
||||
<p>Status: Conceded, stated.</p>
|
||||
<p>Answer: True and stated in the litepaper. Mined coins are the only coins the founders can hold. The addresses are disclosed, so the seeding is visible. Whether to do it at all is a question for counsel (L1, L2).</p>
|
||||
<p>Evidence: litepaper "Liquidity from the people who are there".</p>
|
||||
<p>---</p>
|
||||
<h2 id="5-governance-and-the-founders">5. Governance and the founders</h2>
|
||||
<h3 id="g1-no-cryptography-team">G1. No cryptography team</h3>
|
||||
<p>"One founder. The design doc says phases one and two 'need one cryptographer or proof-systems engineer' and none is named. The reviewers for gate 3 are 'named' in the litepaper and nobody is named."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: Correct. No cryptographer has been hired. The litepaper's gate 3 refers to "named reviewers" who do not yet exist. The honest text is: the specification is written for external review; reviewers will be named and paid before gate 3; until then every security claim here is a design claim. The hostile reviews so far were run by the founder with AI assistance (G2).</p>
|
||||
<p>Evidence: design doc "Team" paragraph. Fix: overclaims list, item 50.</p>
|
||||
<h3 id="g2-an-ai-designed-this">G2. An AI designed this</h3>
|
||||
<p>"The repo has <code>.claude/agents/cryptographer.md</code>. The commits are co-authored by a language model. The 'hostile review' was a chatbot role-playing a Kaspa researcher."</p>
|
||||
<p>Status: Conceded, not yet stated in the litepaper.</p>
|
||||
<p>Answer: True. The design, the reviews, the prototype code, the simulator and this ledger were produced by the founder working with AI models, and the commit history says so. What that does and does not mean: the measurements are measurements, reproducible from the commands in the logs; the simulation is code anyone can run; the design claims are design claims until external humans with names have tried to break them. The litepaper should disclose the method in one sentence and let the measurements stand on their own.</p>
|
||||
<p>Evidence: <code>.claude/agents/</code>, commit trailers. Fix: add a disclosure sentence (overclaims list, item 73).</p>
|
||||
<h3 id="g3-who-are-you">G3. Who are you</h3>
|
||||
<p>"Anonymous founder, GoDaddy domains, a Vercel site, a litepaper dated the same day as five 'milestones'. This is a template."</p>
|
||||
<p>Status: Conceded, team page deferred by decision.</p>
|
||||
<p>Answer: The founder's name is on every commit. The litepaper defers the team page to public testnet by decision, with disclosed mining addresses at genesis. There are no coins to sell and no sale planned, so there is nothing to run away with before block one. The five log entries dated 3 October 2026 are day one of the project and should be presented as that.</p>
|
||||
<p>Evidence: design doc, decisions table row "Who are you?". Journey: <code>site/journey.json</code>.</p>
|
||||
<h3 id="g4-no-admin-keys-except-in-everything-that-matters">G4. No admin keys, except in everything that matters</h3>
|
||||
<p>"'There are no admin keys.' The DEX, the lending market, the bridge and the dev fund contract all ship from your team. Bridges are where the admin keys live."</p>
|
||||
<p>Status: Conceded, wording fix needed.</p>
|
||||
<p>Answer: Correct. Consensus has no admin keys. The genesis apps are contracts and each will have an upgrade policy; the bridge's is the one that matters, and if it starts as a committee bridge (E7) it has keys by definition. The litepaper's sentence must be scoped to consensus and each genesis contract must publish its key policy before launch.</p>
|
||||
<p>Evidence: litepaper "Governance". Fix: overclaims list, item 46.</p>
|
||||
<h3 id="g5-no-multi-client">G5. No multi-client</h3>
|
||||
<p>"One node implementation, a rusty-kaspa fork with a zkEVM bolted on. A bug is a chain halt. Ethereum learned this in 2016."</p>
|
||||
<p>Status: Conceded, stated in the litepaper.</p>
|
||||
<p>Answer: True at launch. The litepaper says a second independent client is the development fund's first priority. The finality module is separable and the chain runs on plain GHOSTDAG without it, which contains one class of bug. A second client before mainnet is not in the 13-month plan and the litepaper should not imply it is.</p>
|
||||
<p>Evidence: litepaper "Governance", last bullet.</p>
|
||||
<h3 id="g6-stratum-v2-does-not-make-pools-unable-to-censor">G6. Stratum v2 does not make pools unable to censor</h3>
|
||||
<p>"Job declaration in Stratum v2 is optional for pools. 'Pools cannot censor' is false. And the vote key stays with the pool regardless."</p>
|
||||
<p>Status: Conceded, wording fix needed.</p>
|
||||
<p>Answer: Correct. Stratum v2 job declaration lets a hasher choose transactions when its pool supports it, and the official pool software will support it. Pools can still decline, and the vote key in the header is the pool's. The sentence becomes "Pools can be bypassed on transaction choice" with the vote-key caveat.</p>
|
||||
<p>Evidence: none in repository. Fix: overclaims list, item 45.</p>
|
||||
<h3 id="g7-the-one-click-app-is-an-update-key-over-the-network">G7. The one-click app is an update key over the network</h3>
|
||||
<p>"An app that auto-updates on ten thousand machines is an admin key. Whoever signs the update controls the miners, the wallets the app made, and the vote keys."</p>
|
||||
<p>Status: Open, policy scheduled.</p>
|
||||
<p>Answer: Correct. The update channel is a key and will be named as one: signed, reproducible builds with published hashes; no silent updates; the app refuses an update whose signature does not match the key published at genesis; the key is held in hardware and its policy published. Consensus rules never change through the app, since activation needs 90% of blocks signalling. Phase 5.</p>
|
||||
<p>Evidence: not yet.</p>
|
||||
<h3 id="g8-governance-by-hashrate-is-governance-by-two-pools">G8. Governance by hashrate is governance by two pools</h3>
|
||||
<p>"90% of blocks to activate an upgrade, 60% to spend the fund. Two pools decide both."</p>
|
||||
<p>Status: Conceded, stated in the design doc.</p>
|
||||
<p>Answer: True in the same way it is true on Bitcoin, where miner signalling activated SegWit and Taproot. The thresholds are high so that nothing passes without near-consensus. The litepaper should name pool concentration as the governance risk rather than imply every miner votes.</p>
|
||||
<p>Evidence: design doc Finality v2, Residual risks bullet 3.</p>
|
||||
<p>---</p>
|
||||
<h2 id="6-comparisons">6. Comparisons</h2>
|
||||
<h3 id="c1-vs-monero-gpus-were-excluded-on-purpose">C1. vs Monero: GPUs were excluded on purpose</h3>
|
||||
<p>"RandomX runs badly on GPUs because a GPU is already specialised hardware that most people do not own. 'Monero's idea, finished for GPUs' misses the point of Monero's idea."</p>
|
||||
<p>Status: Answered by design.</p>
|
||||
<p>Answer: Monero chose the CPU for egalitarian reasons and accepted botnets as the price. Igneum chooses the GPU because the thesis is paid proving, which CPUs cannot do, and refuses a CPU lane because of botnets. It is a different trade, and the litepaper should say "Monero's technique, applied to GPUs" rather than "finished".</p>
|
||||
<p>Evidence: litepaper "For miners", hardware paragraph. Wording: overclaims list, item 74.</p>
|
||||
<h3 id="c2-vs-monero-no-chip-in-seven-years-is-not-proof">C2. vs Monero: "no chip in seven years" is not proof</h3>
|
||||
<p>"Absence of a public RandomX ASIC is not evidence one cannot exist. Monero is also a small prize."</p>
|
||||
<p>Status: Conceded, label needed.</p>
|
||||
<p>Answer: True. "No chip publicly shipped, approximate" is the defensible phrasing. The argument from Monero is precedent, not proof, and the bounty exists because precedent is not proof.</p>
|
||||
<p>Evidence: none. Fix: overclaims list, item 17.</p>
|
||||
<h3 id="c3-vs-kaspa-you-misrepresent-them">C3. vs Kaspa: you misrepresent them</h3>
|
||||
<p>"Kaspa never claimed ASIC resistance and did not get 'captured'. It also has 10 bps in production and a GHOSTDAG you are forking. Say thank you."</p>
|
||||
<p>Status: Conceded, wording fix.</p>
|
||||
<p>Answer: Correct on both counts. kHeavyHash was built to be hardware-friendly and Kaspa's ASIC transition was expected by its community (approximate). The litepaper's "captured by specialised chips within two years, as Kaspa was" and "Kaspa's fair launch, with no utility" are unfair and will be rewritten. Igneum forks rusty-kaspa and borrows the block-rate step plan from Crescendo; the litepaper should credit both.</p>
|
||||
<p>Evidence: none in repository; <code>vendor/rusty-kaspa</code> to be cloned and cited. Fix: overclaims list, items 8, 11, 29 and 49.</p>
|
||||
<h3 id="c4-vs-kaspa-a-finality-overlay-changes-ghostdag-s-guarantees">C4. vs Kaspa: a finality overlay changes GHOSTDAG's guarantees</h3>
|
||||
<p>"GHOSTDAG's safety comes from blue work. A certificate that overrides blue work and a pruning point that never passes the latest lock are changes to the security model, not features on top."</p>
|
||||
<p>Status: Open, experiment scheduled.</p>
|
||||
<p>Answer: True. Among candidate tips (those passing through every certified checkpoint) GHOSTDAG selects by blue work under the 3,600-second merge-depth bound; a certified checkpoint removes other tips from candidacy. That is a change, and its interaction with pruning, with red blocks in the attacker's weight and with latency is exactly what the gate 3 devnet measures. The module is separable so GHOSTDAG alone remains the fallback.</p>
|
||||
<p>Evidence: design doc Finality v2, Fork choice items 1 to 4; <code>sim/results.md</code> final section.</p>
|
||||
<h3 id="c5-vs-ethereum-you-compare-inclusion-to-finality">C5. vs Ethereum: you compare inclusion to finality</h3>
|
||||
<p>"'Included in about one second, against twelve on Ethereum.' Inclusion in a DAG is not confirmation. Ethereum's twelve seconds is a slot, its finality is about thirteen minutes, and you compare your two-minute lock to that as if a two-minute lock by a pool committee were the same thing."</p>
|
||||
<p>Status: Conceded, wording fix.</p>
|
||||
<p>Answer: The numbers are approximately right and the framing is loose. Inclusion is not confirmation on either chain; Igneum's two-minute lock is a committee-of-miners finality with the limits in F4 and F6; Ethereum's finality is economic with slashing. The sentence should state both sides' mechanism, not just the minutes.</p>
|
||||
<p>Evidence: litepaper "Speed". Fix: overclaims list, item 30.</p>
|
||||
<h3 id="c6-vs-ethereum-every-one-of-your-components-is-a-research-project">C6. vs Ethereum: every one of your components is a research project</h3>
|
||||
<p>"A random-program hash with no analysis, a VDF, BLS sortition, STARK recursion on consumer cards, a 2D fee market, a DAG with EVM semantics. Ethereum has a thousand researchers and shipped these one at a time over a decade."</p>
|
||||
<p>Status: Conceded, not yet stated.</p>
|
||||
<p>Answer: True. Each component has a precedent in production somewhere (RandomX, Chia, Algorand and Ethereum for BLS and VRF, SP1, Kaspa) and no chain combines them. That is the risk the gates exist to price. The roadmap's four gates are kill points and the litepaper says so; it should also say the combination is the risk.</p>
|
||||
<p>Evidence: litepaper "Roadmap".</p>
|
||||
<h3 id="c7-vs-bitcoin-hashrate-that-follows-price-is-the-design-you-penalise-it">C7. vs Bitcoin: hashrate that follows price is the design, you penalise it</h3>
|
||||
<p>"Bitcoin's miners come and go with price and the chain is fine. Your 30-day weight under-weights every honest newcomer for a month and lets old miners lock alone for 20 days after a doubling."</p>
|
||||
<p>Status: Conceded, stated in the simulation.</p>
|
||||
<p>Answer: Correct. Table D: a new honest cohort equal to the old one reaches 0.9x its hashrate share on day 28 to 31, and the old cohort can lock alone for 20 to 23 days. The design accepts this because a doubling overnight is indistinguishable from a rental burst. Rewards are unaffected; only the vote waits. The litepaper should say "a new miner votes after a month".</p>
|
||||
<p>Evidence: <code>sim/results.md</code> table D.</p>
|
||||
<h3 id="c8-vs-ergo-ravencoin-conflux-gpu-mining-has-a-home">C8. vs Ergo, Ravencoin, Conflux: GPU mining has a home</h3>
|
||||
<p>"Ergo has been GPU-mined since 2019 with no ASIC. Ravencoin runs KAWPOW. Conflux is a GPU-mined DAG with an EVM space since 2020. 'GPU mining has no home' is false and your firsts table skips all three."</p>
|
||||
<p>Status: Conceded, not yet stated.</p>
|
||||
<p>Answer: Correct. Those chains exist and run on GPUs today (approximate). The accurate claim is that GPU mining lost its Ethereum-scale home in 2022 and that none of those chains proves its blocks or sells proving. Conflux in particular (GPU, DAG, EVM) belongs in the firsts table as the closest precedent for the combination, and the litepaper must name it.</p>
|
||||
<p>Evidence: none in repository; to be cited from their repositories. Fix: overclaims list, items 10 and 11.</p>
|
||||
<h3 id="c9-vs-aleo-you-will-centralise-the-same-way">C9. vs Aleo: you will centralise the same way</h3>
|
||||
<p>"Aleo tried proofs as consensus and the fastest prover won. You keep the lottery separate but the proving pool is still a race."</p>
|
||||
<p>Status: Open, design change scheduled.</p>
|
||||
<p>Answer: See P8. The separation protects block production from prover centralisation; it does not by itself protect the proving pool. Sortition of shards is the scheduled fix.</p>
|
||||
<p>Evidence: design doc "Existing prover networks" table, Aleo row.</p>
|
||||
<h3 id="c10-vs-boundless-and-succinct-you-cannot-bid-there-without-their-tokens">C10. vs Boundless and Succinct: you cannot bid there without their tokens</h3>
|
||||
<p>"'The Igneum miner client also bids on other proving networks.' Boundless provers post collateral in ZKC and Succinct provers stake PROVE. Your miner needs to buy their tokens to bid. And they already have home GPUs, so 'cheapest supplier' is false."</p>
|
||||
<p>Status: Conceded, wording fix.</p>
|
||||
<p>Answer: Correct on both points (approximate, from memory; verify against their current docs). The client can bid where a miner chooses to hold the collateral; the litepaper should not imply free entry, and "cheapest supplier" becomes "a supplier whose marginal cost is close to power".</p>
|
||||
<p>Evidence: design doc "Existing prover networks" table, labelled approximate. Fix: overclaims list, items 12 and 58.</p>
|
||||
<h3 id="c11-vs-everyone-firsts-that-are-not">C11. vs everyone: "firsts" that are not</h3>
|
||||
<p>"'A chain your browser verifies by itself' is phase two by your own doc. 'The GPU version never shipped' ignores KAWPOW. 'Finality immune to rentals' is 'not moved by rentals'. Three of your six firsts are wrong on day one."</p>
|
||||
<p>Status: Conceded, table to rewrite.</p>
|
||||
<p>Answer: Correct. The firsts table is rewritten in the overclaims list: each row states the closest precedent accurately, including ProgPoW/KAWPOW and Conflux, and marks the light-client row as phase two. The claim that stands is that no chain combines GPU mining, per-block ZK proofs, an EVM and a mining-weighted finality overlay, and the table should say "we know of none" and invite correction.</p>
|
||||
<p>Evidence: this ledger. Fix: overclaims list, items 4 to 9.</p>
|
||||
<h3 id="c12-vs-monero-you-borrowed-the-hash-idea-and-left-out-the-point">C12. vs Monero: you borrowed the hash idea and left out the point</h3>
|
||||
<p>"Monero's idea is privacy. You took RandomX and shipped a transparent ledger. Calling it 'Monero's idea, finished' is cheek."</p>
|
||||
<p>Status: Answered by design.</p>
|
||||
<p>Answer: Transactions on Igneum are public, as on Ethereum. Privacy features and shielded pools were considered and rejected on 3 October 2026, because the chain's purpose is an EVM whose state is proven and sold to other chains, which needs public state. The litepaper borrows one technique from Monero, the random program, and should say so plainly rather than "Monero's idea".</p>
|
||||
<p>Evidence: CLAUDE.md rules (privacy rejected). Fix: overclaims list, item 68.</p>
|
||||
<p>---</p>
|
||||
<h2 id="7-legal-and-regulatory">7. Legal and regulatory</h2>
|
||||
<h3 id="l1-it-is-a-security-under-howey">L1. It is a security under Howey</h3>
|
||||
<p>"A founder's company earns a dev fee, runs a pool and a proving business, seeds the DEX, pays 'launch grants', and the roadmap ends in 'exchange listings after'. Expectation of profit from the efforts of others, in writing."</p>
|
||||
<p>Status: Open, counsel not yet engaged.</p>
|
||||
<p>Answer: There is no sale, no premine, no allocation and no promise of return, and nothing in consensus is controlled by the team, which is the structure that regulators have treated most favourably (approximate: compare the SEC's own framework on sufficiently decentralised networks and MiCA's exemption for tokens created automatically as a reward for maintaining a distributed ledger, approximate quotation). The weak points a lawyer will circle are the ones quoted: founder-run pool and proving business, founder-seeded DEX, launch grants, and the phrase "exchange listings after". None is in consensus; all are promotional. The litepaper must drop the listing sentence and counsel must review the founder-business paragraph before v0.2. The legal entity is "offshore, parked" in the design doc, which is not an answer.</p>
|
||||
<p>Evidence: design doc "Legal" paragraph. Fix: overclaims list, items 75 and 76.</p>
|
||||
<h3 id="l2-uk-financial-promotion-rules">L2. UK financial promotion rules</h3>
|
||||
<p>"The founder is in the UK. Since October 2023 a cryptoasset promotion to UK consumers needs an authorised approver. 'The people who show up early get the most' on a .co.uk you own is a promotion."</p>
|
||||
<p>Status: Open, counsel not yet engaged.</p>
|
||||
<p>Answer: A litepaper describing how to mine a coin that does not exist is arguably not an invitation to engage in investment activity, and the regime has carve-outs for information that is not an inducement (approximate; this needs a UK opinion). Sentences that read as inducements to acquire ("show up early get the most", "half of all supply in the first two years") should be rewritten as schedule facts before v0.2. igneum.co.uk redirects to igneum.network and should keep doing so.</p>
|
||||
<p>Evidence: none. Fix: overclaims list, item 77.</p>
|
||||
<h3 id="l3-godaddy-domains-are-a-seizure-risk">L3. GoDaddy domains are a seizure risk</h3>
|
||||
<p>"Fifteen domains at a US registrar on US nameservers behind a US host. One court order and igneum.network is a parking page."</p>
|
||||
<p>Status: Conceded, mitigation scheduled.</p>
|
||||
<p>Answer: True. GoDaddy and Vercel are both US companies and have both complied with takedowns. Mitigations: an ENS or equivalent name and an IPFS mirror of the site and litepaper, the site's content hash published in the repository and in the genesis block, at least one non-US registrar for a second TLD, and the chain itself never depending on any domain (seed nodes are addresses in the client, not DNS only). Phase 5.</p>
|
||||
<p>Evidence: CLAUDE.md "Domains". Mitigation: not yet.</p>
|
||||
<h3 id="l4-paying-testnet-miners-real-money-is-a-payment-before-launch">L4. Paying testnet miners real money is a payment before launch</h3>
|
||||
<p>"'Testnet miners are paid real money for real proofs from phase five.' That is a business paying contractors in crypto across borders with no entity."</p>
|
||||
<p>Status: Open.</p>
|
||||
<p>Answer: Correct that it needs an entity, terms and tax treatment before it happens. The payments come from the customer rollup on its own chain, not from Igneum, but the arrangement is organised by the project. Counsel before phase 5.</p>
|
||||
<p>Evidence: design doc "The first six months".</p>
|
||||
<h3 id="l5-trademark">L5. Trademark</h3>
|
||||
<p>"Igneum. Have you checked EUIPO, USPTO and the UK IPO? There is no evidence you did."</p>
|
||||
<p>Status: Open.</p>
|
||||
<p>Answer: No clearance search is recorded in the repository. One is required before the name is used commercially, in all three registers and in Nice classes 9, 36 and 42, approximate. Until then the name is provisional and the litepaper should not claim otherwise.</p>
|
||||
<p>Evidence: none.</p>
|
||||
<h3 id="l6-a-permissionless-job-market-paid-in-dollars-is-money-transmission">L6. A permissionless job market paid in dollars is money transmission</h3>
|
||||
<p>"Rollups pay dollars for proofs through your contract and your client picks the winner."</p>
|
||||
<p>Status: Answered by design.</p>
|
||||
<p>Answer: At launch jobs are paid on the customer's chain, in the customer's asset, by the customer's contract, to the prover's address; Igneum operates no custody and takes no cut off-chain. When the market settles on Igneum the fee split is consensus, not a company. Counsel confirms before phase 4.</p>
|
||||
<p>Evidence: design doc "The first six months".</p>
|
||||
<p>---</p>
|
||||
<h2 id="8-launch-and-community">8. Launch and community</h2>
|
||||
<h3 id="x1-reproducible-from-the-repository-and-the-repository-is-private">X1. "Reproducible from the repository" and the repository is private</h3>
|
||||
<p>"Your site links to github.com/[second-owner-login]/igneum. It 404s. 'Every number above is measured, published, and reproducible from the repository' is false today."</p>
|
||||
<p>Status: Conceded, fix now.</p>
|
||||
<p>Answer: Correct. Either the repository goes public with the litepaper or the sentence and the GitHub link come off the site until January 2027. Publishing the bench logs, the simulator and the test report with the litepaper is the cheaper fix and the honest one.</p>
|
||||
<p>Evidence: <code>site/index.html</code> footer link; CLAUDE.md says private. Fix: overclaims list, item 22.</p>
|
||||
<h3 id="x2-get-the-miner-with-no-miner">X2. "Get the miner" with no miner</h3>
|
||||
<p>"A big button that says 'Get the miner' on a chain with no miner, no testnet and no benchmark. Vapourware CTA."</p>
|
||||
<p>Status: Conceded, fix now.</p>
|
||||
<p>Answer: Correct. The button should say what exists: "Benchmark: January 2027".</p>
|
||||
<p>Evidence: <code>site/index.html</code>. Fix: overclaims list, item 61.</p>
|
||||
<h3 id="x3-proven-by-fire-when-nothing-has-run">X3. "Proven by fire" when nothing has run</h3>
|
||||
<p>"Tagline: Proven by fire. Status: pre-specification, pre-testnet. 'Watch the chain prove itself' with nothing on the page."</p>
|
||||
<p>Status: Conceded in part, labelled.</p>
|
||||
<p>Answer: The tagline plays on "proven" as in ZK proofs and "cupel". The homepage marks every live panel "PREVIEW", "prototype" or "at testnet", which is honest. The sentence "All of it will be on this page, live" is a promise about a future testnet and should say when. The tagline stays; nothing in the ledger depends on it.</p>
|
||||
<p>Evidence: <code>site/index.html</code>. Fix: overclaims list, item 62.</p>
|
||||
<h3 id="x4-thirteen-months-with-one-founder">X4. Thirteen months with one founder</h3>
|
||||
<p>"Kaspa took years with a research team. You schedule a spec, a devnet, a finality review, a job market, a one-click app, pools, a rollup customer and a mainnet in thirteen months."</p>
|
||||
<p>Status: Conceded, stated.</p>
|
||||
<p>Answer: The roadmap is aggressive and every phase is a gate that can repeat or stop the project, which the litepaper says. The design doc budgets six people at peak and none are hired. The honest addition: dates slip, gates do not.</p>
|
||||
<p>Evidence: litepaper "Roadmap"; design doc "Team".</p>
|
||||
<h3 id="x5-1-000-independent-miners-is-a-sybil-number">X5. 1,000 independent miners is a Sybil number</h3>
|
||||
<p>"Your testnet gate is 1,000 independent miners for 30 days. One person with a script is 1,000 miners."</p>
|
||||
<p>Status: Conceded, measurement to define.</p>
|
||||
<p>Answer: Correct. "Independent" needs a definition that can be measured: distinct ASNs, distinct hardware fingerprints from the benchmark, or signed attestations from pool operators. Defined in phase 4, before the gate is tested.</p>
|
||||
<p>Evidence: <code>site/journey.json</code> phase 5 gate.</p>
|
||||
<h3 id="x6-the-one-click-app-is-a-honeypot-vector">X6. The one-click app is a honeypot vector</h3>
|
||||
<p>"An installer that creates a wallet, holds keys and mines, promoted to people who have never run a miner. Fake copies will be the first Google result. Defender flags every miner as malware."</p>
|
||||
<p>Status: Open, policy scheduled.</p>
|
||||
<p>Answer: Correct on all three. Mitigations: signed, notarised builds on every platform; reproducible builds with hashes in the repository; downloads only from the domain and the repository with the hash shown; seed phrase shown and confirmed before mining starts, with a hardware-wallet option; a published list of the only official download locations and a standing note that nobody from the project ever asks for a seed. Antivirus flagging is a known cost of shipping a miner and the app will document it. Phase 5.</p>
|
||||
<p>Evidence: not yet.</p>
|
||||
<h3 id="x7-no-community-exists">X7. No community exists</h3>
|
||||
<p>"No Discord, no forum, no mailing list, no contact address on the site, and a ledger that says 'criticisms can be submitted'. Where?"</p>
|
||||
<p>Status: Conceded, fix now.</p>
|
||||
<p>Answer: Correct. The site needs a contact route before the litepaper is shared, and the repository needs to be public or a public issue tracker needs to exist. Until then this ledger's submission line points at a route that does not exist.</p>
|
||||
<p>Evidence: <code>site/index.html</code> (no contact route). Fix: overclaims list, item 78.</p>
|
||||
<h3 id="x8-exchange-listings-as-a-roadmap-item">X8. Exchange listings as a roadmap item</h3>
|
||||
<p>"'Mainnet fair launch: Genesis with no premine, 30-day ramp, exchange listings after.' You put listings in the roadmap."</p>
|
||||
<p>Status: Conceded, fix now.</p>
|
||||
<p>Answer: Correct. No listing is arranged, promised or sought by the project. The phrase comes off the roadmap and the homepage journey.</p>
|
||||
<p>Evidence: litepaper "Roadmap", <code>site/journey.json</code>. Fix: overclaims list, item 75.</p>
|
||||
<h3 id="x9-launch-hashrate-will-be-trivial">X9. Launch hashrate will be trivial</h3>
|
||||
<p>"Day one of a GPU coin with a 10% emission ramp is a few hundred cards. Anyone with a cloud account out-mines it for the price of lunch, and your finality has no history to lean on."</p>
|
||||
<p>Status: Conceded, stated in part; see F1.</p>
|
||||
<p>Answer: True. The lottery is as attackable as any new proof-of-work chain for as long as it is small, and finality adds nothing until the window fills. The protections are the one-hour merge-depth bound, no listings before launch, and the proposed rule that no certificate forms until the window has 30 days of history. The litepaper must say that the first month is proof of work only.</p>
|
||||
<p>Evidence: <code>sim/results.md</code> table A (full weight only from day 32 to 41 from zero history). Fix: overclaims list, item 31.</p>
|
||||
<h3 id="x10-five-milestones-in-one-day">X10. Five milestones in one day</h3>
|
||||
<p>"Your Journey log shows five entries, all dated 3 October 2026. That is one day's work presented as a history."</p>
|
||||
<p>Status: Conceded, label needed.</p>
|
||||
<p>Answer: It is one day's work, and the log says the date on every line. The label "Day one" above the entries would remove the impression of theatre.</p>
|
||||
<p>Evidence: <code>site/journey.json</code>.</p>
|
||||
<p>---</p>
|
||||
<h2 id="count-by-status">Count by status</h2>
|
||||
<div class="tbl"><table><thead><tr><th>Status</th><th>Count</th><th>Entries</th></tr></thead><tbody><tr><td>Answered with evidence</td><td>2</td><td>M8, M10</td></tr><tr><td>Answered by design</td><td>14</td><td>M3, M12, F4, F9, F11, F12, F13, P9, E2, E3, E4, C1, C12, L6</td></tr><tr><td>Open, experiment or decision scheduled</td><td>19</td><td>M1, M5, M6, M11, F2, F3, F7, P3, P5, P8, E7, G7, C4, C9, L1, L2, L4, L5, X6</td></tr><tr><td>Conceded, stated in the litepaper or design doc</td><td>13</td><td>F6, F8, P2, P6, E1, E6, E8, G3, G5, G8, C7, X3, X4</td></tr><tr><td>Conceded, not yet stated (fix in the overclaims list)</td><td>32</td><td>M2, M4, M7, M9, M13, F1, F5, F10, P1, P4, P7, P10, E5, G1, G2, G4, G6, C2, C3, C5, C6, C8, C10, C11, L3, X1, X2, X5, X7, X8, X9, X10</td></tr></tbody></table></div>
|
||||
<p>Several entries carry two statuses; the table counts each entry once by its leading status. Total entries: 80.</p>
|
||||
<p>---</p>
|
||||
<h2 id="overclaims-to-remove-from-public-text-now">Overclaims to remove from public text now</h2>
|
||||
<p>Each item quotes the current text exactly and gives the replacement. Sources: <code>site/litepaper.html</code> (LP), <code>site/index.html</code> (HP), <code>site/journey.json</code> (J).</p>
|
||||
<ol><li>LP cover: "A proof-of-work chain whose miners also prove every block, run Ethereum's apps, and built so no chip can ever take your place."</li></ol>
|
||||
<p>Replace with: "A proof-of-work chain whose miners also prove every block, run Ethereum's apps, and are protected from specialised chips by a program that changes every hour."</p>
|
||||
<ol><li>LP abstract: "Mining stays open to anyone with a GPU because the mining program itself changes every hour, so there is nothing for a specialised chip to be built for."</li></ol>
|
||||
<p>Replace with: "Mining stays open to anyone with a GPU because the mining program changes every hour, so a chip built for one program is useless for the next, and a chip for the whole program space is a GPU without the graphics parts."</p>
|
||||
<ol><li>LP abstract: "Nothing in it ever needs a human to keep it that way."</li></ol>
|
||||
<p>Replace with: "No scheduled human release is needed to keep it that way. Writing new code, including an emergency fix to the proof system, is the one thing that takes a person, and it activates only on miner signalling."</p>
|
||||
<ol><li>LP firsts: "Every piece of Igneum has a precedent somewhere. The combination has none, and six of the pieces are firsts on their own."</li></ol>
|
||||
<p>Replace with: "Every piece of Igneum has a precedent somewhere. We know of no chain that combines them. The table names the closest precedent for each piece and will be corrected when shown wrong."</p>
|
||||
<ol><li>LP firsts row: "A mining program that regenerates itself, for GPUs | RandomX does it for CPUs on Monero, since 2019 | The GPU version. Designed, discussed, never shipped"</li></ol>
|
||||
<p>Replace with: "A mining program that regenerates itself, for GPUs | RandomX on Monero since 2019 for CPUs. ProgPoW, as KAWPOW on Ravencoin since 2020, changes its maths sequence every few blocks on GPUs | A full kernel per hour, a daily dataset from a 256 MB cache, a verifiable delay before the seed, and era draws from a genesis reserve"</p>
|
||||
<ol><li>LP firsts row: "Ethereum apps on a GPU-mined chain whose state cannot be wrong"</li></ol>
|
||||
<p>Replace with: "Ethereum apps on a GPU-mined chain whose state is proven every block"</p>
|
||||
<ol><li>LP firsts row: "Finality held by miners and immune to hour-long rentals"</li></ol>
|
||||
<p>Replace with: "Finality held by miners and not moved by hour-long rentals"</p>
|
||||
<ol><li>LP firsts row: "Kaspa's fair launch, with no utility."</li></ol>
|
||||
<p>Replace with: "Kaspa's fair launch."</p>
|
||||
<ol><li>LP firsts row: "A chain your browser verifies by itself | Light clients trust a committee | One proof plus one locked checkpoint, no trust"</li></ol>
|
||||
<p>Replace with: "A chain your browser verifies by itself (phase two) | Light clients trust a committee | One execution proof plus one locked checkpoint at launch; a consensus proof that makes the checkpoint self-verifying is phase two"</p>
|
||||
<ol><li>LP: "GPU mining lost its home in 2022. Igneum is the first chain built so that it can never be taken away again: not by a chip, not by a merge to proof of stake, not by a rental attack, and not by a foundation."</li></ol>
|
||||
<p>Replace with: "GPU mining lost its largest home in 2022. Igneum is built to make it hard to take away: by a chip, by a merge to proof of stake, by a rental attack, or by a foundation."</p>
|
||||
<ol><li>LP: "Every chain that tried to take it in since has either been captured by specialised chips within two years, as Kaspa was, or has stayed too small to pay the power bill."</li></ol>
|
||||
<p>Replace with: "Since then the GPU chains have gone two ways. Chips arrived, as on Kaspa, whose hash was designed to welcome them. Or the chain stayed small: Ergo, Ravencoin and Conflux still mine on GPUs at a fraction of the 2022 fleet, approximate."</p>
|
||||
<ol><li>LP: "It gives the proving market its cheapest supplier."</li></ol>
|
||||
<p>Replace with: "It gives the proving market a supplier whose marginal cost is close to power."</p>
|
||||
<ol><li>LP glance: "New program every hour, so only a GPU runs it well"</li></ol>
|
||||
<p>Replace with: "New program every hour, so a chip for last hour's program is useless"</p>
|
||||
<ol><li>LP mining: "random reads over a multi-gigabyte dataset that changes daily, so the program is bound by memory bandwidth."</li></ol>
|
||||
<p>Replace with: "random reads over a multi-gigabyte dataset that changes daily, so the program is bound by random memory access. Measured: an RTX 5090 hashes at 95 GB/s of useful 4-byte loads against 1,638 GB/s of sequential writes."</p>
|
||||
<ol><li>LP mining: "The memory footprint and instruction count are fixed and only the maths sequence is random, so no hour favours one vendor's cards and nobody gains by grinding the seed."</li></ol>
|
||||
<p>Replace with: "The memory footprint, instruction count and load count are fixed by the generator and only the maths sequence is random, so no hour favours one vendor's cards. The prototype does not yet fix the load count (40 to 232 per hash across 10,000 programs); the specification will."</p>
|
||||
<ol><li>LP mining: "checks a hash on an ordinary CPU in about ten milliseconds by simulating one warp"</li></ol>
|
||||
<p>Replace with: "checks a hash on an ordinary CPU in under ten milliseconds by simulating one warp, the gate. Measured at 0.02 ms with the prototype's cheap dataset; the 256 MB cache version is not yet measured."</p>
|
||||
<ol><li>LP mining: "Igneum runs for ever on the generator fixed at genesis, exactly as Monero has run on RandomX since 2019 with no chip built."</li></ol>
|
||||
<p>Replace with: "Igneum runs on the generator fixed at genesis, as Monero has run on RandomX since 2019 with no chip publicly shipped, approximate."</p>
|
||||
<ol><li>LP mining: "A chip that dropped the graphics parts and kept the parallel cores and the memory would gain under 2x, approximate, which is below what pays for a tapeout, and that is the same margin that has protected Monero for seven years."</li></ol>
|
||||
<p>Replace with: "Our target is that a chip that dropped the graphics parts and kept the parallel cores and the memory gains under 2x, below what pays for a tapeout. That is a design target, not a measurement. Ethash chips reached roughly 1.5 to 2x, approximate, and the standing bounty exists to test the target."</p>
|
||||
<ol><li>LP mining: "Igneum is built so that day never comes, and it does not depend on it."</li></ol>
|
||||
<p>Replace with: "Igneum is built to make that day unlikely, and does not depend on avoiding it."</p>
|
||||
<ol><li>LP vs RandomX table: "GPUs. Any card, any vendor. Bit-exact on Apple and NVIDIA, measured"</li></ol>
|
||||
<p>Replace with: "GPUs. Bit-exact on Apple and NVIDIA across two programs, 192 of 192 vectors. AMD and Intel not yet run."</p>
|
||||
<ol><li>LP vs RandomX table: "256 MB cache on a CPU, one warp under 10 ms, the measured gate"</li></ol>
|
||||
<p>Replace with: "256 MB cache on a CPU, one warp under 10 ms, the gate. Not yet measured with the cache."</p>
|
||||
<ol><li>LP vs RandomX table: "Zero years. Every number above is measured, published, and reproducible from the repository"</li></ol>
|
||||
<p>Replace with: "Zero years. Every number above is measured and logged. The repository opens with the January 2027 benchmark." Or open the repository now and keep the sentence.</p>
|
||||
<ol><li>LP: "Measured so far: the same hourly program, generated on an Apple M5 Max, compiled by Apple's Metal and NVIDIA's CUDA on an RTX 5090, produced identical hashes on both, 192 of 192 across two programs. On a 1 GB dataset the 5090 ran at about 228 million hashes a second and the Mac at about 45 million, both bound by random memory access rather than arithmetic."</li></ol>
|
||||
<p>Append: "These are prototype numbers. The prototype dataset is a closed-form function and can be shortcut about 110x by computing items instead of loading them. The 256 MB cache construction replaces it, and the numbers will be re-measured."</p>
|
||||
<ol><li>LP proving: "Proving is the one useful GPU workload that is cheaply verifiable by construction."</li></ol>
|
||||
<p>Replace with: "Proving is a useful GPU workload that is cheaply verifiable by construction."</p>
|
||||
<ol><li>LP proving: "A proof is right or it is not, and a phone can check it in milliseconds."</li></ol>
|
||||
<p>Replace with: "A proof is right or it is not. Wrapped for light clients, a phone checks it in milliseconds; the wrapping cost is a phase two measurement."</p>
|
||||
<ol><li>LP proving: "Because the proof computes the state from the ordered sequence, a block with a wrong state cannot exist."</li></ol>
|
||||
<p>Replace with: "Because the proof computes the state from the ordered sequence, no node accepts a block with a wrong state root, and full nodes also execute natively and reject a proof that disagrees with their own execution."</p>
|
||||
<ol><li>LP proving: "Shard size is set so a 12 GB card proves one shard in about 20 seconds, measured on a mid-range card before launch and raised by schedule as hardware improves."</li></ol>
|
||||
<p>Replace with: "Shard size will be set so a 12 GB card proves one shard in about 20 seconds. That number is the phase two gate and is not yet measured. It rises by schedule as hardware improves."</p>
|
||||
<ol><li>LP proving: "No other proof-of-work chain has a seat in it."</li></ol>
|
||||
<p>Replace with: "We know of no other proof-of-work chain selling proofs to other chains."</p>
|
||||
<ol><li>LP speed: "Igneum orders blocks with GHOSTDAG, the BlockDAG consensus proven on Kaspa."</li></ol>
|
||||
<p>Replace with: "Igneum orders blocks with GHOSTDAG, the BlockDAG consensus Kaspa has run in production since 2021, forked from rusty-kaspa."</p>
|
||||
<ol><li>LP speed: "A transaction is included in about one second, against twelve on Ethereum, and locked in about two minutes against roughly thirteen."</li></ol>
|
||||
<p>Replace with: "A transaction is included in the DAG in about one second (an Ethereum slot is twelve) and locked by miners in about two minutes (Ethereum reaches finality in about thirteen, approximate). Inclusion is not confirmation on either chain, and the two finality mechanisms differ: see the FUD ledger."</p>
|
||||
<ol><li>LP finality: "A locked checkpoint overrides the heaviest chain, so no amount of fresh hashrate can reorganise past it."</li></ol>
|
||||
<p>Replace with: "A locked checkpoint overrides the heaviest chain, so fresh hashrate cannot reorganise past it. Two thirds of 30-day weight can, and the first month of the chain has no history to weigh, so the chain runs on proof of work alone until the window fills."</p>
|
||||
<ol><li>LP finality: "Even an attacker who brought the whole network's hashrate would need ten days of mining in public to hold a third of the weight, and twenty days to hold two thirds."</li></ol>
|
||||
<p>Replace with: "Even an attacker producing every block on the chain, with honest miners gone, would need ten days of mining in public to hold a third of the weight, and twenty to hold two thirds. An attacker matching the honest network needs twenty days for a third and never reaches two thirds."</p>
|
||||
<ol><li>LP finality: "which is the same limit Bitcoin lives with, with a month's warning attached."</li></ol>
|
||||
<p>Keep. Add after it: "Pools carry their hashers' votes, so vote concentration equals pool concentration, and it is public."</p>
|
||||
<ol><li>LP finality: "Only miners who are present count: a key that stops signing drops out of the denominator within two hours, so a silent minority cannot freeze finality and a lock never waits for miners who have left."</li></ol>
|
||||
<p>Append: "The same two hours are the exposure to a partition or an eclipse that stops honest votes without stopping honest blocks. The gate 3 devnet measures it."</p>
|
||||
<ol><li>LP building: "Anything that runs on Ethereum runs on Igneum unchanged. Same Solidity, same bytecode, same wallets, same tools, a different chain id."</li></ol>
|
||||
<p>Replace with: "Ethereum bytecode runs on Igneum. Same Solidity, same wallets, same tools, a different chain id, and block number, timestamp, blockhash, coinbase and prevrandao defined over the ordered sequence. Contracts that depend on those are told what changed, and contracts heavy in pairing or modexp precompiles pay more here because proving cost is metered."</p>
|
||||
<ol><li>LP building: "Three things run on Igneum that run nowhere else."</li></ol>
|
||||
<p>Replace with: "Three things Igneum offers at the base layer that we know no other EVM chain offers."</p>
|
||||
<ol><li>LP building: "No other EVM chain has a prover network in its base layer."</li></ol>
|
||||
<p>Replace with: "We know of no other EVM chain with a prover network in its base layer."</p>
|
||||
<ol><li>LP building: "Trustless light clients. Because every block is proven, a phone or a browser verifies Igneum's state by checking one proof and the latest locked checkpoint. Bridges built on that need no multisig, the piece that has failed in the biggest bridge hacks."</li></ol>
|
||||
<p>Replace with: "Light clients. Because every block is proven, a phone or a browser verifies Igneum's state from one proof and a locked checkpoint it is given. Making the checkpoint itself self-verifying, which is what removes the multisig from bridges, needs a consensus proof and is phase two."</p>
|
||||
<ol><li>LP building: "Canto and Blast proved builders come for this."</li></ol>
|
||||
<p>Replace with: "Canto's contract-secured revenue and Blast's gas sharing showed builders respond to it."</p>
|
||||
<ol><li>LP building: "Stablecoins at genesis. USDC and USDT bridged through the proof bridge, canonical versions on Igneum, the way Arbitrum and Base launched."</li></ol>
|
||||
<p>Replace with: "Stablecoins. USDC and USDT bridged to Igneum as canonical versions. Whether the genesis bridge is proof-verified or committee-attested is decided in phase 4 and will be labelled."</p>
|
||||
<ol><li>LP builders: "And the only user base a new chain has ever had that did not have to be paid to arrive."</li></ol>
|
||||
<p>Delete.</p>
|
||||
<ol><li>LP builders: "The afternoon is the hard part."</li></ol>
|
||||
<p>Delete.</p>
|
||||
<ol><li>LP governance: "Igneum is governed by the people who power it, and by nobody else."</li></ol>
|
||||
<p>Replace with: "Igneum is governed by the hashrate that powers it. Pools carry their hashers' votes, so pool concentration is the governance risk, and it is public."</p>
|
||||
<ol><li>LP governance: "Pools cannot censor. Igneum uses Stratum v2 from day one, so each miner chooses its own transactions even inside a pool."</li></ol>
|
||||
<p>Replace with: "Pools can be bypassed on transaction choice. Igneum ships Stratum v2 job declaration from day one, so a miner chooses its own transactions when its pool supports it. Vote keys stay with the pool."</p>
|
||||
<ol><li>LP governance: "There are no admin keys. Nothing in consensus can be paused, upgraded or reversed by any key."</li></ol>
|
||||
<p>Replace with: "There are no admin keys in consensus. Nothing in consensus can be paused, upgraded or reversed by any key. The genesis apps and the development fund contract publish their own key policies before launch; the bridge's is the one to read."</p>
|
||||
<ol><li>LP governance: "Upgrades need a second independent node client, funded from the development fund as its first priority."</li></ol>
|
||||
<p>Replace with: "At launch there is one node client. A second independent client is the development fund's first priority and is not in the 13-month plan."</p>
|
||||
<ol><li>LP miners ask: "Kaspa said ASIC resistant too, and IceRiver shipped a chip in eighteen months."</li></ol>
|
||||
<p>Replace with: "Every GPU coin got a chip in the end. Kaspa got one in about eighteen months." And in the answer: "Kaspa's hash was one fixed function, designed to be hardware-friendly, and simple enough to put on silicon."</p>
|
||||
<ol><li>LP miners ask: "Correct, and it is the first thing the external review is paid to break. The specification is public, the review is gate 3 with named reviewers and a bounty"</li></ol>
|
||||
<p>Replace with: "Correct, and it is the first thing the external review will be paid to break. The specification will be public, reviewers will be named and paid before gate 3, and a bounty is attached. Until then every finality claim here is a design claim backed by a simulation without a network in it."</p>
|
||||
<ol><li>LP miners ask: "What Igneum can promise is that its miners have the lowest cost in that market"</li></ol>
|
||||
<p>Replace with: "What Igneum can promise is that its miners' marginal cost in that market is close to power"</p>
|
||||
<ol><li>LP not claimed: "A chip is impossible. No. A chip is pointless, because the target moves before it ships."</li></ol>
|
||||
<p>Replace with: "A chip is impossible. No. A chip is a bad bet, because the target moves before it ships."</p>
|
||||
<ol><li>LP not claimed: "That is harder than attacking Bitcoin, where a majority can reorganise at once"</li></ol>
|
||||
<p>Replace with: "That is a different limit from Bitcoin's, where a majority can reorganise at once: Bitcoin's defence is the cost of the majority, Igneum's is the month in public."</p>
|
||||
<ol><li>LP economics: "It is gas, it is the proving currency, and it is what every outside customer pays in. Part of every payment is burned."</li></ol>
|
||||
<p>Replace with: "It is gas and the proving currency, and part of every payment on Igneum is burned. Outside customers pay in their own currency on their own chain at launch; settlement in IGN with a 10% burn follows when the proof bridge lets Igneum see the payment."</p>
|
||||
<ol><li>LP economics and governance: "5% of gas and 5% of external job fees go to a development fund"</li></ol>
|
||||
<p>Replace with: "5% of the priority fee and 5% of external job fees go to a development fund"</p>
|
||||
<ol><li>LP economics: "Nearly a quarter of all supply is mined in the first year and half in the first two, so the people who show up early get the most."</li></ol>
|
||||
<p>Replace with: "Nearly a quarter of all supply is mined in the first year and half in the first two. Emission halves every two years for ever."</p>
|
||||
<ol><li>LP miners: "so Igneum miners have the lowest marginal cost in the proving market and are the last provers to switch off"</li></ol>
|
||||
<p>Replace with: "so Igneum miners' marginal cost in the proving market is close to power, which is an edge over data-centre provers and nothing more"</p>
|
||||
<ol><li>LP miners: "NVIDIA and AMD both work, because the mining program is generated for the architecture both share"</li></ol>
|
||||
<p>Replace with: "NVIDIA is measured bit-exact against Apple. AMD is the next run. The program is generated for the warp architecture all three share."</p>
|
||||
<ol><li>LP miners: "The dataset starts at 2 GB and grows by half a gigabyte a year, so a 4 GB card mines for about four years and an 8 GB card for more than a decade, approximate."</li></ol>
|
||||
<p>Keep (labelled). HP equivalent "Any card with 4 GB today, 8 GB for the next decade." add "approximate".</p>
|
||||
<ol><li>LP roadmap: "Genesis with no premine, 30-day ramp, exchange listings after"</li></ol>
|
||||
<p>Replace with: "Genesis with no premine, 30-day ramp. No listing is arranged, promised or sought by the project." Same change in J phase 6.</p>
|
||||
<ol><li>HP hero: "The first chain built so no chip can ever take your place."</li></ol>
|
||||
<p>Replace with: "A chain built so a chip gains too little to take your place."</p>
|
||||
<ol><li>HP: "Get the miner" (button, twice)</li></ol>
|
||||
<p>Replace with: "Benchmark: January 2027"</p>
|
||||
<ol><li>HP: "All of it will be on this page, live."</li></ol>
|
||||
<p>Replace with: "All of it will be on this page, live, from public testnet in August 2027."</p>
|
||||
<ol><li>HP economics: "Not one coin to a founder, a fund or a stake."</li></ol>
|
||||
<p>Replace with: "Not one coin of emission to a founder, a fund or a stake. The official client carries a 1% dev fee to the founder's company, as every GPU miner does; any client without it is welcome."</p>
|
||||
<ol><li>HP: "A mining program that rewrites itself every hour, so no chip can be built for it."</li></ol>
|
||||
<p>Replace with: "A mining program that rewrites itself every hour, so a chip built for one hour is useless the next."</p>
|
||||
<ol><li>HP: "No premine, no stake, no foundation, no merge to anything else, ever."</li></ol>
|
||||
<p>Replace with: "No premine, no stake, no foundation, no merge to proof of stake."</p>
|
||||
<ol><li>HP footer and nav: "GitHub" link to a private repository.</li></ol>
|
||||
<p>Make the repository public or remove the link until it is.</p>
|
||||
<ol><li>HP vs RandomX table: identical to LP items 20 to 22; same replacements.</li></ol>
|
||||
<ol><li>HP: "RandomX proved that a random program beats a chip when the only hardware that runs it well is the hardware everyone already owns."</li></ol>
|
||||
<p>Replace with: "RandomX has kept chips off Monero since 2019 by making the program random, so the hardware everyone already owns runs it best, approximate."</p>
|
||||
<ol><li>LP vs RandomX: "Monero's idea, finished for GPUs"</li></ol>
|
||||
<p>Replace with: "Monero's technique, applied to GPUs"</p>
|
||||
<ol><li>LP roadmap: "Each gate is a measurement published whether it passes or fails. Miss it and the phase repeats or the project stops."</li></ol>
|
||||
<p>Keep. Add under the table: "Dates slip. Gates do not."</p>
|
||||
<ol><li>LP mining table: "Ethereum's growing dataset killed Bitmain's E3 miner in 2020 this way, with nobody doing anything"</li></ol>
|
||||
<p>Replace with: "Ethereum's growing dataset ran Bitmain's E3 out of memory in 2020, approximate, with nobody doing anything"</p>
|
||||
<ol><li>LP builders: "Stablecoins at genesis" heading and "the way Arbitrum and Base launched"</li></ol>
|
||||
<p>Covered by item 40; remove "at genesis" until E7 is decided.</p>
|
||||
<ol><li>LP cover status line: "Status pre-specification, pre-testnet"</li></ol>
|
||||
<p>Keep. Add: "Method: designed and prototyped by the founder with AI assistance; measurements reproducible from the logs; external review before gate 3."</p>
|
||||
<ol><li>LP "Who are you?" answer</li></ol>
|
||||
<p>Append: "The founder's name is on every commit. No cryptographer is yet hired; the design doc budgets one for phases one and two."</p>
|
||||
<ol><li>LP, every finality number quoted from the simulation (ten days, twenty days, two hours)</li></ol>
|
||||
<p>Add once, in the Finality section: "Day counts come from a model with no network latency, no DAG and no partitions (sim/results.md). The gate 3 devnet replaces them with measurements."</p>
|
||||
<ol><li>LP "Fair launch, announced": "Pools live on testnet."</li></ol>
|
||||
<p>Append: "The first month of mainnet runs on proof of work alone while vote weights build; exchanges are told to treat it so."</p>
|
||||
<ol><li>LP, anywhere a launch sentence reads as an inducement to acquire ("the people who show up early get the most", "Half of the 4 billion cap is mined in the first two years" as a chart caption)</li></ol>
|
||||
<p>Rewrite as schedule facts without the "so" clause (item 54), pending a UK promotions opinion.</p>
|
||||
<ol><li>HP and LP: no contact route anywhere.</li></ol>
|
||||
<p>Add one before sharing the litepaper, and point the FUD ledger's submission line at it.</p>
|
||||
<ol><li>LP "What Igneum does not claim"</li></ol>
|
||||
<p>Add three items: "A memory-hard prototype. Not yet: the current dataset can be shortcut 110x; the 256 MB cache replaces it." "Finality in the first month. Not until the 30-day window has history." "A cryptography team. Not yet; external reviewers are named before gate 3."</p></article>
|
||||
</div>
|
||||
<footer>© 2026 Igneum. Generated from the repository at build time. Nothing on this page is an offer to sell anything.</footer>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
5
site/package.json
Normal file
5
site/package.json
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
{
|
||||
"name": "igneum-site",
|
||||
"private": true,
|
||||
"scripts": { "build": "node build.mjs" }
|
||||
}
|
||||
Loading…
Reference in a new issue