Add BRC-166: P2PKH Payments for HTTP 402

[andyrowe]

A profile for HTTP 402 settlement on BSV using plain P2PKH payments to a per-invoice address. Any BSV holder can pay (no BRC-100 wallet, BRC-42 derivation, identity key, or BEEF), and settlement is verifiable by any third party from public chain data alone. Complements x402-foundation/x402#2890 (BRC-29/42 mode) rather than competing with it.

Backed by a live mainnet reference implementation at bsv.cx and a captured real settlement transaction. Adds the file to the root and payments indexes.

This pull request:

Proposes a new standard by creating a new markdown file in the appropriate directory and requests discussion

Summary

BRC-166 specifies a permissionless, self-verifying plain-P2PKH profile of the x402 exact scheme on BSV. A payer settles by signing a plain transaction paying the exact amount to a per-invoice P2PKH address; the origin, acting as its own facilitator, verifies the outputs and broadcasts it. No BRC-100 wallet, BRC-29/42 derivation, identity key, or BEEF is required - only a key holding BSV and the ability to sign a raw transaction - and because settlement is keyed off the on-chain locking script rather than a private invoice record, any third party can verify a payment from public chain data alone, without trusting the origin. It is a companion to x402#2890 (which should land first), not a competitor: BSV carries two exact addressing modes, selected by an explicit extra.payloadFormat.kind discriminator. A conforming reference implementation is live on mainnet at bsv.cx, backed by a captured real settlement transaction.

[andyrowe]

Some design context, and the one point I'd most like @sirdeggen's read on.

Companion to #2890, not a competitor. #2890 (BRC-29/42 derived-address BEEF) gives on-chain payee unlinkability; this mode makes the payment itself publicly checkable on-chain against the challenge, which is what lets a facilitator other than the payee confirm a payment.

The design question worth deciding together. x402's exact defines one payload per (scheme, network), and BSV is the first network that legitimately wants two — the wallet-ecosystem mode (#2890) and the permissionless mode (BRC-166). BSV uniquely supports both, and the permissionless mode's entire purpose is serving payers who cannot adopt the first. BRC-166 handles this with an explicit extra.payloadFormat.kind discriminator ("p2pkh-rawtx"), and requires a payer to select a mode only on recognizing the kind, otherwise declining rather than guessing.

Two things I'd propose so the coexistence stays clean:

1. Symmetric discriminators — both modes emit an explicit extra.payloadFormat.kind (e.g. #2890 as "brc29-beef"), so neither is the silent default a naive client falls into. That removes the only wrong-payload-guess failure mode.
2. An umbrella scheme_exact_bsv.md in the x402 repo enumerating both BSV modes and their discriminators, referencing #2890 and BRC-166 as the normative spec for each.

If you'd rather not open (exact, bsv:mainnet) to two payloads, BRC-166 can instead stand as a BSV-native 402 profile that reuses the x402 envelope without claiming the registered exact-bsv payload slot — I'm happy to go that way; the only cost is losing drop-in x402-client compatibility.

Conformance: headers, amount, x402Version: 2, and bsv:mainnet (CAIP-2) follow x402-F v2; the error model follows v2 (402 for verification/settlement failures with a machine errorReason in PAYMENT-RESPONSE, 400 malformed, 500 origin-side, 503 pre-payment).

Drafted with substantial AI assistance (Claude), directed and reviewed by me; recorded in the commit trailers per the contributing guideline.