BRC-184: Outpoint Content Addressing

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)
+184  | [Outpoint Content Addressing](./outpoints/0184.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

@@ -208,6 +208,7 @@
 * [User Wallet Data Format](./outpoints/0038.md)
 * [User Wallet Data Format Encryption Extension](./outpoints/0039.md)
 * [User Wallet Data Synchronization](./outpoints/0040.md)
+* [Outpoint Content Addressing](./outpoints/0184.md)
 
 ## Opinions
 

outpoints/0184.md

@@ -0,0 +1,84 @@
+# BRC-184: Outpoint Content Addressing
+
+Open Protocol Labs (info@opl.dev)
+
+**Authors:** David Case (dcase@opl.dev), Luke Rohenaz (luke@opl.dev)
+
+**Contributors:** Kurt Wuckert Jr. (kurt@opl.dev), Michael Boyd (root@opl.dev), Dan Wagner (dan@opl.dev)
+
+## Abstract
+
+This proposal documents the underscore-separated content locator used by 1Sat applications, `<txid>_<vout>`, and its relationship to the dot-separated outpoint format in [BRC-36](./0036.md). It specifies a content-addressing profile, not a replacement for the canonical BRC-36 wallet object. Content extraction and mutable chain resolution remain responsibilities of the consuming protocol.
+
+## Motivation
+
+A transaction can contain more than one data-bearing output. A transaction id alone therefore cannot identify one output's content. 1Sat tools use underscore-separated output identifiers, while BRC-36 uses dot-separated identifiers. Explicit conversion at those boundaries prevents applications from rejecting valid references or accidentally changing signed bytes.
+
+## Specification
+
+The key words MUST, SHOULD, and MAY are normative requirements of this profile.
+
+### Output locator
+
+A locator in this profile has the form `<txid>_<vout>`:
+
+- `txid` is exactly 64 lowercase ASCII hexadecimal characters, in displayed transaction-id order (not serialized input byte order).
+- `_` is one ASCII underscore.
+- `vout` is an unsigned decimal integer from 0 through 4294967295, with no leading zeros except the single digit `0`.
+
+Producers using this profile MUST emit this form. Resolvers MUST reject malformed locators, fetch the transaction whose computed id matches `txid`, and check that output `vout` exists before extracting content. This syntax identifies an output, not a particular push or envelope within that output. The consuming content protocol MUST specify how it selects content when multiple payloads are present. A locator alone does not prove transaction inclusion or spendability.
+
+Example (illustrative, not a claim that the transaction exists):
+
+```text
+a54d3af24a03bcc28f6b3f2dd0ad249ee042b2f4b95810ae5184ab617a74b8b9_0
+```
+
+### Compatibility with BRC-36 and BRC-159
+
+[BRC-36](./0036.md) requires `<txid>.<vout>` in its `outpoint` field. Applications exchanging BRC-36 objects MUST retain that dot form. It is not a deprecated or forbidden encoding. [BRC-159](../tokens/0159.md) recognizes both dot and underscore forms for 1Sat identity.
+
+Readers of this content profile SHOULD accept a dot in place of the underscore, validating the same components. Conversion changes only the separator; it does not reverse the txid or reinterpret the output index. Equality is equality of the decoded `(txid, vout)` pair. Implementations MUST NOT normalize signed source bytes before signature verification.
+
+A reader MAY accept traditional `<txid>:<vout>` notation at an explicitly documented compatibility boundary. A colon is not inherently illegal in a URI path; URI parsing and escaping depend on the enclosing URI component. Implementations MUST avoid interpreting a compatibility separator as a version suffix.
+
+### Bare transaction references
+
+A bare txid is a transaction reference, not an outpoint. Existing `b://<txid>` references retain their [BRC-180](https://github.com/opldotdev/BRCs/blob/codex/brc-180-b-protocol/scripts/0180.md) meaning. This proposal does not impose a new universal output-selection rule on existing URI schemes.
+
+The ORDFS implementation's `loadByTxid` scans outputs in index order for recognized inscription or B content. This is informative gateway behavior, not a rule that every protocol means by “parseable content.” A consuming profile that accepts bare txids MUST document its content recognition and selection rule. New references that need one particular output SHOULD include its index.
+
+### Sequence and path extensions
+
+ORDFS uses selectors such as `<txid>_<vout>:<seq>` and paths below an output. These are serving-protocol extensions, not Bitcoin outpoint identifiers. In the inspected implementation, `-1` selects latest chain state and `-2` selects origin state; a nonnegative selector is an absolute chain position. Chain positions include transfers, not merely content revisions. With no selector, ORDFS resolves at the referenced output's chain position, which can inherit earlier content.
+
+Consequently, this document does not define “no selector” as raw script content, nor promise that a latest reference is immutable. A protocol adopting selectors MUST specify traversal, content inheritance, missing-history behavior and bounds. Readers implementing only the base locator MUST report unsupported extensions rather than silently discard a suffix. Neither suffixes nor directory paths belong in a BRC-36 `outpoint` field.
+
+## Compatibility examples
+
+For a transaction id `T` consisting of 64 lowercase hex digits:
+
+| Input | Result |
+|-------|--------|
+| `T_0` | Canonical content locator for output 0 |
+| `T.0` | BRC-36 form; same decoded output |
+| `T_01`, `T_-1`, `T_4294967296` | Invalid base locator |
+| `T_4` when the transaction has four outputs | Syntactically valid; output does not exist |
+| `T_0:-1` | Extension requiring a serving profile |
+| `T` | Transaction reference; output selection requires a profile |
+
+## Security considerations
+
+Distinguish malformed input, unknown transaction, missing output, unsupported content and unavailable history. Resource limits or network failures MUST NOT be represented as proof that content does not exist. Transaction data from a gateway must be checked against its txid; confirmation and chain validity require separate validation. Mutable selectors depend on the gateway's knowledge and can change under reorganization. Applications rendering executable content need their own isolation policy.
+
+## Implementations
+
+[b-open-io/1sat-stack](https://github.com/b-open-io/1sat-stack) provides underscore output references, compatible dot parsing and ORDFS resolution. Its [`pkg/ordfs/ordfs.go`](https://github.com/b-open-io/1sat-stack/blob/589884a6a445a57b62e79057d27040660bdaec37/pkg/ordfs/ordfs.go) illustrates gateway selection and sequence behavior; [`pkg/ordfs/routes.go`](https://github.com/b-open-io/1sat-stack/blob/589884a6a445a57b62e79057d27040660bdaec37/pkg/ordfs/routes.go) handles serving paths. Implementation permissiveness does not establish universal conformance to the stricter producer grammar proposed here.
+
+## References
+
+- [BRC-36: Format for Bitcoin Outpoints](./0036.md)
+- [BRC-159: 1Sat token identity](../tokens/0159.md)
+- [BRC-160: Inscription envelopes](../tokens/0160.md)
+- [BRC-180: B content](https://github.com/opldotdev/BRCs/blob/codex/brc-180-b-protocol/scripts/0180.md)
+- [RFC 3986: URI syntax](https://www.rfc-editor.org/rfc/rfc3986)

outpoints/README.md

@@ -9,3 +9,4 @@ BRC | Standard
 38   | [User Wallet Data Format](./0038.md)
 39   | [User Wallet Data Format Encryption Extension](./0039.md)
 40   | [User Wallet Data Synchronization](./0040.md)
+184  | [Outpoint Content Addressing](./0184.md)