Commitments and hashing: in-language primitive, or host-side?

[gmikeyg]

Purpose: Provably fair games, sealed bids and similar "commit now, reveal later" designs need a binding commitment, and Tau has no hash. Knowing whether one is planned, or that the answer is "the host hashes and feeds the result in", decides how we design those products.

Commit-reveal designs (provably fair games, sealed-bid auctions) need a binding commitment: a player publishes H(seed) first and reveals seed later, and a rule checks that they match. Tau has bitvector arithmetic but no hash, so today the host would compute H and feed the result in as an input, and the spec has to trust the host for that step.

Is a hash or commitment construct planned for the language? If not, what is the recommended pattern on Tau Net: host-computed digests passed as custom inputs, or something else?

[gmikeyg]

Following up with the concrete case behind this question, in case it helps decide.

We built a commit/reveal/beacon round for fair random draws (dispute panels, reviewer selection, audit samples) as a single Tau spec and tested it on devel a9ca5c8: participants commit, then reveal, then one public random value seals the seed, and the panel is drawn from the sealed seed by reject-and-redraw. Proofs over every step show the seed cannot change once sealed, the last revealer cannot steer it, picks are distinct eligible members, and the round never reaches "no solution"; live rounds with pools up to 1,000 members matched an outside model step for step.

Three places still rely on the host, all because there is no hash:

1. Reveal check. A reveal must match the participant's earlier commitment H(value). Today the host computes H, compares, and feeds the spec a 1-bit "matched" flag; the spec can only refuse reveals whose flag is 0.
2. Frozen member list. To draw from a published list longer than one bitvector mask, the spec freezes a 256-bit digest of the list and its length before any reveal, then draws positions 0..T-1. Tau can freeze the digest but cannot check it, so an auditor has to recompute it outside Tau.
3. Larger samples from one seed. An audit that needs more random numbers than one sealed seed holds would normally stretch the seed with a hash-based generator (election audits use SHA-256 this way, so anyone can replay the sample). Without a hash the stretching is host-side: replayable, but not checked by the spec.

We realise a built-in hash would put a function designed to be hard to invert in front of the solver, so it may be a poor fit for sat/valid. For our use it would be enough if the value were computed on concrete inputs at run time and treated as opaque in proofs.

Questions:

• Is a hash or commitment construct planned for the language (main or devel)?
• If not, is "the host computes the digest and feeds the spec a verified flag" the intended pattern? On Tau Net that flag would need to come from the node rather than the transaction sender; we asked about that in Capability request: attested inputs (third-party signed claims verified by the node) tau-testnet#62 (attested inputs).