Skip to content

Latest commit

 

History

History
130 lines (80 loc) · 9.28 KB

0023.md

File metadata and controls

130 lines (80 loc) · 9.28 KB
Raw

BRC-23: Confederacy Host Interconnect Protocol (CHIP)

Ty Everett ([email protected])

Abstract

We outline the Confederacy Host Interconnect Protocol (CHIP), a peer discovery mechanism for UTXO-based overlay networks. CHIP is an overlay network which tracks active network operators hosting specific topics, facilitating UTXO discovery, providing robust availability guarantees, thus enabling fault tolerance. This document specifies the format for CHIP tokens, their propagation across the network, and the process of using them to find and connect with hosts.

Motivation

The BRC-22 standard defines a method for running a server that accepts transactions, admits their outputs into topics, and tracks topical UTXO sets. However, there is a need for a connectivity and peer discovery mechanism for users who want to stay loosely in sync with one another. CHIP addresses this need, ensuring efficient synchronization and data propagation by facilitating the discovery of network operators actively hosting specific topics.

Specification

We define the various components of the Confederacy Host Interconnect architecture.

CHIP Token Format

CHIP tokens are registered on the Bitcoin SV blockchain as single-satoshi BRC-48 outputs representing hosting advertisements by Confederacy network operators. The token fields are ordered as follows:

Field Meaning
Field 1 The string CHIP, denoting a CHIP advertisement.
Field 2 The BRC-31 identity key of the advertiser creating the token.
Field 3 The internet domain name of the HTTPS server hosting the network node.
Field 4 The topic name hosted by the advertiser.

Token Creation and Submission

The advertiser creates a transaction output containing the token and submits it to known nodes, including their own. The BRC-48 locking key must be linked to the advertiser's BRC-31 identity key using the BRC-42 and BRC-43 methodologies.

The advertiser follows these steps to derive the BRC-48 locking key, compute the signature, and advertise the transaction to all known nodes:

  1. Deriving the BRC-48 Locking Key:
    • Use the advertiser's BRC-31 identity key as the sender private key in the BRC-42 key derivation, with the "anyone" public key (1 by G) as the counterparty.
    • Compute the invoice number using the BRC-43 methodology with security level 2, protocol ID CHIP, and key ID of 1.
    • Derive the signing private key from your identity key using the computed invoice number.
  2. Computing the Signature:
    • Use the derived private key to compute the BRC-48 signature over the token fields.
  3. Advertising the Transaction:
    • Create a transaction output containing the CHIP token.
    • Submit the transaction to all known nodes, including the advertiser's own node.

There is no need to advertise that nodes host CHIP itself. It is assumed that all nodes which understand and receive CHIP advertisements intrinsically host CHIP, as they are already participating in the CHIP network and processing the advertisements.

Token Validation and Admission

Nodes accepting CHIP tokens must validate the identity key's link to the signature-producing key before admitting the output. Invalid tokens must be rejected. The following steps detail the token validation process:

  • Step 1: Extract token fields. Upon receiving a CHIP token, the node should first extract the four fields as defined in the token format. These fields include the CHIP identifier, the advertiser's BRC-31 identity key, the domain name of the HTTPS server hosting the network node, and the topic name hosted by the advertiser.

  • Step 2: Verify the CHIP identifier. Check that the first field of the token is the string CHIP. If this condition is not met, reject the token as invalid.

  • Step 3: Verify the BRC-48 locking key. Utilize the advertiser's claimed BRC-31 identity key as the sender public key in the BRC-42 key derivation process, with the "anyone" private key (1) as the recipient. Compute the invoice number using the BRC-43 methodology with security level 2, protocol ID CHIP, and key ID of 1. Derive the public key from the advertiser's identity key using this invoice number. Ensure that the computed key matches the BRC-48 locking key. If the keys are not linkable, reject the token as invalid.

  • Step 4: Verify the BRC-48 signature. Check the signature over the token fields by using the derived public key from the previous step. Ensure that the signature is valid and corresponds to the fields provided in the token.

  • Step 5: Admit the token. If all previous steps have been successfully completed and the token is deemed valid, admit the token into the CHIP topic.

CHIP Lookup Service

The CHIP BRC-24 lookup service enables network users to access and query for CHIP advertisement UTXOs in a standardized way. By facilitating access to these UTXOs, users can discover other nodes that may have the data they need, enhancing connectivity across the UTXO-based overlay network.

Provider Name

The specified provider name for the lookup service is CHIP. This standardized name allows implementations to easily recognize and interact with the service.

Query Processing

The lookup service processes queries as JSON objects containing "topic" and "advertiser" keys. These keys are used in an AND stipulation to filter the results based on the provided values. The service searches the UTXOs for matches that satisfy both conditions (if present) and returns the corresponding results.

Query Fields and AND Stipulation

The query fields are as follows:

Field Meaning
topic The topic name hosted by the advertiser, used to filter UTXOs based on the desired topic.
advertiser The BRC-31 identity key of the advertiser, used to filter UTXOs based on the specific advertiser.

The AND stipulation operates by requiring both topic and advertiser conditions to be satisfied for a UTXO to be included in the result set. If only one key is provided, the lookup service will return UTXOs matching that single condition. If both keys are present, the service will only return UTXOs that match both the specified topic and advertiser.

Query Examples

Example 1: Query with only "topic"

{
  "topic": "example_topic"
}

In this example, the lookup service will return all UTXOs with the specified "example_topic", regardless of the advertiser.

Example 2: Query with only "advertiser"

{
  "advertiser": "02bc91718b3572462a471de6193f357b6e85ee0f8636cb87db456cb1590f913bea"
}

Here, the service will return all UTXOs from the specified advertiser, regardless of the topic.

Example 3: Query with both "topic" and "advertiser"

{
  "topic": "example_topic",
  "advertiser": "02bc91718b3572462a471de6193f357b6e85ee0f8636cb87db456cb1590f913bea"
}

In this case, the lookup service will return UTXOs that match both the specified topic and advertiser, providing more precise results.

Discovering Nodes Hosting a Topic of Interest

This section details the process for an overlay network user to discover nodes hosting a particular topic they are interested in. The user will follow these steps to locate relevant nodes and notify them about a new transaction in the topic:

  • Query the CHIP Lookup Service. The user initiates the process by querying the CHIP lookup service through a known node. The query contains the desired "topic" key, and optionally the "advertiser" key if the user wants to find a specific advertiser hosting the topic. The lookup service returns a list of UTXOs with corresponding CHIP tokens containing relevant domain names and BRC-31 identity keys of advertisers.

  • Contacting Servers and Notifying about the New Transaction. Upon receiving the list of UTXOs, the user extracts the domain names and identity keys of the relevant nodes. The user then contacts each server at their respective domain via the BRC-22 protocol, notifying them about a new transaction in the topic.

  • Verifying Identity Key during Transaction Submission. During the transaction submission process to the topic, the user verifies that the identity key of the advertiser matches the key used by the server for authentication. This step ensures that the server is the intended recipient and maintains the integrity of the transaction submission process.

By following these steps, an overlay network user can discover nodes hosting a specific topic of interest and securely engage with them to submit transactions to the relevant topic. This process enhances the connectivity and efficiency of UTXO-based overlay networks and ensures the security of transactions between nodes.

Implementation

There are no known implementations of this specification at this time. The specification will be updated when an implementation is published.