Company: Open Protocol Labs (info@opl.dev)
Author: Luke Rohenaz (luke@opl.dev)
Contributors: Kurt Wuckert Jr. (kurt@opl.dev), David Case (dcase@opl.dev), Michael Boyd (root@opl.dev), Dan Wagner (dan@opl.dev)
Original protocol author: _unwriter
This is a draft codification of an existing protocol, not a new wire format. Original protocol attribution is distinguished from authorship of this BRC; contributor acknowledgments do not imply endorsement of this transcription. Existing identifiers and payloads remain unchanged. Clarifications describe the scope of the documented profile; incompatible extensions require a separate proposal.
B is an OP_RETURN protocol to store and reference arbitrary data on Bitcoin. A B transaction carries raw file content together with its media type, character encoding, and optional filename under the protocol prefix 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut (a BRC-179 address identifier, generated using Bitcom). Stored media is addressed by the transaction id that carries it and referenced from other on-chain media with the b://<txid> URI scheme, making B the foundational content layer for on-chain websites, images, and documents composed with companion attribute and identity protocols such as MAP and AIP.
B's design goals:
- The simplest protocol to upload arbitrary media to the blockchain.
- A protocol to reference previously uploaded media from another on-chain media.
Before B, on-chain content schemes packed data and metadata into ad-hoc formats. B stores content as raw push data with just enough metadata (IANA media type and encoding) for any application to interpret it, and its reference scheme lets on-chain documents link to one another — an HTML page embedding an on-chain image, markdown linking to an on-chain page — so that entire websites can live on Bitcoin.
This proposal preserves B's existing field order and identifier. It complements BRC-18's data-carrier script template with content metadata; it does not change Bitcoin consensus rules or define inscription ownership, a UTXO token, or storage availability.
The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119.
A B transaction is a data-carrier output (BRC-18) whose push data are:
OP_RETURN
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
[Data]
[Media Type]
[Encoding]
[Filename]
| Order | Field | Meaning |
|---|---|---|
| 1 | Data | The raw content to store, written directly as binary push data (not Base64 or hex text). |
| 2 | Media Type | A media type as listed in the IANA Media Types registry (e.g. image/png, text/html, text/markdown). |
| 3 | Encoding | A character set label, or the protocol-specific label binary (not an IANA character set). Default: binary. MAY be omitted when no filename follows. |
| 4 | Filename | A filename to store the blob as. Default: none — the blob is identified simply by its txid. MAY be omitted. |
Omission is positional: only trailing optional fields can be omitted. To include a filename for binary content, include the binary encoding field first. No universal null placeholder is defined by the original B specification. Readers must preserve raw content bytes, including empty content; textual decoding applies only after determining the encoding. Metadata is text, not Script opcodes. Unknown trailing extension fields do not change the four base positions.
Examples are schematic push-field notation, not literal ASM. Historical bare OP_RETURN records remain readable; new false-return outputs use OP_FALSE OP_RETURN as described by BRC-18. In pipelines the segment ends at the complete 7c separator push, subject to BRC-179's delimiter limitation.
The field order is deliberate — data, media type, encoding, filename, in order of significance — leaving room for future extensibility through additional push data.
Examples:
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut <html><body>hello world</body></html> text/html UTF-8 hello.html
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [file bytes] image/png binary duck.png
OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [file bytes] image/png
Stored media is addressed by the transaction id of the transaction that carries it and referenced with the URI form:
b://<txid>
References work from ANY other on-chain media. An on-chain HTML page can embed an on-chain image:
<img src="b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c">link to another on-chain page:
<a href="b://e2be88f33d98074f778ddd94c13fe500cb1f5a4dfb3ed958391c95f431c20549">my website!</a>or appear in on-chain markdown:
The txid is the conventional 64-character hexadecimal transaction identifier. It identifies the whole transaction, not an output or segment. The legacy URI provides no output-selection rule when a transaction contains multiple B records. Applications must document their selection policy and must not claim that an ambiguous txid alone uniquely identifies one blob.
B's specification defines only the b:// form. How a client resolves a b:// URI to a serving endpoint is outside this specification.
Informative note: the Bitcom documentation (BRC-179 §6) states that bit://19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut/<txid> is equivalent to b://<txid> — both point to the same content — and recommended the bit:// form for new references. That equivalence is a claim of the Bitcom documentation, not of B itself.
B is a producer-only protocol in BRC-179 pipeline terms: it originates data rather than transforming piped input, so the original pipeline example places B before its metadata and signature segments. Attributes, authorship, and other concerns are layered by piping into companion protocols:
B <data> <media type> <encoding> | MAP SET type post | AIP BITCOIN_ECDSA <address> <signature>
This composition — content in B, attributes in MAP, authorship in AIP — keeps B itself minimal while supporting arbitrarily rich applications. (MAP and AIP are specified in their own BRCs.)
B is NOT a protocol for handling authenticated or encrypted media. Its design goals are:
- Public: public assets.
- Simple: simple to implement.
- Versatile: easily pluggable into any application in any context.
- Extensible: future extensibility with additional push data support.
Authentication is layered on with companion signature protocols such as AIP or Sigma (specified in their own BRCs); encryption is out of scope entirely.
The filename and media type are untrusted publisher input. A serving application should avoid filesystem path traversal, header injection, and executable-content exposure on a privileged origin. B provides neither encryption nor authorship authentication, and publishing content can expose it permanently. A gateway response is not itself proof that the bytes occur in the claimed transaction: a verifying client checks the transaction identifier and extracts the chosen record from that transaction; confirmation verification is a separate step. A txid reference does not ensure continued data availability.
The original B repository provides the format and examples. The bmap B parser illustrates extraction into an application object. Parser support does not establish gateway availability or a standard multi-output resolution policy.
- B repository (canonical specification): https://github.com/unwriter/B
- BRC-179: Bitcom — protocol prefix, pipeline, and
bit://routing conventions - BRC-18: Pay to False Return — data-carrier output template
- IANA Media Types: https://www.iana.org/assignments/media-types/media-types.xhtml
- IANA Character Sets: https://www.iana.org/assignments/character-sets/character-sets.xhtml