> For the complete documentation index, see [llms.txt](https://bsv.brc.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bsv.brc.dev/overlays/0178.md). # Race-Settled Collection Markets for Overlay Lookups and Message Boxes Deggen () ## Abstract This BRC specifies a client-judged payment market that lets a network of independent overlay hosts and message box servers compete to answer the same query. A client broadcasts an authenticated request, ranks responses by the time they actually arrive, and pays the fastest hosts that attest the same content hash. Payment is split across a configurable top-K set using square-root weights so that second- and later-place hosts still earn enough to stay viable, while first place still earns more than fifth. A possession threshold on the content hash makes isolated possession insufficient to collect: eligibility requires `t` distinct host identity keys attesting the same hash. Recipients need not hold BSV. The sender of a stored message MAY pre-fund a collection grant that the recipient spends at collect time. The same market applies to BRC-24 overlay lookups, BRC-33 message box collection, and other relay lookups whose result is a byte string that can be hashed. This BRC does not replace a single trusted host. Applications that already trust one regulated operator MAY keep using one message box URL. This BRC is the interoperable economics layer for operators who want the same query to be answerable by any honest host in a set. ## Copyright This BRC is licensed under the Open BSV License. ## Motivation BRC-33 defines a store-and-forward message box addressed by identity key. BRC-34 and overlay advertisements let clients discover hosts. BRC-24 defines overlay lookup. BRC-41 and BRC-105 define how a single HTTP host can charge for a request. None of those standards specify how a *set* of hosts should be paid when all of them can answer the same query. Two failures follow from that gap. 1. A single message box URL is a single point of failure and a single point of trust. If that host drops, swaps, or delays a message, the client has no competing supplier. 2. Hardening only the *lookup* path with overlay quorums, while still delivering the message to one URL, is incomplete. The destination remains a single server that can drop everything the quorum agreed about. A fully on-chain mailbox avoids the single host but re-prices every message as a permanent inscription. A Byzantine consensus layer among hosts can agree on directory state, but hosts that are not miners have no native reward for honesty. This BRC takes a narrower cut. The scarce resource is *timely, verifiable delivery of a hashed payload*. The client is the judge of arrival time because only the client observes arrival. Hosts are paid only when: * the payload hash they attested is the hash the client accepted, and * enough distinct hosts attested that same hash. Eligibility is then a function of shared possession, not isolated possession. A host that can answer quickly still needs `t` distinct identity keys to have attested the same content hash before the client may pay. Racing to respond determines how the fee is split. BSV micropayments make a long-tail split practical. Overlay lookup data is a commodity. Any honest host can obtain the same payload from the chain or from a peer. The product users actually buy is collective availability: no single operator can credibly sell more than about 99.9% uptime without extreme cost, so even the current fastest host benefits when another host is up during its outage. Withholding payload from other operators in order to starve them therefore shrinks the reliability of the market the withholder itself sells. The rational strategy for an operator is to be as fast as it can, not to hoard. Geographic proximity to clients and pre-computation of likely answers are investments. The race pays for them. The protocol MUST NOT penalize a host for being close to its customers or for having warm caches. Identity keys are the account model. Every query is authenticated under BRC-103 so a host can attribute payment, reputation, and rate limits to a stable public key rather than an IP address or a cookie. ## Scope In scope: * the query, attest, collect, and pay flow between one client and many hosts * the content-hash attestation threshold * the square-root payout function, protocol floor fee, and default SLAP-tracker bootstrap * sender-funded collection grants for empty-wallet recipients * identity-key reputation for non-payment * application of the market to BRC-24 lookups and BRC-33 message listing * complete-payload hash check at collect time * sender grant expiry and reclamation * operator discretion to refuse a query Out of scope: * the wire format of BRC-33 message bodies and BRC-24 `output-list` answers, which remain as defined in those BRCs * host discovery, which remains BRC-23, BRC-25, BRC-34, BRC-101, and BRC-169 * identity binding of a human handle to an identity key, which remains BRC-52, BRC-68, and BRC-169 * on-chain inscription of message payloads * a new consensus protocol among hosts ## Terminology | Term | Meaning | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Host | An independent overlay node or message box server that stores or can reconstruct a payload and will answer queries. | | Client | A wallet or application that issues a query and settles payment. Often the recipient of a stored message; sometimes a third-party lookup caller. | | Identity key | A BRC-103 / BRC-31 public identity key. Accounts in this market are identity keys. | | Query | An authenticated request for a named payload class (a message box listing, an overlay lookup, or a relay lookup). | | Payload | The byte string a host would return for a query. | | Content hash | `SHA-256` of the canonical payload encoding defined for that query class. | | Attestation | A host signature over the query identifier and a content hash, proving the host claims to hold that payload. | | Threshold `t` | Minimum number of distinct host identity keys that MUST attest the same content hash before the client MAY pay. | | Top-K | The number of fastest valid responders that share the fee. Default `K = 5`. | | Floor fee | Protocol minimum satoshis the client MUST attach to a collect that returns a non-empty payload. | | Collection grant | Satoshis locked by a message sender so a recipient can collect without holding BSV. | | Race window | Short interval after the first valid attestation during which the client continues to accept competing attestations. | | Square-root weights | Payout weights `sqrt(k - i + 1)` for 1-based rank `i` among `k` paid hosts. | | SLAP trackers | Client-shipped, signed, versioned list of default overlay host URLs used as the initial diverse host set. Replaceable by the client. | | Adjusted ranking | Client-measured arrival order. No RTT subtraction. Proximity is not discounted. | ## Specification ### Roles and trust boundary A host is trusted only to store and return bytes. A client MUST treat host-advertised timestamps, ranks, and "I was first" claims as untrusted. Arrival time is measured on the client. A host signature is trusted only as a statement by that host's identity key. A client that wants availability from a set of hosts MUST NOT depend on any one host being honest, live, or well-connected. The protocol remains useful with one host (`t = 1`, `K = 1`); that profile is the existing single-server model and is permitted. ### Authentication Every query, attestation, and collect request MUST be authenticated so that the caller's identity key is bound to the exact request bytes. 1. HTTP transports MUST use BRC-103 mutual authentication over BRC-104. 2. Implementations SHOULD use the `@bsv/auth` package, or an equivalent BRC-103 binding, so the identity key is present on every request without a side channel. 3. The authenticated identity key of the client is the account against which hosts apply rate limits and reputation. 4. The authenticated identity key of the host is the account that receives payout outputs and that is counted toward threshold `t`. Replay protection follows BRC-103 session nonces. A host MUST reject an attestation or collect whose query identifier it has already settled. ### Canonical payload hashing The content hash is `SHA-256(canonicalPayload)`. Canonical encodings: | Query class | Canonical payload | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `message-list` | UTF-8 JSON array of BRC-33 message objects sorted by `messageId` ascending, with object keys in the order `messageId`, `sender`, `body`. Empty list hashes the UTF-8 bytes `[]`. | | `message-body` | Compact UTF-8 JSON of the BRC-33 message body object, object keys sorted lexicographically, no insignificant whitespace. Hosts MAY store any encoding. The attested hash MUST be `SHA-256` of these canonical bytes, not of the locally stored bytes. | | `overlay-lookup` | The BRC-24 `application/octet-stream` encoding of an `output-list` when available; otherwise UTF-8 JSON of the `output-list` object with stable key order `type`, `outputs`. | | `relay-lookup` | The raw response body the relay would return for that lookup key. | Hosts that disagree on canonicalization will disagree on the hash and will fail the threshold. Implementations MUST use the table above. Storage format is not the attested format. A host that attests `SHA-256` of non-canonical bytes is not interoperable and MUST be treated as a different content hash. ### Query identifier A client constructs a query object and a query identifier: ```json { "type": "message-list", "client": "", "hostSetHint": [""], "params": { "recipient": "", "messageBox": "payment_inbox" }, "maxFeeSats": 20, "floorFeeSats": 2, "threshold": 3, "topK": 5, "raceMs": 400, "expires": "2026-09-18T19:05:00.000Z", "nonce": "<32-byte hex>" } ``` `queryId` is `SHA-256` of the UTF-8 JSON query object with keys sorted lexicographically. The client broadcasts the query to every host it is willing to pay. Hosts not listed in `hostSetHint` MAY still answer. `hostSetHint` is an optimization, not an allow-list, unless the client sets an implementation-defined policy flag `strictHosts: true`. ### Phase 1 — Attest A host that can answer the query returns an attestation without necessarily shipping the full payload. #### Attestation payload | Field | Type | Description | | --------------- | ----------------- | ------------------------------------------------------------------ | | `type` | String | Must be `attest`. | | `queryId` | String (hex) | The query identifier. | | `host` | String (hex) | Host identity key. | | `contentHash` | String (hex) | `SHA-256` of the canonical payload. | | `payloadSize` | Integer | Size in bytes of the canonical payload. | | `quotedFeeSats` | Integer | Host's requested share if it were sole winner. Informational only. | | `attestedAt` | String (ISO 8601) | Host-claimed time. Untrusted for ranking. | | `signature` | String (hex) | BRC-77 signature by `host` over the attestation preimage. | Attestation preimage, concatenated as UTF-8 with `\n` separators: ``` BRC-178 attestation ``` A host MAY attach the full payload in Phase 1. Clients MAY use an attached payload to start hashing immediately, but MUST still wait for the race window and threshold before paying. #### Client ranking 1. Record the local arrival time of each syntactically valid attestation. 2. Discard attestations with an invalid signature, an expired `queryId`, or a `host` identity key that does not match the BRC-103 session. 3. Group remaining attestations by `contentHash`. 4. After `raceMs` from the first valid attestation, or sooner if `t` attestations for one hash have arrived and the client is satisfied, select the `contentHash` with the most distinct hosts. Ties break to the hash whose earliest attestation arrived first. 5. If the winning hash has fewer than `t` distinct hosts, the client MUST NOT pay. It MAY retry, widen the host set, or fall back to a configured single host. 6. Sort hosts that attested the winning hash by client-measured arrival time, ascending. That order is the race ranking. 7. Arrival time is the local receive time of a syntactically valid attestation. The client MUST NOT subtract measured RTT, MUST NOT penalize geographic proximity, and MUST NOT treat a warm or pre-computed answer as invalid. Those are legitimate sources of speed. 8. `raceMs` MAY be adapted from observed network conditions. Randomizing `raceMs` per query is OPTIONAL and is not required to defend proximity. Default parameters: | Parameter | Default | Notes | | -------------- | ------- | ---------------------------------------- | | `t` | `3` | `1` restores single-host mode. | | `K` | `5` | `K` MUST be `>= t` unless `t = 1`. | | `raceMs` | `400` | Clients MAY adapt based on measured RTT. | | `floorFeeSats` | `2` | MUST be at least `1`. | ### Phase 2 — Collect and pay The client sends a collect request to the ranked hosts, or to any host that attested the winning hash. Payment is a single BSV transaction with one output per paid host. #### Collect request | Field | Type | Description | | ------------- | ----------------- | ------------------------------------------- | | `type` | String | Must be `collect`. | | `queryId` | String (hex) | The query identifier. | | `contentHash` | String (hex) | The winning hash. | | `ranking` | Array | Ordered host identity keys, fastest first. | | `payment` | Object | BRC-105 / BRC-29 payment envelope. | | `grant` | Object or omitted | Optional collection grant spend, see below. | The `payment` object MUST be a BRC-105 `x-bsv-payment` JSON body (or the equivalent header on HTTP) whose transaction pays the ranked hosts. ### Square-root weights An earlier version used Fibonacci weights; this BRC uses square-root weights. Let `k` be `min(K, number of ranked hosts that attested the winning hash)`. The weight for rank `i` (1-based, 1 is fastest) is: ``` weight(i) = sqrt(k - i + 1) ``` The fee `R` is `max(floorFeeSats, client-chosen fee, sender grant remainder)` satoshis. Let `S = weight(1) + ... + weight(k)`. ``` payout(i) = floor(R * weight(i) / S) ``` Any remainder `R - sum(payout)` is added to `payout(1)`. Implementations MUST compute weights in ordinary floating point, then apply `floor` only at the payout step. Do not integer-truncate the square roots before summing `S`. Worked example, `k = 5`, `R = 12`. Weights below are IEEE-754 binary64 values of `sqrt` (ordinary floating point). Raw floors are computed first. The remainder is applied only after that sum. `S` = 2.236067977499790 + 2.000000000000000 + 1.732050807568877 + 1.414213562373095 + 1.000000000000000 = 8.382332347441762 | Rank | Weight (exact) | Weight (binary64) | `R * weight / S` | Raw floor | Payout | | ---- | -------------- | ----------------- | ----------------- | --------- | ------ | | 1 | sqrt(5) | 2.236067977499790 | 3.201115705962994 | 3 | 5 | | 2 | sqrt(4) | 2.000000000000000 | 2.863164928950193 | 2 | 2 | | 3 | sqrt(3) | 1.732050807568877 | 2.479573563695535 | 2 | 2 | | 4 | sqrt(2) | 1.414213562373095 | 2.024563336916181 | 2 | 2 | | 5 | sqrt(1) | 1.000000000000000 | 1.431582464475097 | 1 | 1 | Sum of raw floors = 3 + 2 + 2 + 2 + 1 = 10. Remainder `12 - 10 = 2` is added to rank 1. Final payouts are 5, 2, 2, 2, 1. First place is strictly above fifth, and ranks 2 through 5 are non-zero. Dividing the same weights rounded to three decimal places (`2.236`, `2.000`, `1.732`, `1.414`, `1.000`, `S = 8.382`) as exact decimals produces the same raw floors and the same remainder adjustment. Quotients below are the exact values, truncated: ``` floor(12 * 2.236 / 8.382) = floor(3.201145311381531...) = 3 floor(12 * 2.000 / 8.382) = floor(2.863278453829634...) = 2 floor(12 * 1.732 / 8.382) = floor(2.479599141016463...) = 2 floor(12 * 1.414 / 8.382) = floor(2.024337866857551...) = 2 floor(12 * 1.000 / 8.382) = floor(1.431639226914817...) = 1 ``` Sum of those floors is 10. Remainder 2 added to rank 1 yields 5, 2, 2, 2, 1. Worked example, `k = 3`, `R = 20`. Binary64: `S` = sqrt(3) + sqrt(2) + sqrt(1) = 1.732050807568877 + 1.414213562373095 + 1.000000000000000 = 4.146264369941973 ``` floor(20 * 1.732050807568877 / 4.146264369941973) = floor(8.354753354008237) = 8 floor(20 * 1.414213562373095 / 4.146264369941973) = floor(6.821627548042177) = 6 floor(20 * 1.000000000000000 / 4.146264369941973) = floor(4.823619097949584) = 4 ``` Sum of raw floors = 18. Remainder `20 - 18 = 2` is added to rank 1, which receives 10. Payouts: 10, 6, 4. The same floors follow from the three-decimal sketch `S = 1.732 + 1.414 + 1.000 = 4.146`, using exact decimal division (quotients truncated): ``` floor(20 * 1.732 / 4.146) = floor(8.355041003376748...) = 8 floor(20 * 1.414 / 4.146) = floor(6.821032320308731...) = 6 floor(20 * 1.000 / 4.146) = floor(4.823926676314520...) = 4 ``` Sum of floors = 18, remainder 2, rank 1 receives 10. Payouts: 10, 6, 4. Outputs use BRC-29 derivation. For ranked host `i`: * counterparty is that host's identity key * `derivationPrefix` is `queryId` * `derivationSuffix` is the two-byte big-endian rank `i` This binds each output to one query and one rank and prevents a host from claiming a different rank's output. A client MUST create outputs only for hosts that attested the winning hash. A client MUST NOT pay a host that attested a different hash. Non-normative: a host that slows down over time while remaining inside the paid top-K still loses weight on the square-root curve as soon as another host overtakes it. The curve is not flat. Clients MAY additionally decay a host's effective weight if that host's median collect latency worsens over a rolling window; this is local policy, not a consensus rule. #### Host collect response A host that accepts the collect MUST return the complete canonical payload whose hash is `contentHash`, plus a BRC-77 signature over `queryId || contentHash || payloadSize`. The client MUST hash the entire received payload. The client MUST accept the payload only if that hash equals the committed `contentHash` and the received length equals `payloadSize`. A prefix that hashes correctly is not sufficient. Truncation, early close, or trailing garbage is a failed collect. On mismatch the client MUST NOT acknowledge the collect against that host, MUST NOT treat that host as having been paid for this `queryId`, and SHOULD lower local reputation for that host identity key. Because the payment transaction is already bound to `queryId` and rank, a client that received matching complete bytes SHOULD broadcast the transaction. ### Sender-funded collection grants A recipient who has never held BSV still needs to collect. The sender of a stored message MAY attach a grant. When calling BRC-33 `sendMessage`, the sender MAY include: ```json { "collectionGrant": { "satoshis": 20, "expires": "2026-10-18T00:00:00.000Z", "minThreshold": 3, "transaction": "" } } ``` The grant transaction pays an output that the recipient's identity key can unlock under BRC-42 / BRC-29, using: * protocol ID `[2, "BRC-178 collection grant"]` * key ID equal to the message's `messageId` as a decimal string The message box host MUST store the grant with the message and MUST release grant details to the authenticated recipient on `listMessages`. At collect time the recipient (or their wallet) spends the grant into the square-root payout outputs. The recipient does not need an independent BSV balance. If no grant exists, the recipient pays from their own wallet, or the collect fails with a payment-required error per BRC-105. A grant MUST meet the floor fee. Senders MAY attach more than the floor to buy faster propagation: hosts SHOULD gossip messages with larger remaining grants first. If a grant expires unspent, the sender's wallet MAY reclaim it. Hosts MUST stop advertising expired grants. Reclamation window: after `expires`, hosts MUST stop advertising the grant immediately. The sender MAY sweep the grant output at any time after `expires`. This BRC does not require an extra delay block. Implementations SHOULD treat `expires` as the sole cut-off so value is not stranded between expiry and an undefined later deadline. At collect time the recipient spends the grant into the square-root payout outputs. ### Eligibility threshold A host is eligible for payout on a query only if it is one of at least `t` distinct hosts that attested the same `contentHash` for that `queryId`. This is an eligibility rule, not a moral rule about sharing. Isolated possession of a payload is not enough to collect when `t > 1`. Propagation is the ordinary way a host joins a threshold set. This BRC does not require a host to gossip; it only refuses payment when `t` is not met. Withholding payload from other operators is allowed by the protocol and is usually self-defeating. The payload is obtainable from the chain or from any honest peer. The market users pay for is the chance that *some* host is up. An operator that starves every competitor reduces the collective uptime that makes overlay lookup trustworthy, including during that operator's own outages. The specified default strategy is: be fast; do not rely on exclusive possession. Hosts SHOULD forward a newly stored payload to a random subset of advertised peers promptly. Gossip wire format remains BRC-34, BRC-23, and BRC-88. ### Operator discretion A query is an offer to pay for an answer. It does not bind any host. A host MAY refuse any query for any reason, including commercial, operational, or political reasons. Refusal is not a protocol violation. Clients MAY keep a local note of which hosts declined which query classes and MAY use that note when building `hostSetHint`. This BRC does not require hosts to explain a refusal and does not treat refusal as slashable. ### Honor, reputation, and optional query deposits Micropayment amounts in this market are often too small to justify an on-chain dispute. The default profile is honor plus reputation: 1. Compliant clients always broadcast a valid payout transaction after accepting a payload whose hash matches the committed `contentHash`. 2. Compliant hosts always propagate payloads they intend to collect on, and always return those exact bytes on collect. 3. Each host MAY keep a local reputation score keyed by client identity key. A client that repeatedly collects and does not broadcast payment MAY be rate-limited, required to attach a query deposit, or refused. 4. Each client MAY keep a local reputation score keyed by host identity key. A host that attests a hash and then delivers different bytes, or that consistently misses the race window, MAY be dropped from `hostSetHint`. Optional query deposit, for hosts that do not trust a client: | Field | Type | Description | | --------------------- | ------- | ----------------------------------------------------------------- | | `depositSats` | Integer | Satoshis locked by the client with the query. | | `depositTx` | String | Atomic BEEF of the deposit. | | `refundIfNoPayloadMs` | Integer | If no valid collect completes, the deposit returns to the client. | A host that delivered a matching payload and can prove non-payment MAY claim the deposit as compensation. Proof of non-payment is the existence of a completed collect transcript and the absence of the expected payout transaction in a subsequent window. This profile is OPTIONAL. Implementations that deal only in dust-sized fees SHOULD skip deposits and rely on reputation. ### Floor fee The network floor exists so a sender cannot starve collectors by attaching a zero grant. * `floorFeeSats` MUST be at least `1`. * The recommended default is `2`. * Hosts MAY refuse to store or gossip a message whose grant is below the floor. * Hosts MAY advertise a higher local floor. Clients treat the effective floor as the maximum of the protocol default and the floors advertised by the hosts they intend to pay. * The floor MAY vary with `payloadSize`. A recommended schedule is `2` satoshis plus `1` satoshi per 1024 bytes of canonical payload, rounded up. ### Bootstrapping and default SLAP trackers A new host set has no traffic and therefore no fees. The intended first operators are non-profit hosts that run at cost on the square-root curve (or flatter) and publish every topic they know. That non-profit baseline is the speed and coverage floor commercial hosts must beat. After several commercial hosts exist, clients MAY keep using the same curve; this BRC does not automatically steepen weights. Default SLAP trackers: client software SHOULD ship a signed, versioned list of overlay host URLs (SLAP trackers) covering known topics. The default list is the diversity backbone for query broadcast. It exists so a client is not limited to whatever hosts happen to sit on its current network path. Requirements: 1. The list MUST be signed by a well-known publisher key shipped with the client or retrieved over a pinned channel. 2. The list MUST carry a version and a fetched-at time. 3. The client MUST be able to replace the list with a user-supplied list. The default is a starting point, not a choke point. 4. `hostSetHint` SHOULD be initialized from the current tracker list, then refined by local reputation. 5. An eclipse of the client's local network path does not fill threshold `t` unless the attacker also displaces the tracker-derived host set. Compromising the publisher of the default list is a trust-root failure; clients mitigate by replacing the list. An application treasury MAY additionally pay a declining per-query subsidy to every host that produced a valid attestation included in a threshold set, for a fixed number of months. The subsidy MUST be disclosed. This BRC does not require a subsidy. ### HTTP binding Hosts that already speak BRC-33 and BRC-24 keep those paths working. This BRC adds three routes, all BRC-103 authenticated: | Method | Path | Body | | ------ | ----------------- | ------------------------------------------------------------------------------------------ | | `POST` | `/brc178/query` | Query object. Returns an attestation, optionally with payload. | | `POST` | `/brc178/collect` | Collect request. Returns the canonical payload. | | `GET` | `/brc178/params` | Unauthenticated. Returns the host's `t`, `K`, `floorFeeSats`, and supported query classes. | A BRC-33 `listMessages` call MAY be answered as a `message-list` query class without a separate `/brc178/query` hop when the client includes the BRC-178 query fields in the existing body. Hosts that do not implement BRC-178 ignore those fields. Payments ride BRC-105 headers: * `x-bsv-payment-version` * `x-bsv-payment-satoshis-required` on a `402` challenge * `x-bsv-payment` on the collect request ### Relationship to a single trusted host An application that already trusts one regulated operator — for example a licensed stablecoin issuer that also runs the message box — MAY set `t = 1` and `K = 1` and ignore square-root splits. That profile is compatible with this BRC and with today's BRC-33 servers. Moving from that profile to `t = 3`, `K = 5` later does not require a new identity scheme. It requires only that additional hosts store the same payloads and that clients raise `t`. ### Generalization Any read that returns a deterministic byte string can use this market. Overlay lookups, UHRP host resolution, handle resolution side-channel records, and relay lookups are the same race: authenticate, attest a hash, wait for threshold, pay the fastest attesters, collect the bytes, verify the hash. Writes (BRC-33 `sendMessage`, overlay ingest) are not raced for payment in this BRC. A write host MAY still charge a BRC-41 / BRC-105 ingest fee of its own. The collection grant is how the writer pays the future readers' hosts. ## Examples ### Example attestation ```json { "type": "attest", "queryId": "a4f1c2e8b0d65c1f9e3a7b2c4d8e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e", "host": "02c0b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "contentHash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08", "payloadSize": 184, "quotedFeeSats": 4, "attestedAt": "2026-09-18T18:59:01.233Z", "signature": "3045022100ab..." } ``` ### Example collect ranking and outputs Fee `R = 12`, `k = 5`. The client constructs one transaction with five BRC-29 outputs of 5, 2, 2, 2, and 1 satoshis to the five host identity keys in ranking order, using the square-root payout function in this BRC (raw floors 3, 2, 2, 2, 1, then remainder 2 added to rank 1). `derivationPrefix` is the `queryId`. `derivationSuffix` is `0001` through `0005`. ### Example empty-wallet collect Alice sends Bob a payment notification. Alice attaches a 20-satoshi collection grant. Bob's wallet has no BSV. Bob's client runs Phase 1 against three advertised hosts, obtains three attestations of the same list hash, spends Alice's grant into the square-root payout outputs, and receives the message bodies. Bob never funded a wallet. ## Implementation Clients: 1. Use `@bsv/auth` (or equivalent BRC-103 HTTP transport) on every host call. 2. Fan the query out in parallel. Rank by local arrival time, never by `attestedAt`. 3. Compute `SHA-256` over the canonical encoding in the table above, not over a pretty-printed JSON variant. 4. Broadcast the payout transaction only after at least one matching payload arrives, and do so promptly. 5. Persist host and client reputation locally. Do not treat another host's reputation gossip as authoritative. Hosts: 1. Advertise BRC-178 support from `/brc178/params` and, when using overlay advertisements, from the existing SHIP/SLAP records. 2. Propagate stored payloads to peers before expecting to win races that require `t > 1`. 3. Verify collect payments with `internalizeAction` against the advertised BRC-29 derivation. 4. Do not persist ephemeral lookup prefixes typed by a user beyond the request lifetime. Fuzzy-search autocomplete is allowed to see partial queries in memory; it SHOULD NOT log them. 5. Refuse grants below the advertised floor. Single-host operators implementing BRC-33 today can add `/brc178/params` returning `t = 1`, `K = 1` and accept BRC-105 payment on `listMessages` without implementing gossip. ## Security considerations * Host-claimed timestamps are not a ranking signal. Rank is client receive time. * Geographic proximity and warm caches are legitimate. The protocol does not discount them. * Threshold `t` is a liveness and safety tradeoff. High `t` raises the number of distinct keys required and also raises the chance a small live set cannot be paid. * A client can collect bytes and withhold payment. Reputation and optional deposits remain the controls. On-chain escrow for dust fees is usually more expensive than the fee. * Collect integrity is complete-payload hash equality. Prefix match is insufficient. * A host MAY refuse any query. Clients may record that fact locally. The protocol does not punish refusal. * Default SLAP trackers are a trust root. They MUST be signed, versioned, and replaceable. * Canonicalization disagreement fails the threshold. Attest the table encoding, not the storage encoding. * Collection grants are value. Authenticate the recipient before revealing grant transactions. After `expires`, stop advertising; sender may sweep. * A host can attest a hash it does not hold, then fail collect. It wastes a rank slot and burns reputation. Clients SHOULD skip such hosts on the next query. * A host can serve a valid payload and still lie in future queries. Hash verification is per query and does not create a durable content-addressed store unless the application also uses BRC-26 / BRC-167. * Fuzzy identity search leaks partial queries to every host that receives them. That leak is accepted for UX. Honest hosts process those prefixes ephemerally. ## References * BRC-24: Overlay Network Lookup Services * BRC-29: Simple Authenticated BSV P2PKH Payment Protocol * BRC-31: Authrite Mutual Authentication * BRC-33: PeerServ Message Relay Interface * BRC-34: PeerServ Host Interconnect Protocol * BRC-41: PacketPay HTTP Payment Mechanism * BRC-42: BSV Key Derivation Scheme * BRC-52: Identity Certificates * BRC-77: Message Signature Creation and Verification * BRC-95: Atomic BEEF Transactions * BRC-103: Peer-to-Peer Mutual Authentication and Certificate Exchange Protocol * BRC-104: HTTP Transport for BRC-103 Mutual Authentication * BRC-105: HTTP Service Monetization Framework * BRC-167: Chunked, Hashed, Interleaved Resolution Protocol (CHIRP) * BRC-169: Universal Handle Addressing and Resolution for the Metanet * `@bsv/auth` npm package --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://bsv.brc.dev/overlays/0178.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.