LogoLogo
  • README
  • Contribute
    • Discuss on Github
  • Example
    • Banana-Powered Bitcoin Wallet Control Protocol
  • Apps
    • The deployment-info.json Specification
  • Wallet
    • Transaction Creation
    • Data Encryption and Decryption
    • Digital Signature Creation and Verification
    • Input Redemption
    • HTTP Wallet Communications Substrate
    • XDM Wallet Communications Substrate
    • Window Wallet Communication Substrate
    • Wallet Transaction Output Tracking (Output Baskets)
    • Submitting Received Payments to a Wallet
    • Certificate Creation and Revelation
    • Unified Abstract Wallet-to-Application Messaging Layer
    • Transaction Labels and List Actions
    • Output Basket Removal and Certificate Deletion
    • Group Permissions for App Access
    • Extensible Proof-Type Format for Specific Key Linkage Claims
    • P Protocols: Allowing future wallet protocol permission schemes
    • P Baskets: Allowing Future Wallet Basket and Digital Asset Permission Schemes
    • Unified, Vendor-Neutral, Unchanging, and Open BSV Blockchain Standard Wallet-to-Application Interface
  • Transactions
    • Everett-style Transaction Envelopes
    • Simplified Payment Verification
    • Merkle proof standardised format
    • TSC Proof Format with Heights
    • Raw Transaction Format
    • TXO Transaction Object Format
    • Transaction Extended Format (EF)
    • Merkle Path JSON format
    • Compound Merkle Path Format
    • Background Evaluation Extended Format (BEEF) Transactions
    • Simplified Payment Verification
    • Merkle Path Binary Format
    • BSV Unified Merkle Path (BUMP) Format
    • Graph Aware Sync Protocol
    • Scalable Transaction Processing in the BSV Network
    • Atomic BEEF Transactions
    • BEEF V2 Txid Only Extension
  • Scripts
    • Bitcoin Script Binary, Hex and ASM Formats
    • Bitcoin Script Assembly Language
    • Pay to Public Key Hash
    • Pay to R Puzzle Hash
    • Pay to False Return
    • Pay to True Return
    • Push TX
    • Bare Multi-Signature
    • Pay to Push Drop
  • Tokens
    • There is no BRC-20
    • Definition of UTXOs as Bitcoin Tokens
    • Token Exchange Protocol for UTXO-based Overlay Networks
    • Mandala Token Protocol
  • Overlays
    • Overlay Network Data Synchronization
    • Confederacy Host Interconnect Protocol (CHIP)
    • Overlay Network Lookup Services
    • Confederacy Lookup Availability Protocol (CLAP)
    • Universal Hash Resolution Protocol
    • Overlay Network Transaction History Tracking
    • Private Overlays with P2PKH Transactions
    • Standardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup Services
    • Overlay Services Synchronization Architecture
    • Diverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements
  • Payments
    • Direct Payment Protocol (DPP)
    • Paymail Payment Destinations
    • Simple Authenticated BSV P2PKH Payment Protocol
    • PacketPay HTTP Payment Mechanism
    • Hybrid Payment Mode for DPP
    • HTTPS Transport Mechanism for DPP
    • Paymail BEEF Transaction
    • HTTP Service Monetization Framework
  • Peer-to-Peer
    • Authrite Mutual Authentication
    • PeerServ Message Relay Interface
    • PeerServ Host Interconnect Protocol
    • Identity Certificates
    • Genealogical Identity Protocol
    • Publishing Trust Anchor Details at an Internet Domain
    • Message Signature Creation and Verification
    • Serialization Format for Portable Encrypted Messages
    • Defining a Scalable IPv6 Multicast Protocol for Blockchain Transaction Broadcast and Update Delivery
    • Proven Identity Key Exchange (PIKE)
    • Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol
    • HTTP Transport for BRC-103 Mutual Authentication
  • Key Derivation
    • BIP32 Key Derivation Scheme
    • BSV Key Derivation Scheme (BKDS)
    • Security Levels, Protocol IDs, Key IDs and Counterparties
    • Admin-reserved and Prohibited Key Derivation Protocols
    • Revealing Key Linkages
    • Protecting BRC-69 Key Linkage Information in Transit
    • Mnemonic For Master Private Key
    • Linked Key Derivation Scheme
    • Bidirectionally Authenticated Derivation of Privacy Restricted Type 42 Keys
    • Limitations of BRC-69 Key Linkage Revelation
    • Verifiable Revelation of Shared Secrets Using Schnorr Protocol
  • Outpoints
    • Format for Bitcoin Outpoints
    • Spending Instructions Extension for UTXO Storage Format
  • Opinions
    • Users should never see an address
    • List of user experiences
    • Legitimate Uses for mAPI
    • Security and Scalability Benefits of UTXO-based Overlay Networks
    • Improving on MLD for BSV Multicast Services
    • Web 3.0 Standard (at a high level)
    • Thoughts on the Mandala Network
    • Outputs, Overlays, and Scripts in the Mandala Network
  • State Machines
    • Simplifying State Machine Event Chains in Bitcoin
Powered by GitBook
On this page
  • Abstract
  • Motivation
  • Background
  • Specification
  • Overview
  • Components
  • Key Responsibilities
  • SHIP and SLAP Token Formats
  • Token Creation and Submission
  • Token Validation and Admission
  • Implementation

Was this helpful?

Edit on GitHub
Export as PDF
  1. Overlays

Overlay Services Synchronization Architecture

PreviousStandardized Naming Conventions for BRC-22 Topic Managers and BRC-24 Lookup ServicesNextDiverse Facilitators and URL Protocols for SHIP and SLAP Overlay Advertisements

Last updated 5 months ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

Abstract

This document outlines the Overlay Services Synchronization Architecture, detailing the Services Host Interconnect Protocol (SHIP) and Services Lookup Availability Protocol (SLAP). These protocols enable efficient peer discovery and data synchronization across UTXO-based overlay networks. This BRC defines the components, interactions, and responsibilities of nodes running these protocols to maintain reliable and up-to-date overlay services.

Motivation

The proliferation of UTXO-based overlay networks necessitates robust mechanisms for peer discovery and data synchronization. While defines transaction submission and processing, SHIP and SLAP extend this by providing standardized methods for discovering the overlay hosts that run particular services. This architecture ensures seamless interaction between network participants, improving the efficiency and reliability of data propagation. It can also enable the users of services to find hosts that are interested in their transactions.

Background

Readers of this document should be familiar with BRCs 45, 59, 22, 24, 23, and 25.

Specification

Overview

The Overlay Services Synchronization Architecture comprises two fundamental protocols:

  1. Services Host Interconnect Protocol (SHIP)

  2. Services Lookup Availability Protocol (SLAP)

Each node running overlay services will implement topic managers and lookup services for both SHIP and SLAP, ensuring alignment between advertised services and their actual configuration.

Components

  • SHIP/SLAP Topic Managers: Manage topic-specific transaction admittance.

  • SHIP/SLAP Lookup Services: Provide mechanisms for querying UTXO states within topics.

  • Advertiser: Handles the creation and revocation of SHIP and SLAP advertisements.

  • Overlay Services Engine: Coordinates the processing of transactions, alignment of advertisements, and synchronization of data across various services.

Key Responsibilities

1. Ensuring Alignment

Each node must ensure alignment between the SHIP and SLAP advertisements it has sent out and the current set of topic managers and lookup services it is configured with.

2. Hosting SHIP/SLAP Overlay Networks

Nodes host copies of the SHIP and SLAP overlay networks, ensuring they are updated with new advertisements or revocations.

  • Submission: Any node can submit SHIP/SLAP advertisements to another node if it knows its domain name, updating the overlay network.

  • Internal Updates: Nodes submit their own advertisement transactions to themselves to update the overlay networks about new advertisements or revocations, thereby ensuring their hosted copies are always current and propagating them to other nodes.

3. Transaction Propagation

As part of the transaction submission process, nodes notify each other about transactions on topics they host and care about.

When new transactions are submitted to a node, the Engine:

  • Ensures transactions are propagated to relevant nodes based on SHIP/SLAP advertisements made by them.

  • Updates lookup services with new or spent UTXOs.

  • Delegates transaction submission, verification, and output admittance to the SHIP/SLAP topic managers.

SHIP and SLAP Token Formats

SHIP Token Format

Field
Meaning

Field 1

The string SHIP, denoting a SHIP advertisement.

Field 2

Field 3

The domain name of the HTTPS server hosting the network node.

Field 4

The topic name hosted by the advertiser.

SLAP Token Format

Field
Meaning

Field 1

The string SLAP, denoting a SLAP advertisement.

Field 2

Field 3

The domain name of the HTTPS server hosting the network node.

Field 4

Token Creation and Submission

The advertiser creates a transaction output containing the token and submits it to known nodes, including their own. The process involves:

  1. Deriving the locking key using the advertiser's identity key.

  2. Computing the signature over the token fields.

  3. Creating and submitting the transaction output containing the token.

Token Validation and Admission

Nodes validate the identity key's link to the signature-producing key before admitting the output. The steps include:

  1. Extracting token fields.

  2. Verifying the SHIP/SLAP identifier.

  3. Verifying the locking key and signature.

  4. Admitting the token if valid.

Implementation

Developers should implement an HTTPS server that hosts the SHIP and SLAP topic managers and lookup services. The server should be responsible for notifying other nodes of relevant transactions and maintaining synchronization.

The identity key of the advertiser.

The identity key of the advertiser.

The service name, represented by a provider ID.

BRC-22
BRC-31
BRC-31
BRC-24