BRC-167 Introduces CHIRP for Chunked, Verifiable Retrieval of Large Content

Content Infrastructure Watch / Data Infrastructure

In Brief

A new BSV Blockchain standard, BRC-167, introduces the Chunked, Hashed, Interleaved Resolution Protocol, or CHIRP, for publishing and retrieving large digital content as independently verifiable pieces rather than one indivisible file. Built on the existing Universal Hash Resolution Protocol, CHIRP allows applications to retrieve chunks in parallel, retry or resume individual pieces, and request portions of large content while cryptographically verifying that each piece belongs to the committed whole. (Beersy)

News Report

BRC-167: Chunked, Hashed, Interleaved Resolution Protocol, authored by Ty Everett and published August 27, extends the BSV Blockchain ecosystem’s content-resolution architecture with a method designed specifically for large files, datasets, media and archives. (Beersy)

The new protocol builds on BRC-26 Universal Hash Resolution Protocol, or UHRP.

UHRP allows a byte string to be identified by its SHA-256 hash and provides a way to discover locations from which matching content can be retrieved. That model provides strong content integrity, but its simplest form treats an entire file as one object. For large content, the publisher must finish producing the file before its whole-file identifier can be finalized, while a recipient generally retrieves and verifies the object as a whole. (Beersy)

CHIRP introduces a Merkle-tree layer above that model.

A publisher divides an ordered stream of data into bounded chunks. Each chunk is hashed, while branch nodes record the hashes, sizes and positions of the pieces beneath them. Those branches ultimately resolve into a small root object whose hash commits to the complete ordered content. (Beersy)

That structure allows a receiver to verify individual chunks before using them rather than waiting until an entire large object has been downloaded.

A CHIRP resolver can also obtain different pieces concurrently from multiple hosts, retry only a failed or corrupted chunk, resume an interrupted transfer using already verified data, and retrieve only the chunks required for a requested logical byte range. (Beersy)

The protocol therefore separates content identity from the size of the individual transfer operation.

If a multi-gigabyte dataset is interrupted near the end of a download, for example, the application does not necessarily need to restart the entire transfer. Previously verified chunks can remain valid because their hashes and positions are committed through the Merkle structure.

Likewise, an application needing only part of a large file can traverse the relevant branches, retrieve the overlapping chunks in full, verify them, and then expose only the requested portion.

CHIRP deliberately does not replace UHRP or create a second content-discovery network.

A CHIRP root is itself an ordinary UHRP object. Resolution continues to use the existing tm_uhrp topic and ls_uhrp lookup service defined by the earlier overlay standards. Hosts advertise the root through UHRP and commit to serving the full set of objects reachable from that root for the duration of the advertisement. (Beersy)

Conceptually, UHRP continues to answer what content is being requested and where it can be found, while CHIRP adds a standardized way to divide, retrieve and independently verify large content beneath that identifier.

The protocol also allows multiple hosts to advertise the same root. A resolver is encouraged to distribute requests across those hosts rather than depending on one provider until it fails. If an object times out, returns the wrong length or fails its hash check, the resolver can retry that individual object through another complete host. (Beersy)

The first CHIRP version defines a canonical chirp:// URI, deterministic chunking and tree construction, bounded root and branch structures, HTTP retrieval rules, logical-range retrieval and a baseline upload-session protocol.

Its design also leaves extension points for later features such as content-defined chunking, media-aware boundaries, compact inclusion proofs, partial hosting, erasure coding and collections, without redefining the meaning of a version-one identifier. (Beersy)

The specification is careful to distinguish integrity from authenticity.

CHIRP can prove that retrieved bytes correspond to an immutable content identifier and occupy the committed position in the larger object. It does not by itself establish who authored the content, whether the publisher had authority to distribute it, or whether the material is trustworthy.

Applications that need provenance must therefore authenticate the CHIRP reference through another mechanism such as a signature, transaction, certificate or trusted application record. (Beersy)

That distinction is relevant to Project Babbage’s description of CHIRP as enabling authenticated, chain-backed content. The content chunks themselves are verified through CHIRP, while provenance can be added by placing or authenticating the corresponding reference within a signed or blockchain-backed record.

The standard also does not prescribe payment or authentication for hosting. Its upload layer can be combined with existing BRC mechanisms such as BRC-103/104 authentication and BRC-105 or BRC-121 service payments. (Beersy)

BRC-167 identifies the BSV Association’s consolidated TypeScript Stack as the intended home for an initial reference implementation, including a proposed @bsv/chirp package, command-line tooling, browser and Node.js interfaces, UHRP server routes, conformance vectors and multi-host integration testing. The specification itself remains the authoritative interoperability definition. (Beersy)

BSV TIMES Read

CHIRP addresses a practical difference between proving that a file is correct and making large authenticated content usable as network infrastructure.

Whole-file hashing works well when objects are relatively small. As content becomes much larger, however, applications also need to stream, resume, distribute and selectively retrieve it without giving up the ability to verify what they receive.

CHIRP moves that verification boundary down to manageable pieces while retaining one cryptographic commitment to the complete ordered object.

That creates a useful architecture for large datasets, media, archives and application content. Hosts can distribute the bytes, multiple providers can serve different pieces, and applications can retrieve only what they need, while the identifier remains independent of any particular storage provider.

The important point is also what CHIRP does not attempt to do. It does not make every piece of content authentic merely because its bytes are verifiable. Identity and provenance remain separate layers that can be attached through signatures, transactions or other records.

That separation is characteristic of infrastructure designed to be reused. CHIRP defines how large content can be addressed, transferred and checked. Applications remain free to determine what that content means, who is authorized to publish it and what services are built around it.