BRC-180: B — Bitcoin Data Protocol

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)

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
 

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://<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.
+
+## 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 <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
+```
+
+### 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://<txid>
+```
+
+References work from ANY other on-chain media. An on-chain HTML page can embed an on-chain image:
+
+```html
+<img src="b://46e1ca555622e73708a065f92df0af2cc0fe00ed1dd352d5fb8510365050347c">
+```
+
+link to another on-chain page:
+
+```html
+<a href="b://e2be88f33d98074f778ddd94c13fe500cb1f5a4dfb3ed958391c95f431c20549">my website!</a>
+```
+
+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/<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.
+
+### 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 <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.)
+
+### 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

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)