BRC-170: Locked Content Header (LCH)

[ty-everett]

This pull request:

Proposes a new standard by creating a new markdown file in the appropriate directory and requests discussion and assignment of BRC-170.

Summary

Defines Locked Content Header (LCH), a BSV-native container and licensing protocol for encrypted paid content. The proposal standardizes deterministic CBOR headers, original rights-holder and delegated-seller authority, signed ODRL offers and buyer licenses, BRC-105 and BRC-121 acquisition, BRC-78 and extensible key delivery, segmented range access, quantity and event billing, multilateral BRC-29 payments delivered as Atomic BEEF, and mandatory C2PA provenance for composed works.

Six initial usage profiles cover fixed-price rendering, range metering, event metering, rental, composition, and AI training. Unknown critical mechanisms and unlicensed actions fail closed.

The accompanying conformance package includes deterministic-CBOR objects, positive and negative AES-256-GCM cases, BRC-77 signatures and tamper cases, BRC-78 key recovery, BRC-29 payment scripts, ODRL JSON-LD policies, nested composition and cycle cases, ten end-to-end reference cases with 34 checks, and a signed C2PA MP3 sidecar fixture.

Validation was performed independently with Python cbor2 and cryptography, the BSV SDK, cddl-rs, jsonld.js, and c2patool. Markdown, links, JSON, artifact hashes, and staged diff checks also pass.

[raspi-user]

I reviewed the LCH proposal and think it is valuable and broadly coherent, but I would not merge it unchanged. A few points need tightening so independent implementations do not make incompatible choices.

1. Payment recovery references an undefined offer field.

   Section 11.4 says payees must accept recovery delivery "for at least the Offer's declared recovery period", but the normative offer-body / payment-offer structures do not define where that recovery period is declared. That makes retry/recovery behaviour under-specified. Please add a normative field, define its unit/default/minimum, and include it in the conformance vectors.

2. Endpoint and locator trust rules should be central and normative.

   Discovery entries, payment offers, payment requirements, payment demands, policy locators, human-term locators, and content locators are all plain tstr endpoints/locators. The security section mentions scheme, redirect, local-network, and origin policy, and BRC-105 constrains payment identity, but implementers need one normative endpoint policy: allowed schemes, redirect behaviour, local/private network handling, TLS/BRC identity expectations, and which endpoint classes must be identity-bound.

3. lch:offer:self placeholder handling needs exact processing rules.

   The placeholder solves the circular Offer ID problem, but the substitution scope/order is not precise enough. It should be explicit that only the ODRL Offer uid field is virtualised during ODRL evaluation, and that arbitrary occurrences of the same literal string in targets, parties, constraints, nested policies, or extension data are not rewritten unless separately specified.

4. randomizeOutputs=false may conflict with wallet policy.

   The multilateral profile requires BRC-100 randomizeOutputs=false so output indices remain stable. That is understandable for receipt verification, but it needs a refusal path for wallets that do not allow deterministic output ordering for privacy or policy reasons. If possible, prefer verifying the exact output script/amount after transaction finalisation instead of making stable global output ordering a hard requirement.

5. C2PA/composition requirements may be too broad for AI training.

   Mandatory C2PA plus a Composition Record works well for media composition, extraction, and derivatives. For training workflows, "for each source Asset" may become impractical for large datasets unless the BRC defines a dataset, batch, or manifest aggregation profile. Otherwise conforming training implementations may be forced into unworkable provenance graphs.

6. Authority revocation needs an exact verification algorithm.

   Authority grants mention revocationOutpoint and BRC-52 semantics, but implementers need precise validation rules: proof source, confirmed vs mempool state, reorg handling, offline/cache behaviour, and what evidence is sufficient to treat an authority chain as still valid.

Overall: the proposal is strong, but the recovery-period issue is a concrete spec bug, and the endpoint / placeholder / wallet-output rules should be made deterministic before this becomes a BRC.

[ty-everett]

Addressed all six review areas and carried the resulting rules into the draft TypeScript implementation:

1. Recovery is now explicit: every Offer declares recoveryPeriodSeconds; Demand/Quote objects carry a signed, exclusive recoveryUntil; new-payment and idempotent-recovery boundaries are distinct.
2. Endpoint trust is centralized and fail-closed across operational endpoints and HTTPS/UHRP/CHIRP locators, including DNS/address checks, redirect rules, credential stripping, limits, and protocol-role identity.
3. ODRL self references now virtualize only the exact top-level uid after digest checking and pinned parsing; no global string replacement is permitted.
4. Wallet output order is unconstrained. Implementations identify each Demand output from the finalized transaction by exact script and amount, rejecting missing, duplicate, and ambiguous matches.
5. train alone does not imply a Composition Record. Explicitly claimed training sources use inputTo; aggregate dataset commitments remain future-profile work.
6. Revocation now defines exact states, freshness, network/tip evidence, mempool behavior, reorganization invalidation, and offline fail-closed caching.

Implementation-driven clarifications added in the same update:

• exact half-open time semantics for notBefore, notAfter, expiresAt, and recoveryUntil;
• every and only intersecting key periods, including complete whole-asset delivery;
• canonical BRC-78 version bytes 42 42 10 33;
• distinct C2PA assertion bindings for repeated placements;
• whole-placement-v1 remains conservative but does not prohibit repetition, trimming, reversal, rational-rate time warps, distortion, mixing, or other licensed editorial operations; edit descriptions stay non-critical metadata and selective/proportional mappings remain future profiles.

The portable vector file was regenerated from the built implementation and independently checked. It now covers exact time boundaries, randomized payment-output matching, complete key-period rules, six distinct editorial placements, repeated-source/C2PA behavior, training provenance, and BRC-78 recovery. Its deterministic SHA-256 is 92c834e0be390cde0f3935c2cc0e7f96657c6ad56bc478d6bd643ccd8770598a.

The corresponding draft TS Stack reference implementation is now open at bsv-blockchain/ts-stack#501. Both PRs remain drafts while exact-head CI and review feedback are completed.

[ty-everett]

Exact head b82b95e1041897e10e9899c37a11c051dabd531c incorporates the acquisition-flow discoveries from the executable TS Stack reference implementation.

The draft now normatively binds every Payment Demand to the signed License Request buyer, uses public BRC-77 anyone signatures for multilateral Request and Delivery messages, defines exact Payee BRC-29 derivation with forSelf: true, and specifies the BRC-100 internalizeAction wallet-payment remittance. It also explains the issuer verification boundary: the issuer verifies transaction identity, distinct exact outputs, amounts, Request/Payee/Demand bindings, Payee signatures, and receipts, while each Payee attests the locking script it alone can derive.

Section 11.5 now supplies a deterministic-CBOR HTTP binding for preflight, request, quote, demand, delivery, receipt, completion, license, and recovery, with exact media types, bounded bodies, no-store behavior, stable errors, role binding, and idempotency. Deployment guidance identifies the creator wizard, content host, issuer, Payee wallets, buyer wallet, and player, together with durable ledger/CEK storage boundaries and CHIRP/UHRP hosting adapters. The text also states the v1 pre-expiry evidence limit rather than implying that Atomic BEEF proves creation time.

The portable vectors were regenerated from the implementation. Their SHA-256 is 448f72f135832de872219827e5bf0298cdb6e44a5167773b39438141b12941f4; every Demand buyer was independently checked against its Request buyer. Exact-head BRC CI is fully green and there are no unresolved review threads. This PR remains draft alongside TS Stack PR #501 for protocol review and an independent interoperability implementation.

[ty-everett]

Federated Payee delivery semantics are now on exact head ed956f3e3a7486b7c96844ca2e137a4ee34f4210.

The draft now states that every Payment Demand endpoint is independently chosen or approved by that Payee and does not inherit issuer origin, operation, or wallet custody. It requires persistence of the Quote, funded Atomic BEEF, remittances, and signed Deliveries before fan-out; retention of partial valid Receipts; retry with the same transaction; direct dispatch by each signed endpoint; and completion only with one authentic Receipt per Demand.

The HTTP binding remains the portable v1 acquisition binding. An HTTP endpoint may gateway to a message box while preserving the observable contract. A future native asynchronous/message-box profile must define addressing, authentication, correlation, acknowledgements/replies, expiry, and replay without changing the signed Demand, Delivery, or Receipt objects.

The new federated-band conformance case places the issuer, drummer, and composer at three distinct HTTPS origins with independently controlled wallets, includes a partial outage/retry, requires wrong-route rejection, and forbids replacement transaction creation.

All 4 exact-head checks are green, there are no unresolved review threads, and local and remote heads match. The proposal remains draft alongside the TS Stack reference implementation for interoperability review.

[ty-everett]

Availability and authorized-output settlement refinement is complete at 418ed7e.

The specification now defines:

• receipt-complete-v1 as the direct-Payee baseline.
• authorized-output-v1 as an explicit per-Demand opt-in profile.
• Signed Payment Authorization, Transaction Evidence, Payment Delivery Acknowledgement, and Payment Delivery Retrieval objects.
• License release only from a complete, profile-specific evidence bundle.
• Exact Payee-authorized BRC-29 script and amount verification, atomic Authorization-to-first-txid binding, durable byte-exact Delivery retention through recovery, authenticated late retrieval, and fail-closed behavior.
• Explicit handling for offline Payees, evidence or delivery provider outage, wrong output, broadcast-only evidence, short retention, conflicting transactions, and receipt-only fallback rejection.
• Explicit tradeoffs around provider trust and availability, accepted versus mined state, reorg or conflict risk, privacy and linkability, and key release before Payee internalization. Silence or timeout never substitutes for signed proof.

Validation:

• Portable vectors regenerate byte-for-byte identically with SHA-256 4e4e43cd9fdf8df16ae34e79fd1c92d042b32482de69eb9ad3118c88c5e3f775.
• Markdown fences, JSON, authorized-output vector presence, and all 46 local links validate.
• Exact-head CI has 4 successful checks: CodeQL and both GitBook surfaces.
• No unresolved review threads.

The matching reference implementation is bsv-blockchain/ts-stack#501 at d0fddb9c8ace9b84816ccc6d7281a5d4176c36d5. Its exact-head CI is fully green, including Codecov patch coverage at 90.20619%.