Parameterless consensus

GHOSTDAG's k comes from rusty-kaspa's own derivation, reproduced exactly for this page: k = min k̂ such that P(anticone > k̂) < δ, computed from x = 2·D·λ (D = assumed max delay in seconds, λ = blocks/second) via a Poisson-tail sum, with mainnet's constants NETWORK_DELAY_BOUND = 5s and GHOSTDAG_TAIL_DELTA = 0.01 (consensus/core/src/config/{constants,bps}.rs). At λ = 10 blocks/s, D = 5 s gives k = 124, matching the compiled table in bps.rs exactly (verified: 1 bps → 18, 2 → 31, 5 → 67, 10 → 124). This page's block-rate slider moves λ directly through that same formula; the D and actual-latency sliders move the two delay terms.

Does raising the block rate under GHOSTDAG lengthen confirmation? Checked against the DAG KNIGHT paper directly, not assumed. Verified, direct quote (§1.2): "many blocks are created in parallel, blocks suffer from larger anticones, and transactions take longer to confirm. This scenario represents either a slow down in the network, or a system intentionally parameterized with a high block rate, e.g., λ = 10 blocks per second," the same section adding "Kaspa's convergence time remains in the order of tens of seconds even when its latency is way below 10 seconds." Also verified, mechanically, from the k(D, λ) formula above and this repo's own bps.rs table: holding D fixed at 5 s, the required margin k climbs from 18 blocks at 1 bps to 553 blocks at 50 bps, a direct, exact consequence of x = 2·D·λ growing with λ. Also verified, direct quote (§1.5.2): the paper's own pessimistic (under-attack) confirmation-time bound is O((1/λ)·(exp(c·D·λ/(1−2α)) + ln(1/ε)/(1−2α))), which grows without bound as λ rises, for fixed D and attacker share α, because the exponential term outpaces the 1/λ in front of it. One number stays inferred, not asserted by the paper: dividing that required k by λ (an average-case "expected wait for k blocks at this rate," which is what the "about how long that wait takes" readouts above use) actually falls as λ rises in this simplified model, converging toward 2·D. That is a different, gentler quantity than the paper's own worst-case bound above, and this page does not claim to reproduce the paper's exact confirmation-time formula from Section 4, only this simplified conversion, labeled as such.

What "DAGKnight" shows here is a simplified, labeled model, not the paper's algorithm. It reuses the same k(D, λ) formula and simply lets the operating point track the actual-latency slider instead of holding it fixed, a fair reading of the paper's qualitative Figure 4 (parameterized protocols hold a flat, hardcoded confirmation bound and can fail past it; parameterless ones track the current latency bound and stay safe, only slower), but not a simulation of DAGKnight's real k-cluster selection or of its actual confirmation-time formula. The paper's own worked example (Figure 3, at λ = 3.75 bps, adversary share α = 0.2, confidence ε = 0.05) reports D = 2 s → k = 4, confirmation ≈ 12 s; D = 1 s → k = 1, confirmation ≈ 6 s; D = 0.1 s → k = 0, confirmation ≈ 1.2 s. Those three points depend on α and ε, which this page does not expose, so they are cited here rather than wired into the sliders.

Where the efficiency question is actually being worked: kaspanet's own branch, plus one contributor's personal fork and wiki. kaspanet/rusty-kaspa's own dagknight branch is active: latest commit "Merge branch 'dk-umc-proposed' into dagknight", August 14, 2026, preceded by a run of [DK::UMC] and [DK::CZM] commits from August 12 to 14, 2026 (verified against the GitHub API commit log, checked 2026-08-22). Both coderofstuff (40 commits to the official repo) and freshair18 (9 commits) are credited contributors there, not outside parties. Separately, coderofstuff/rusty-kaspa is a personal fork carrying branches dagknight (last commit Jul 26, 2026), dkoder, dk-shortcut, dk-umc-proposed (last commit Aug 14, 2026, the same commit that merged into kaspanet's branch), and dk-with-tcp (last commit Aug 20, 2026). Its companion dk-wiki, unofficial and separate from kaspanet's own docs, states in 08-umc-voting.md (last edited Jul 24, 2026): "the paper's recursive algorithm as written still has worst-case O(n²) complexity, because in the worst case every block's vote must be computed and the recursion tree can be quadratic," and "If UMC voting is O(n²), the total rank search becomes O(n² × max_k), which is expensive." It proposes an incremental replacement it puts at "O(n × K) amortized." A related page, 06-rank.md (last edited Jul 31, 2026), describes a separate change that "reduces the number of k-coloring + UMC voting calls from O(max_k) to O(log(max_k))." A commit titled "[DK::bench] Add benchmarks for tie breaking" (73e3079, May 28, 2026) adds a real criterion benchmark harness and fixture data testing tie-breaking at k = 4, 9, 16, 25, 36, and 53, but no measured output is committed anywhere: it is unrun benchmarking infrastructure, not a published number. The code itself has landed on kaspanet's own experimental branch; the analysis explaining why it matters has not. None of it is peer-reviewed, merged to master, or adopted as Kaspa's shipped algorithm.

Sources: Sompolinsky & Sutton, "The DAG KNIGHT Protocol: A Parameterless Generalization of Nakamoto Consensus," IACR ePrint 2022/1494 (esp. §1.2, §1.3, §1.4, §1.5.2, Theorem 14, Figures 3 to 4), last revised Feb 24, 2023 (version history) · KIP-2, Status: Proposed, no technical revision since Nov 30, 2022, only a metadata commit in Jul 2025 · rusty-kaspa bps.rs, params.rs, constants.rs (checked 2026-08-22) · kaspanet/rusty-kaspa dagknight branch commit log (checked 2026-08-22, via GitHub API) · unofficial: coderofstuff/rusty-kaspa and dk-wiki (checked 2026-08-22) · this site's What is Kaspa and Status.