From c59af093b9b2eb8255ab4d28ab8068a7f1c30143 Mon Sep 17 00:00:00 2001 From: Luke Rohenaz Date: Fri, 4 Sep 2026 17:09:44 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20propose=20BRC-180=20B=20=E2=80=94=20Bit?= =?UTF-8?q?coin=20Data=20Protocol?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 1 + SUMMARY.md | 1 + scripts/0180.md | 137 ++++++++++++++++++++++++++++++++++++++++++++++ scripts/README.md | 1 + 4 files changed, 140 insertions(+) create mode 100644 scripts/0180.md diff --git a/README.md b/README.md index 100a9bb..0fe9acf 100644 --- a/README.md +++ b/README.md @@ -238,6 +238,7 @@ BRC | Standard 174 | [Consensus-Unique Name Tokens — Identity Binding and Verified Resolution](./tokens/0174.md) 176 | [BSV-21 — Validity Proofs](./tokens/0176.md) 177 | [Wallet-Enforced Expiry for `noSend` Actions](./wallet/0177.md) +180 | [B — Bitcoin Data Protocol](./scripts/0180.md) 190 | [Access Gates for Metanet Rooms](./apps/0190.md) 210 | [Derived Collectibles](./apps/0210.md) 218 | [Chat-Native Command Grammar for the Metanet](./apps/0218.md) diff --git a/SUMMARY.md b/SUMMARY.md index 11501cf..3e9dea7 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -108,6 +108,7 @@ * [Pay to Push Drop](./scripts/0048.md) * [Bitcoin Script ASM Format](./scripts/0106.md) * [Bitcoin Script to and from Bitcoin BASIC — a compiler and a decompiler](./scripts/0173.md) +* [B — Bitcoin Data Protocol](./scripts/0180.md) ## Tokens diff --git a/scripts/0180.md b/scripts/0180.md new file mode 100644 index 0000000..b87dc6f --- /dev/null +++ b/scripts/0180.md @@ -0,0 +1,137 @@ +# BRC-180: B — Bitcoin Data Protocol + +Open Protocol Labs (info@opl.dev) + +**Original protocol author:** [_unwriter](https://github.com/unwriter) + +**BRC editor:** 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) + +## Status and Scope + +This is a draft codification of an existing protocol, not a new wire format. Original protocol attribution is distinguished from BRC editorial attribution; 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. + +## Abstract + +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](https://github.com/opldotdev/BRCs/blob/codex/brc-179-bitcom/scripts/0179.md) 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://` 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. + +## Motivation + +B's design goals: + +1. The simplest protocol to upload arbitrary media to the blockchain. +2. 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. + +## Specification + +The key words "MUST", "SHOULD", and "MAY" in this document are to be interpreted as described in RFC 2119. + +### 1. Protocol Format + +A B transaction is a data-carrier output ([BRC-18](./0018.md)) 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 hello world text/html UTF-8 hello.html + +OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [file bytes] image/png binary duck.png + +OP_RETURN 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut [file bytes] image/png +``` + +### 2. Referencing Media (`b://`) + +Stored media is addressed by the transaction id of the transaction that carries it and referenced with the URI form: + +``` +b:// +``` + +References work from ANY other on-chain media. An on-chain HTML page can embed an on-chain image: + +```html + +``` + +link to another on-chain page: + +```html +my website! +``` + +or appear in on-chain markdown: + +```markdown +![image](b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c) +``` + +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](https://github.com/opldotdev/BRCs/blob/codex/brc-179-bitcom/scripts/0179.md) §6) states that `bit://19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut/` is equivalent to `b://` — 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. + +### 3. Composition + +B is a **producer-only** protocol in [BRC-179](https://github.com/opldotdev/BRCs/blob/codex/brc-179-bitcom/scripts/0179.md) 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 | MAP SET type post | AIP BITCOIN_ECDSA
+``` + +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.) + +### 4. Non-Goals + +B is NOT a protocol for handling authenticated or encrypted media. Its design goals are: + +1. **Public:** public assets. +2. **Simple:** simple to implement. +3. **Versatile:** easily pluggable into any application in any context. +4. **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. + +## Security Considerations + +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. + +## Implementations + +The [original B repository](https://github.com/unwriter/B) provides the format and examples. The [bmap B parser](https://github.com/rohenaz/bmap/blob/master/src/protocols/b.ts) illustrates extraction into an application object. Parser support does not establish gateway availability or a standard multi-output resolution policy. + +## References + +- B repository (canonical specification): https://github.com/unwriter/B +- [BRC-179: Bitcom](https://github.com/opldotdev/BRCs/blob/codex/brc-179-bitcom/scripts/0179.md) — protocol prefix, pipeline, and `bit://` routing conventions +- [BRC-18: Pay to False Return](./0018.md) — 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 diff --git a/scripts/README.md b/scripts/README.md index e20dda5..6dfe7d1 100644 --- a/scripts/README.md +++ b/scripts/README.md @@ -16,3 +16,4 @@ BRC | Standard 48 | [Pay to Push Drop](./0048.md) 106 | [Bitcoin Script ASM Format](./0106.md) 173 | [Bitcoin Script to and from Bitcoin BASIC — a compiler and a decompiler](./0173.md) +180 | [B — Bitcoin Data Protocol](./0180.md)