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
  • Specification
  • Implementation

Was this helpful?

Edit on GitHub
Export as PDF
  1. Overlays

Universal Hash Resolution Protocol

PreviousConfederacy Lookup Availability Protocol (CLAP)NextOverlay Network Transaction History Tracking

Last updated 1 year ago

Was this helpful?

Ty Everett (ty@projectbabbage.com)

Abstract

This document describes the Universal Hash Resolution Protocol (UHRP), a standard framework for content availability advertisement implemented with a UTXO-based overlay network. UHRP enables content hosts to advertise the availability of a particular file by creating a UTXO-based advertisement token, which is then submitted to the UHRP overlay and tracked by overlay network nodes. UHRP provides resilience to single points of failure and ensures content accessibility even if one host is offline, because multiple entities can be paid by content providers to keep content available.

Motivation

In the digital world, consumers often require access to specific content without regard for the hosting source. Content providers, on the other hand, have a vested interest in maintaining wide availability of their offerings, even during host outages. Existing systems, however, do not provide a standardized and robust means of connecting users to their required files.

UHRP addresses this by enabling multiple content hosts to advertise the availability of content using UTXOs. Users can seek the content based on its hash, ensuring they connect to the files they need via an overlay network that is resilient to single points of failure. Content providers wishing to ensure consistent availability can pay multiple hosts, so that content remains available even if one host goes down.

This new paradigm not only streamlines content availability but also enables new hosts to build reputation by demonstrating opportunity cost (for example, by paying higher than normal transaction fees to miners on hosting commitments). Over time, service providers and applications can build a trusted list of UHRP hosts, thereby improving the overall reliability and trustworthiness of the content hosting ecosystem.

Specification

A UHRP advertisement token comprises a Bitcoin UTXO with a locking script containing the following components:

  • <public key>: This is the public key associated with the host that is making the advertisement.

  • OP_CHECKSIG: Ensures that if the token becomes spent, a signature was made using the host's private key.

  • Protocol prefix: A protocol prefix pushed onto the stack, with a value of 1UHRPYnMHPuQ5Tgb3AF8JXqwKkmZVy5hG.

  • <address>: The base58 version of the address corresponding to the <public key>.

  • <hash>: The next 32 bytes are the SHA-256 hash of the content being advertised.

  • <url>: The HTTPS URL where the host is advertising that the content is available for download.

  • <expiryTime>: A UTF-8 encoded version of a decimal integer representing the Unix timestamp of the advertisement expiry.

  • <contentLength>: A UTF-8 encoded version of a decimal integer representing the byte length of the content.

  • <signature>: A digital signature over the concatenated fields fields from the host's <public key>.

Implementation

Questions about this initial draft specification should be directed to the author.

Upon creation and submission of an advertisement to a overlay network node for the UHRP topic, the node will track the UTXO and facilitate its lookup via a lookup service with the provider name UHRP. If the token ever becomes spent, the advertisement is canceled. The spending transaction may contain more information justifying the host's revocation (shch as a DMCA notice), but any such stipulation is beyond the scope of this initial document, and left for others to specify later.

Tools such as (for downloading) and (for uploading to a NanoStore provider) have been created by the Babbage team. To implement the serialization format, the can be used.

BRC-22
BRC-22
BRC-24
NanoSeek
NanoStore-Publisher
uhrp-url tool