Beersy
BRC-26

Universal Hash Resolution Protocol

Referring to a file by a web address breaks the moment that address stops working. This lets a file be named by its contents instead, with any number of hosts advertising that they hold a copy.

Ty Everettchanged 1 May 20263 min read
hosthostclientls_uhrp

Summary

Why
Content needs to stay reachable by its identity even when the specific server hosting it goes offline or is not known in advance.
What
BRC-26 defines the (UHRP), a way for hosts to advertise file availability as UTXO-based tokens tracked by an and looked up by content hash.
How
A host builds a whose carries its public key, the file's SHA-256 hash, an HTTPS download URL, an expiry timestamp, a content length, and a signature, submits it to a BRC-22 overlay under a UHRP topic, and clients later query a BRC-24 (named per BRC-87, such as tm_uhrp/ls_uhrp) with…

What this lets you do

  • Advertise that you host a specific file by creating a UTXO-based token naming its hash, URL, and expiry
  • Let anyone look up which hosts currently claim to have a given file, by its hash
  • Cancel an advertisement by spending the token, for example after a takedown notice
  • Pay multiple independent hosts to advertise the same file so it survives any single host going offline
  • Resolve a uhrp: URL to a live download link through an overlay lookup service

Written by claude-sonnet-5 from the specification text. Where the two differ, the original is correct.

Reference for an AI

Everything an assistant needs to answer questions about BRC-26 accurately, including what it depends on.

The specification

Abstract

This document describes the (UHRP), a standard framework for content availability advertisement implemented with a UTXO-based . 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 ). 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 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 with a 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 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 NanoSeek (for downloading) and NanoStore-Publisher (for uploading to a NanoStore provider) have been created by the Babbage team. To implement the serialization format, the uhrp-url tool can be used.

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

Was this helpful?

Search Beersy

Search standards by number, title, author or topic