I agree that SHA256 collision resistance stops one specific kind of cheating: swapping the server seed after its hash has been published. That’s correct.
But that’s not why there is a lack of trust.
All your maths and verification talk about a revealed unhashed server seed. Your explanation shows that once the unhashed server seed is revealed, past results can be reproduced and verified. That proves the results are consistent and cannot be changed after the fact, but it doesn’t show when the outcomes were actually generated.
It doesn’t prove that outcomes were precomputed before betting started. It doesn’t prove nonces 1 through ∞ existed ahead of time. It doesn’t prove results weren’t generated on demand, one bet at a time. It doesn’t prove the server seed wasn’t used only when bets actually happened. And it doesn’t prove that the infinite future sequence existed before the seed was revealed.
There’s no way for this verification to tell the difference between:
a system where all outcomes were fixed in advance (all results generated when the seed was created, before the hashed seed is revealed), and
a system where each result is calculated live per bet and infinite future results are generated once the seed is revealed.
Both systems produce the exact same verification output.
So again, SHA256 stops seed swapping. It doesn’t stop real-time outcome generation. Provably fair shows results weren’t changed after the fact, but it doesn’t prove future results existed ahead of time or that outcomes couldn’t be influenced at the moment each bet was placed.
While the math confirms consistency after the reveal, it doesn’t remove the need to trust the system while you’re placing each bet. The verification only shows results weren’t changed afterward; it doesn’t prove they were set in advance.