In early designs, Hemis explored using paired Probabilistic Transactions (PTXs): two players would each broadcast a half‑transaction to the network. When both halves were present in the mempool, nodes would combine them into a single “full” transaction. The Gamemaster network would then apply a random number to select the winner. This design aimed to avoid a second transaction by forming the bet directly from two halves.
However, this approach introduced several challenges:
1. Mempool congestion and griefing. Single halves could sit unpaired indefinitely. Attackers could spam unmatched halves, bloating the mempool and forcing nodes to perform expensive pairing logic.
2. User experience. The second participant might see the first half’s details and decline to match if the bet was unfavourable. There was no way to enforce timely matching.
3. Complex timeouts and refunds. Each half would need an expiry and refund path if no match occurred, leading to complicated scripts and edge cases.
4. Front‑running risk. Miners could choose which halves to include in a block, subtly influencing which bets settle and which don’t.
5. Implementation burden. Handling partial transactions required new mempool code, pairing logic and state management. With limited resources and the loss of lead developers, this complexity posed a serious risk to delivery.
New PTX design and reasons for the shift
The consensus‑level PTX design discards the idea of pairing transactions in the mempool and instead embeds all participants’ commitments in a single transaction. Key differences:
| Aspect | Original paired PTX | New consensus‑level PTX | Rationale |
|---|---|---|---|
| Number of user transactions | Two half‑transactions per game; combined in mempool | One fully formed PTX (contains all inputs/outputs) | Simplifies UX; players sign once. |
| Mempool behaviour | Mempool must match halves and track unpaired transactions | PTXs are standard transactions; no pairing | Avoids mempool congestion and griefing. |
| Randomness | Gamemaster selects winner upon combination | Randomness derived at block confirmation via VRF | Eliminates possibility of withholding matches to bias outcomes. |
| Refunds/timeouts | Each half needs a refund if unmatched | PTXs include an expiryHeight; if not mined by then, funds can be reclaimed | Simpler scripts and wallet logic. |
| Implementation effort | Requires pairing logic in txmempool.cpp and new transaction assembly code | Adds a new transaction type and modifies consensus validation | Uses well‑understood patterns from transaction versioning and consensus upgrades. |
| Security concerns | Vulnerable to spam and front‑running in mempool | Security depends on VRF and honest majority of Gamemasters | More predictable and easier to audit. |
Why VRF‑based consensus random is better
- No trust in peers: random numbers come from the Gamemaster quorum’s VRF, not from a player committing a secret. There is no incentive to abort a reveal as in commit–reveal systems.
- Unpredictable until block is produced: by committing to a future block height, participants cannot know the result beforehand and miners cannot choose the block hash to influence the game.
- Immediate settlement: the game resolves when the transaction is mined; players do not need to wait for a second reveal or a mempool pairing event.
Implementation highlights for the tech team
1. Remove pairing code paths: there is no need to implement logic that watches the mempool for matching halves. Focus on normal transaction handling.
2. Add a PTX flag and extended serialization: modify `CTransaction` to signal PTX transactions and add a structure to hold ranges and seed/expiry heights.
3. Store VRF values in block headers: update the Gamemaster (LLMQ) code to include a `nVrfOutput` field in `CBlockHeader` and `CBlockIndex`. Expose an API `llmq::GetVrfForHeight()`.
4. Consensus checks: implement `CheckProbabilisticTx()` to compute the hash of the PTX ID and VRF output, map it to a range and verify that the output chosen in the transaction matches this range.
5. Wallet functions: create a helper in the wallet to build a PTX, calculate the range boundaries based on weights, compute a house edge and sign the transaction. GUI and RPC layers need new calls.
6. Activation: wrap PTX enforcement behind a version bit (similar to Dash’s Spork or Bitcoin’s BIP9). Until activation, PTXs should be considered invalid and not relayed.
The move to a consensus‑level PTX not only simplifies the implementation but also offers a better user experience and more robust security. The tech team should focus on clear modular changes, transaction format, consensus checks, VRF plumbing and wallet support rather than mempool pairing logic. Extensive testing and security review are essential, but the underlying components are similar to existing transaction and LLMQ mechanisms, making the task manageable for a small team.