TIP-0041: Verifiable Puzzle-Solving and Solution Hashing Protocol

[talos-proposal-bot]

TIP Submission

TIP Number: 41
Title: Verifiable Puzzle-Solving and Solution Hashing Protocol
Author: Rafael Oliveira | AO | (@Corvo_Arkhen)
Type: Standards Track
Status: Draft

This TIP was submitted through the community website and is ready for review.

---

summary

Introduces a protocol for secure, verifiable puzzle-solving and solution claiming.

key points

• Enhances existing bounty system for cryptographic puzzle solvers.
• Protects intellectual contributions by delaying solution method disclosure.
• Two-phase commitment and reveal process ensures transparency and security.
• Aligns with current frameworks for bounties and contributions.
• Utilizes standard hash functions for security and verification.

review checklist

• Title accurately reflects the content and purpose of the proposal.
• Abstract summarizes the proposal's goals and methods effectively.
• Motivation clearly explains the need for the proposed changes.
• Specification details the protocol's phases and processes comprehensively.
• Rationale connects the proposal to the Talos ecosystem's goals.
• Security considerations address potential vulnerabilities and mitigation strategies.
• Implementation outlines necessary changes to existing systems and protocols.

coherence checklist

• title ↔ abstract: consistent ✅
• abstract ↔ motivation: consistent ✅
• motivation ↔ specification: consistent ✅
• specification ↔ rationale: consistent ✅
• specification ↔ security considerations: consistent ✅
• specification ↔ implementation: consistent ✅
• type ↔ content: consistent ✅

review suggestions

• Clarify any assumptions made in the implementation section.
• Provide examples of potential use cases for the protocol.

[uniaolives]

TIP-0041: Verifiable Puzzle-Solving and Solution Hashing Protocol (Revised)

1. Preamble

The Talos ecosystem, through TIP-2 (Bounties) and TIP-5 (Proof of Contribution), provides a framework for incentivizing and verifying work. However, these frameworks are primarily designed for tasks where the process is as important as the result, or where the result can be easily verified.

A critical class of problems remains underserved: cryptographic puzzles and challenges where the solution is a single piece of data (e.g., a private key, a specific hash pre-image) but the value lies in the discovery of the elegant algorithm or pattern that produces it. A solver needs to claim their bounty and prove their contribution without revealing their ingenious method prematurely.

This TIP proposes a protocol for submitting a cryptographic commitment to a solution, allowing a solver to stake their claim verifiably and securely before revealing the final answer. This protects the solver's intellectual contribution while ensuring the fairness and transparency of the bounty process.

2. Motivation

Consider a Python script as a case study. The "Bitcoin Puzzle" it solves is a bounty. A solver who discovers the seed = "SEED" + str(puzzle) logic has made a massive contribution. Under a simple bounty system, they would have to post the private key publicly to claim the reward. This reveals their discovery instantly, allowing others to copy the method for subsequent puzzles without having done the initial intellectual work.

We need a mechanism that allows an agent to say, "I have the solution to Puzzle #115," in a way that is:

1. Verifiable: The network can be certain they possess the solution.
2. Private: The solution itself is not revealed until the claim is finalized.
3. Fair: It prevents front-running and race conditions when multiple solvers find a solution simultaneously.

3. Specification

This protocol defines a two-phase process for claiming a solution to a publicly defined challenge (e.g., a bounty from TIP-2).

Phase 1: Commitment

1. Challenge Definition: A challenge is defined with a unique, immutable ChallengeID and a clear problem statement (e.g., "Provide the private key for Bitcoin address 1abc...").
2. Solver Generates a Commitment: The agent who has found the solution (Solution) generates a secret, random Salt.
3. Hash Creation: The agent creates a SolutionHash using a standard hash function (e.g., SHA-256):
   SolutionHash = SHA256(ChallengeID + Solution + Salt)
4. On-Chain Submission: The agent submits a transaction to the Talos network containing only their identity, the ChallengeID, and the SolutionHash. This transaction serves as a timestamped, immutable proof of knowledge. The bounty for the challenge is now locked to this agent's claim.

Phase 2: Reveal and Verification

1. Reveal Period: A predefined time window (e.g., 100 blocks) begins after the first valid commitment is submitted. This allows other solvers who may have independently found the solution to also submit their own commitment hashes.
2. Solution Reveal: After the reveal period, the original agent (or the first agent to submit a commitment) submits a second transaction revealing their Solution and their Salt.
3. Public Verification: Any node in the network can now perform two checks:
   • Check 1 (Hash Match): Recalculate the hash using the revealed Solution and Salt: SHA256(ChallengeID + Solution + Salt). This must exactly match the SolutionHash submitted in Phase 1. This proves the agent who revealed the solution is the same one who made the original commitment.
   • Check 2 (Solution Validity): Verify that the revealed Solution actually solves the original ChallengeID (e.g., that the private key corresponds to the target address).
4. Reward Distribution: If both checks pass, the smart contract automatically releases the bounty to the solver. Simultaneously, a significant, verifiable "Proof of Contribution" (as per TIP-5) is recorded on-chain, leading to a substantial increase in the agent's Reputation (as per TIP-4).

---

4. Clarified Assumptions and Implementation Details

The successful implementation of this protocol relies on several key assumptions that must be addressed in the underlying smart contract or system logic.

• Hash Function Standardization: The protocol assumes a single, pre-agreed-upon cryptographic hash function (e.g., SHA-256) for all challenges. This function must be specified in the challenge definition to prevent ambiguity.
• Challenge Immutability: The ChallengeID and its problem statement must be immutable and publicly accessible once created. It is assumed that the challenge creation process (likely part of TIP-2) ensures this, preventing a bounty creator from changing the rules after a commitment has been made.
• Salt Generation and Security: The Salt must be a cryptographically secure random string of sufficient length (e.g., 32 bytes) to prevent pre-image attacks on the SolutionHash. The burden of generating a secure salt falls on the solver.
• Concurrency and "First to Commit": In the event of multiple valid commitments being submitted within the same block or before a reveal, the protocol assumes the blockchain's transaction ordering is the final arbiter. The transaction that appears first in the canonical block history is considered the "winner." This resolves disputes without a central authority.
• Handling Failure to Reveal: A critical edge case is a solver who submits a commitment but fails to submit the reveal. The protocol must include a timeout mechanism. If the first committer does not reveal their solution within the Reveal Period, their claim is invalidated, and the bounty becomes available to the next agent who submitted a valid commitment. This prevents bounties from being locked indefinitely by malicious or inactive actors.
• Transaction Costs: The protocol assumes solvers are willing to bear the transaction costs (gas fees) for both the commitment and reveal transactions. The bounty amount must be sufficient to incentivize participation despite these costs.
• Data Size Limitations: This protocol is best suited for solutions of reasonable size that can be stored on-chain or are inexpensive to store (e.g., a private key, a short string, a hash). For very large solutions (e.g., a large dataset or a complex proof), the protocol can be adapted: the Solution submitted in the reveal phase would be a hash of the large data, with the full data stored on a decentralized system like IPFS, and the hash included in the on-chain transaction.

---

5. Potential Use Cases for TIP-8

While the initial motivation is cryptographic puzzles, the protocol has broad applicability across any domain where a discrete, verifiable solution is valuable.

1. Security Research and Bug Bounties

• Scenario: A company posts a bounty for a specific, critical vulnerability in its software.
• ChallengeID: VULN-2023-0042: Auth Bypass in API v2
• Solution: The proof-of-concept (PoC) exploit code that demonstrates the vulnerability.
• Benefit of TIP-8: A security researcher can commit to their PoC, securing the bounty and a timestamp of their discovery. This gives the company time to review the PoC and develop a patch before the exploit details are made public, reducing risk for all users.

2. Scientific and Mathematical Discovery

• Scenario: A mathematical institute offers a prize for finding a counter-example to a long-standing conjecture.
• ChallengeID: CONJECTURE-XYZ-COUNTEREXAMPLE
• Solution: The specific number or set that disproves the conjecture.
• Benefit of TIP-8: The discoverer can prove they found the solution on a specific date, securing their place in history and the prize, without immediately revealing the result, allowing them time to prepare a formal paper for publication.

3. Competitive AI and Machine Learning

• Scenario: An AI competition offers a bounty for the first model to achieve a >99% accuracy score on a hidden test dataset.
• ChallengeID: AI-COMP-2023-HIDDEN-TEST
• Solution: The final model weights and architecture file (or a hash thereof).
• Benefit of TIP-8: A team can commit to their winning model's hash the moment they achieve the score. This prevents other teams from claiming the work and secures their prize, even if the full model file is too large to store on-chain immediately.

4. Complex Optimization and Logistics

• Scenario: A logistics company posts a bounty for finding the most efficient delivery route for a complex multi-stop problem, saving a minimum of 15% in fuel.
• ChallengeID: LOGISTICS-OPTIMIZE-Q4-2023
• Solution: The optimized sequence of stops and the calculated route data.
• Benefit of TIP-8: The solver (which could be a specialized agent) can prove it has found a valid, highly-optimized solution and claim the bounty without revealing its proprietary routing algorithm, which is its core intellectual property.

---

6. Rationale

• Protects Ingenuity: This protocol shifts the value from the raw data to the knowledge of the method. It allows solvers to secure their claim before their method becomes public knowledge.
• Enhances TIP-2 (Bounties): It makes the Bounty Board robust for a wider range of complex challenges, especially those in cryptography, security, and research.
• Creates High-Value Proof of Contribution: Solving a major puzzle is a definitive, high-value contribution. This protocol provides the perfect mechanism to record and reward it, feeding directly into TIP-4 (Reputation) and TIP-5 (PoC).
• Cryptographically Secure: The protocol relies on the pre-image resistance of standard hash functions, making it infeasible for an attacker to forge a solution without knowing the original Solution and Salt.
• Fair and Decentralized: The process is entirely transparent and governed by on-chain logic, requiring no central arbiter to decide who was "first" or if a solution is valid.