deciders

Deciders

Purpose and Structure

Purpose

Deciders in the Haircomb system play a crucial role in determining the outcomes of transactions or actions that require cryptographic verification. Their primary function is to decide which of the possible destinations in a Merkle Segment will receive the COMB. Deciders act as cryptographic keys, but with enhanced flexibility. They are designed to sign small (16-bit) decisions, allowing for multiple choices within a system. By making and committing decisions, Deciders ensure that the transaction routing process is secure, verifiable, and transparent. They contribute to maintaining the integrity of the Haircomb ecosystem by preventing double spending or double decision-making.

In essence, Deciders provide a mechanism for trusted third-party arbitration in trades or multi-party decisions, adding a layer of trust to transactions and creating a decentralized decision-making process.

Structure

The structure of a Decider consists of a chain of cryptographic keys, with each key (or Decider) holding the power to make a single decision in the chain. The key components of a Decider include:

  • Private Key: This is a set of two 32-byte values used to sign a decision.
  • Short Decider: The public-facing part of the Decider, represented by the SHA256 hash of the next Decider and the two tips (hashes) of the current Decider.
  • Long Decider: This is the signature created when a decision is made, comprising two 32-byte values derived from the private key. The Long Decider commits to the decision and must be stored on-chain to validate the transaction.

Structurally, Deciders can be chained together to decide on larger values. Each Decider in the chain references the next one, except for the last in the chain, which has no successor. This creates a flexible decision-making system where multiple transactions can be decided by the same Decider, or a single Decider can be part of multiple chains.

Use Cases

Use Case 1: Third-Party Arbitration

Deciders are used in third-party arbitration scenarios where two parties engage in a transaction (e.g., trading COMB for another currency). A trusted third party (the arbiter) creates a Decider and distributes the Short Decider to both parties. The parties construct a Merkle Segment with two possible destinations: one for the buyer and one for the seller. The seller funds the Merkle Segment address, and once the buyer transfers the agreed-upon amount in the other currency, the arbiter verifies the transaction and uses the Decider to determine whether the COMB is sent to the buyer or rolled back to the seller.

Benefits:

  • Trustless execution of trades.
  • Protection against fraud or miscommunication.
  • Decentralized decision-making with cryptographic guarantees.

Use Case 2: Conditional Payments

In this use case, a Decider is used to send conditional payments based on predefined outcomes. For instance, if a smart contract depends on an external event (such as a vote result or external API data), a Decider can be employed to choose from multiple payment destinations. The destinations could represent different parties or varying payment amounts, and the Decider selects the appropriate destination once the conditions are met.

Benefits:

  • Automated and conditional payments.
  • Flexibility in determining payment outcomes.
  • Cryptographically secure decisions without the need for constant human intervention.

Additional Examples

  • Escrow Services: Deciders can be used to manage escrow services where funds are held until certain conditions are met, at which point a Decider releases the funds.
  • Voting Mechanisms: In decentralized voting systems, Deciders can be employed to finalize votes, ensuring that the results are tamper-proof and that the winning outcome is cryptographically decided.
  • Multi-Signature Transactions: Deciders allow for multi-signature transactions where several parties must approve a transaction before it is processed, ensuring added security.

Further Reading

  • Haircomb Whitepaper: Detailed technical overview of the Haircomb system, including Deciders.
  • Merkle Segments: A deeper dive into Merkle Segments and their interaction with Deciders.

References

  • Natasha Otomoski: The creator of Haircomb, who first introduced Deciders in the whitepaper.
  • BitcoinTalk Forum: Original announcement of Haircomb and its technical details, including the role of Deciders.