Universal Hash Resolution Protocol

Ty Everett ([email protected])

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 BRC-22 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

Status Note

The content-addressing idea remains current, and bsv-blockchain/ts-sdk includes StorageUtils, StorageDownloader, and StorageUploader helpers for UHRP-style storage. Some details below are historical:

  • Current SDK UHRP URLs encode the SHA-256 file hash with Base58Check prefix ce00; callers may use the bare string or a uhrp: / uhrp:// prefix.

  • Current SDK download resolution queries BRC-24 service ls_uhrp with { "uhrpUrl": "..." } and expects an output-list response.

  • Current SDK resolution reads PushDrop advertisement fields with the download URL in field 3 and an expiry timestamp in field 4.

  • Current SDK upload helpers interact with storage servers through authenticated HTTP routes such as POST /upload, GET /find?uhrpUrl=..., GET /list, and POST /renew; the direct file upload itself is a PUT to the server-provided upload URL.

  • The older UHRP topic/provider naming and the NanoSeek/NanoStore tooling references below are legacy. New overlay implementations should use BRC-87 names such as tm_uhrp / ls_uhrp or another explicitly documented tm_ / ls_ pair.

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>.

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

Implementation

Tools such as NanoSeekarrow-up-right (for downloading) and NanoStore-Publisherarrow-up-right (for uploading to a NanoStore provider) have been created by the Babbage team. To implement the serialization format, the uhrp-url toolarrow-up-right can be used.

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

Last updated