Private Overlays with P2PKH Transactions
An index does not have to build its view purely from what is written on chain. This shows how one can track ordinary payments privately, keeping the interesting details off the public record.
18 standards
Privacy
What a third party can work out by watching. Standards here reduce what is visible: payments that do not carry the sender's long-term key, overlays that stay private, and derivation that leaves no public link between two keys.
Also searched as unlinkability, anonymity, surveillance, confidentiality.
Filed under
18 standards, spread across 8 of the 12 topics.
Start with
BRC-228
Unlinkable Payments under the Identity Paradigm
Sending someone a bit of digital cash normally means telling them who you are, because the payment format includes your long-term identity key. That's fine for a friend or a business you trust, but it means every coffee tip or casual peer payment lets the recipient permanently tag it to your identity and link it to every other payment you've ever made them. There was no easy way to pay someone spendable coins for a one-off transaction while keeping your long-term identity out of the record.
Filed under Payments
Standards about this
Privacy is the main subject of these 5.
81 109 PCW-1 : Peer Cash Wallet Protocol
Two people who want to pay each other directly still tend to route the payment through a service. This describes a wallet flow where the two devices negotiate between themselves and settle as several independent transactions.
152 Best Practices for Regulated Tokens in a BRC-100 Ecosystem
A wallet holding ordinary money, collectibles, credentials and regulated assets at once has to treat them very differently, and nothing says how. This works through what a developer should do so the strict cases stay strict.
221 Deterministic, Order-Independent Coin Selection for Privacy Wallets
A wallet does not pick its own order for the spendable outputs it knows about; some outside source hands them over in whatever order that source chooses. If a privacy-focused wallet's logic for choosing which outputs to spend secretly depends on that order, the source can quietly steer which of the holder's keys get linked together in a payment, and rebuilding the "same" payment later can spend a different set of outputs than before, exposing both attempts to an observer.
228 Unlinkable Payments under the Identity Paradigm
Sending someone a bit of digital cash normally means telling them who you are, because the payment format includes your long-term identity key. That's fine for a friend or a business you trust, but it means every coffee tip or casual peer payment lets the recipient permanently tag it to your identity and link it to every other payment you've ever made them. There was no easy way to pay someone spendable coins for a one-off transaction while keeping your long-term identity out of the record.
Standards that touch it
These are about something else, and deal with privacy on the way.
38 User Wallet Data Format
Wallet data trapped inside one provider's software is a problem for the user who wants to leave and for anyone who has to answer a data request. This defines a single portable file holding everything about one user's wallet.
44 Admin-reserved and Prohibited Key Derivation Protocols
If applications and the wallet itself draw keys from the same pool, an application can trample on the wallet's own records. This sets aside a range of names for the wallet's internal use and puts them beyond application reach.
52 Identity Certificates
Proving something about yourself online usually means trusting whoever is asking with all of it. This defines a certificate where a third party vouches for your details and you choose which of them any particular verifier gets to see.
69 Revealing Key Linkages
Keys derived between two parties are deliberately unlinkable, which is usually the point and occasionally a problem when someone has to audit a relationship. This describes two ways to deliberately reveal that link, and is clear about how much each one gives away.
72 Protecting BRC-69 Key Linkage Information in Transit
Revealing how two parties' keys are linked hands over something genuinely sensitive, and sending it in the clear defeats the purpose. This adds encryption around that revelation so only the intended recipient learns it.
77 Message Signature Creation and Verification
Signing a plain message is not the same problem as signing a transaction, and doing it ad hoc leads to signatures nobody else can check. This defines how messages are signed and verified, including signatures only the intended recipient can confirm.
84 Linked Key Derivation Scheme
Deriving a shared key normally needs one party's private key, which rules out cases where neither side can act. This extends the derivation so a key can be worked out from both parties' public keys alone.
168 Verifiable Time Allocation
Timesheets are just typed claims that nobody can check after the fact, so disputes about hours worked come down to trust in whichever party controls the record. There was no way to make a weekly time claim that was both unforgeable in its total and private until the person who made it chose to reveal part of it. This closes that gap by anchoring a fixed, 168-hour-bounded claim on chain and letting disclosure happen hour by hour, to whoever the holder picks.
182 Pairwise Authentication
A BSV wallet normally logs into every website using the same permanent public key. That means any two sites that compare notes can tell their visitor is the same person, and the user has no way to stop it or start fresh. This makes it hard to build sites where users want separate, unlinkable accounts, like a different presence on each service.
186 Thoughts on UTXO-Driven Applications and Private Overlays
Early designs for tracking and coordinating transaction-based state tended to assume everyone needed to see everything, which does not match how most real applications actually share data. Teams building on top of transaction outputs had no shared way to think through when to keep an overlay open to everyone versus restricted to a known set of participants, so designs ended up copying patterns that did not fit their actual trust or privacy needs. This leaves developers without a clear mental model for choosing the right shape of network for their application.
191 Thoughts on Identity, Privacy and Recovery on the Metanet
Right now, proving who you are online usually means handing over a company's whole account system, your transaction history, or a permanent public record just to buy something or prove a right. If your phone breaks or your provider goes bad, you can lose both your money and years of accumulated app data and relationships, with no clear way to get them back or take them elsewhere.
202 Identity-Key Decentralized Identifiers
If an app wants to treat a user's public key as a standard identity identifier that other DID-aware tools understand, there's no agreed way to turn that key into such an identifier without inventing something ad hoc or pulling in a name, serial number, or external registry that doesn't actually represent the key itself. This leaves apps unable to plug a BSV identity key into generic decentralized-identity tooling, or tempted to fake metadata that isn't really known.
212 Compact Wallet Feature Flags in `getVersion`
A wallet reporting its version to an app used to need one chunky piece of text for every single feature it wanted to advertise, like "offline payments supported" or "color module supported". Stack up a dozen features and the version string blows past old length limits that some apps still enforce, so the wallet either hides capabilities or risks crashing the app. There was no cheap way to say "I support these twelve things" in the same space it used to take to say "I support this one thing".
Usually read alongside
Concepts that keep appearing on the same standards as this one.
Was this helpful?