Beered by 3 people
107 standards · 12 topics
An application that wants to move money has to build a Bitcoin transaction, and building one correctly means handling keys, fees and change. This lets the application describe what it wants to happen and hand the actual work to a wallet, which already knows how to do it safely.
Two parties who want to exchange private data normally have to agree on a key first, and looking after that key is where most systems go wrong. This lets an application ask a wallet to encrypt something for one specific recipient without the application ever handling a key itself.
Proving a message really came from you usually means keeping a signing key inside the application, which is both risky and easy to get wrong. This lets an application ask the wallet to sign on the user's behalf, and can produce a signature only the intended recipient is able to check.
Spending money you already hold means pointing at the specific coins you own and proving you are allowed to spend them. This gives an application a way to name those coins when asking a wallet to build a transaction, along with everything the wallet needs to check the claim before it signs.
A wallet running on your own machine and a website open in your browser have no natural way to talk to each other. This defines one over ordinary web requests, so any application can reach any wallet on the same device without either side having been built for the other.
Two web pages from different sites cannot safely reach into each other, which becomes a problem when one of them is your wallet. This uses the browser's own page-to-page messaging so an application can ask a wallet to act while each side stays sealed off from the other.
An application keeping things on chain has to track which outputs are its own, and leaving that bookkeeping to the application invites mistakes. This lets the wallet group outputs by application and hand them back on request.
A certificate is only useful if an application can ask for one and later prove you hold it. This defines the requests an application makes to a wallet to obtain a certificate and to reveal selected fields from it.
Every application wanting to use a wallet otherwise integrates with each one separately, making every wallet vendor a dependency. This proposes a single interface covering transactions, keys, encryption and identity, so either side can be replaced without rewriting the other.
A wallet holding hundreds of transactions with no way to tell them apart is hard to make sense of. This lets an application attach its own labels when a transaction is made, and later list transactions by those labels.
Anything an application can add to a wallet it should eventually be able to remove, or the wallet fills with things nobody needs. This adds the ability to drop outputs from a group and delete certificates that are no longer wanted.
An application asking the user for one permission at a time, over and over, teaches them to click yes without reading. This lets an application declare everything it needs up front, in one place, so the user makes one informed decision.
Different proof systems will be used to back up key-linkage claims, and hard-coding one of them makes the format a dead end. This defines a container that names which proof type it carries, so new ones can be added later.
If applications are free to use any protocol name they like, a future standard cannot claim one without breaking somebody. This reserves a range of names so later permission schemes have room to exist.
Granting an application access to a group of assets is currently all or nothing. This reserves naming space for future schemes that can be more precise about what an application may touch.
Every wallet historically had its own way of being talked to, so an application had to pick one and be locked to it. This defines a single interface every wallet can implement, so applications work with whichever wallet the user already has.
Labels attached to wallet activity are used both for organising and for deciding what an application may see, which means new labelling ideas cannot be added safely. This reserves label space so they can.
An application that only wants to know how much is in a group has to fetch every item and add them up. This lets it ask for the total directly, using a form older wallets still handle correctly.
If you hand someone a signed Bitcoin payment transaction but ask your wallet not to broadcast it yet, the wallet still locks away the coins it used, sometimes far more value than the payment itself, and there was no reliable way to get that value back if the other party never sends the transaction. An app-side timer does not help because it cannot undo a signature that already left the wallet. This leaves developers stuck choosing between reserving too much money indefinitely or giving up on delayed-send payment flows.
When an app asks a wallet to approve something, the wallet often shows a cryptic code, a raw protocol string, an unfamiliar basket name, or a block of certificate bytes. Users cannot tell what is actually being requested, and there has been no shared, trustworthy place to look up a human-readable name or description for these identifiers. This makes it possible to publish and consult optional, attributed descriptions, without letting those descriptions ever decide whether the underlying operation is allowed.
Right now if you run two wallet-enabled apps on the same computer, or try to use your phone's wallet from a desktop browser, things break: one app grabs the only expected port, or whichever wallet loads last wins and silently takes over. There was no agreed way for an app to see what wallets are available, let the user pick one, and keep that choice stable without accidentally scrambling which wallet handles which connection.
Losing a password usually means losing an account forever, but trusting one login service with everything makes that service a single point of failure it can abuse or lose. People need a way to open the same wallet account on a new device or recover it after losing a password, a phone, or a service provider, without any single party being able to lock them out or hold their funds hostage.
Apps that want to know who a user is usually force them into yet another signup, hand their identity to a central provider, or trust whatever name a person types into a form. There was no good way for a person to prove a single cryptographic identity across many apps, selectively reveal only the attributes they choose, and let each app apply the trust decisions the user has actually made. This makes it possible for an app to recognize a person by their key, pull up attributes they published, and ask them directly for more proof, all without building an account system or an identity bureau.
An app that wants to greet a returning user by the name of their wallet account has no way to ask the wallet what that account is currently called, so it either guesses, hardcodes a vendor name, or stays silent. This leaves users confused when the same account shows up under different branding across apps or over time. A small, optional way to carry that label alongside the version string the wallet already returns solves this without adding new wallet methods."
Wallets that handle plain bitcoin payments have no built-in idea of a custom token such as a loyalty point or a share. Without shared rules for finding, verifying, spending and tracking such tokens, every app would reinvent issuance, transfers and swaps from scratch, and wallets could not interoperate on the same asset. This lets a wallet manage fungible tokens with the same safety, automatic input selection, and consent prompts it already gives ordinary payments.
Some apps want a wallet to track and move a named digital item, like a ticket or a badge, without the wallet pretending to guarantee how many exist, who issued them, or whether one is the "real" one. Before this, a wallet either had to apply full token rules it didn't need, or drop structure entirely and lose any way to recognize the item at all. This gives apps a lightweight way to say "sign this thing and identify it" without any false promises about scarcity or ownership history.
An application asking a wallet for permission gets an error if the person does not answer straight away, which is unfair to anyone who stepped away. This says the request waits for them rather than timing out.
Sending someone a transaction is not enough for them to trust it: they also need the earlier transactions and the proofs showing the money is real. This defines a single package carrying all of it, so software from two different vendors can exchange a payment the recipient can actually check.
Confirming a payment traditionally means running a full copy of the blockchain, which is far too heavy for a phone or a web page. This describes how a recipient can satisfy themselves a payment is genuine using only block headers and a short proof.
Raw transaction bytes are compact but almost impossible to search or filter. This describes a structured representation of the same data that can be stored in an ordinary document database and queried like any other record.
Different proof formats each solved part of the problem, leaving processors and clients converting between them. This defines one format that is cheap for a transaction processor to produce and convenient for a client to check.
Handling very high transaction volume means doing as much as possible at the same time, while some checks must still happen in order. This describes how that work is divided across the network so throughput rises without correctness slipping.
A bundle carrying several transactions leaves the recipient guessing which one is the subject and which are supporting evidence. This constrains the bundle to a single subject transaction so there is nothing to guess.
Reusing one key for everything links all your activity together, and agreeing a fresh key for every interaction is impractical. This lets two parties generate an unlimited supply of keys for each other, where the sender can produce a key only the recipient can later unlock.
Generating unlimited keys is only safe if software can tell what each one is for and how much the user has agreed to. This defines the naming scheme that separates keys by purpose and sets how much permission each use requires.
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.
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.
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.
Two parties can derive private keys between themselves, but neither can prove to an outsider that they did it correctly. This adds a way for a third party to check the derivation without being given the ability to spend.
An earlier way of revealing how two parties' keys are linked asks the recipient to take the claim on faith. This sets out plainly what a verifier cannot check for themselves, as the case for something better.
Revealing a shared secret is only useful if the recipient can confirm it is the right one, and handing over the key that proves it defeats the point. This lets the prover demonstrate correctness without revealing anything more.
Sending an ordinary Bitcoin payment leaves the recipient unsure whether it is real without checking the whole chain. This defines a straightforward payment between two parties that the recipient can verify independently, and that any compliant wallet can take part in.
Charging a small amount for a single web request is impractical with cards, where the fee can exceed the payment. This describes paying per request with Bitcoin, so an interface can be metered by use rather than sold by subscription.
Charging a small amount for a single web request has no standard shape, so every service invents one and no client can be written once. This defines how a server states its price and how a client pays it in the same exchange.
The same script can be written as raw bytes, as hexadecimal, or in a readable assembly form, and tools disagree about the details. This documents all three so software can convert between them without surprises.
Bitcoin's scripting instructions are numbers, which machines read easily and people do not. This defines a readable way to write them down, so a developer can inspect a script and reason about what it does.
Most Bitcoin payments lock coins so that only the holder of one particular key can spend them. This documents exactly how that lock is written and later unlocked, which is the pattern behind an ordinary Bitcoin address.
Sometimes you want to lock coins so that anyone who knows a particular secret can claim them, without publishing the secret itself. This describes a way to do that using a value which already appears inside every signature.
Attaching data to an unspendable output means the coins attached to it are gone for good, which some argue is the wrong way to think about Bitcoin. This offers a way to carry data on an output that can still be spent afterwards.
Attaching data to an output normally makes it unspendable, so the data and the ownership cannot travel together. This describes a script that carries arbitrary data and leaves the output spendable, letting a token hold its own details.
Ethereum has a well-known token standard called ERC-20, and people arriving from that world assume there must be a BRC-20 to match. There is not, and this document exists to say so plainly and stop the confusion spreading further.
Building tokens on Bitcoin tempts people to copy account-based designs from other chains, which fits badly. This argues that an unspent output is already the natural unit of ownership and should be treated as the token itself.
Swapping a token for payment with a stranger requires one of you to go first, which neither party wants to do. This describes an exchange between two parties where neither has to trust the other to complete their side.
Selling something once on Bitcoin is easy, but selling it over and over from the same listing without the seller babysitting every sale is hard. Normally you would need the seller online to approve each purchase and each payout to collaborators, which breaks down once there are multiple recipients sharing revenue or the seller wants to walk away. This makes it possible to run a listing that buyers can purchase repeatedly, that pays out to a fixed set of recipients automatically, and that anyone can wind down or settle after a deadline even if the seller disappears.
Referring to one particular coin is easy; referring to it so another program can act on it is not, because its amount and its lock live elsewhere. This defines the smallest complete way to name an output together with what is needed to use it.
An output on its own says nothing about which application it belongs to or what it is for. This adds a way to tag one with the group it belongs to, and with instructions whose meaning that group defines.
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.
A file containing everything about your wallet is not something to leave lying around unprotected. This defines the encrypted wrapper around such an export, so a backup can be stored safely and restored with a password.
Moving a wallet between storage providers, or keeping two of them in step, otherwise needs custom code for every pairing. This defines a resumable synchronisation protocol so independent providers can exchange wallet state directly.
Finding your own application's data on the blockchain means either scanning everything or trusting somebody else's index. This defines how to submit transactions to a service that tracks only the subset you care about, and how it reports back what it accepted.
An index that watches part of the blockchain is only useful if you can find one, and relying on a single index is a single point of failure. This describes how such services announce what they track, so clients can discover several and survive one going offline.
Submitting data to an index is half the job; getting it back out again is the other half. This defines how a client asks such a service what it is holding and receives an answer it can verify for itself.
Knowing which services track which data is not the same as knowing which ones will answer questions about it. This extends the discovery mechanism so a service can advertise the specific queries it is willing to serve.
Referring to a file by a web address breaks the moment that address stops working. This lets a file be named by its contents instead, with any number of hosts advertising that they hold a copy.
Applications constantly need somewhere to keep small pieces of state, and doing that on chain usually means inventing a scheme per project. This standardises a simple named-value store: a public one others can discover, and a private one held in the wallet.
An index that only keeps current data cannot answer questions about how something got to be the way it is. This extends the index to retain the spent history as well, so past states remain queryable.
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.
Independent implementations picking their own names for the same index or query will not interoperate. This proposes naming conventions so a name means the same thing wherever it appears.
Indexes need to find each other and stay in step, and doing that ad hoc leaves gaps. This defines how they announce what they track and what they answer, and how they synchronise once found.
Index advertisements were assumed to contain a plain web address, which rules out reaching a service any other way. This allows other kinds of address so a service is not tied to one way of being contacted.
Large files are usually treated as one indivisible blob: you can't name it until the whole thing has finished uploading, a single failed byte range means retrying the entire download, and there's no way to prove a partial chunk actually belongs to the file it claims to be part of. This makes streaming uploads, resumable downloads, and safe partial reads of big files awkward or impossible with simple whole-file hashing.
Different Bitcoin-based apps use the word "overlay" for two very different setups: one where every server is supposed to agree on the exact same data, and one where servers legitimately hold different, non-matching collections. When people conflate these, it becomes unclear whether a mismatch between two servers is a bug to fix or just two valid, different answers.
Pulling a large, constantly changing list of overlay results used to force a choice between getting a stable view that quickly goes stale, or watching live updates and losing track of what you already saw if your connection dropped. There was no safe way to read the current state of something and then keep watching it change without missing an update that happened during a disconnect. This gives a reader a consistent starting snapshot plus a way to pick back up exactly where it left off, even after going offline.
Apps that talk to overlay services had no standard way to ask a host "what can you actually do, and on what terms" before sending data. Without that, a client either guesses a URL and hopes, or every integration invents its own private handshake for things like private lookups or proposing a transaction that isn't finished yet. This makes it possible for a client to discover exactly which services and payment or auth rules a host supports, and to safely work with draft transactions that are not yet final.
Some data on the blockchain world needs to stay private until someone pays for it, like a song's decryption key, but the usual way overlay servers share and index information assumes everything is public and copied everywhere. Without a clear contract, a seller has no safe way to accept payment, hold a secret key in reserve, and reliably hand it over, especially if a network hiccup happens between "paid" and "delivered". This makes it possible to run a paid catalogue where buyers always eventually get what they paid for, even after crashes or lost responses.
Imagine paying for a digital item, like a song, over a payment network: the network can confirm the payment landed, but has no built-in way to also hand over the thing you paid for only once that payment is genuinely and exclusively yours. Without a clear process, a seller could claim a payment is accepted but never deliver, deliver to the wrong person, or leave a buyer stranded if something fails partway through. This gives buyers and sellers a dependable, replayable sequence for locking in terms, submitting payment, and releasing the purchased secret only to its rightful recipient.
When a wallet or app stops endorsing an advertisement, or a root decides it no longer wants to show one, there has been no shared, attributable way to ask a server to stop serving that one specific record without pretending to be a global ban or an on-chain spend. Without it, roots either ignore stale or withdrawn ads forever or quietly drop them with no record of who asked or why, and restoring one later is guesswork.
Two parties talking over a network each want to know who they are dealing with, and neither wants to hand over more about themselves than necessary. This defines a mutual introduction where both sides prove who they are and choose what to reveal.
Sending someone a message directly needs both of you online at the same moment, which often you are not. This defines a message box on a server that holds messages until the recipient comes to collect them.
A message relay is only dependable if there is more than one of them, and clients need some way to find them. This describes how relay servers announce themselves, so no single one has to stay up forever.
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.
Deciding whether to trust a certificate means knowing which keys an organisation actually vouches with. This publishes that at the organisation's own domain, so it can be looked up the same way any other website detail is.
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.
An encrypted message is only portable if the recipient can work out how to decrypt it from the message itself. This defines a self-describing container so an encrypted message can be stored or forwarded and still be opened later.
Sending every transaction separately to every interested party wastes enormous bandwidth when they all want the same data. This proposes delivering it once to everyone who has asked, using the network's own one-to-many delivery.
Two parties talking directly each need to know the other is who they claim, and neither wants to route through a server to find out. This defines a handshake using challenges and signatures, with credentials exchanged along the way.
A peer-to-peer handshake still has to travel over ordinary web requests to work with existing infrastructure. This says exactly which endpoints and headers carry it.
Anyone can sign a digital certificate claiming something about you, like "this email belongs to this person," but a valid signature by itself does not tell you whether the signer actually checked anything, how they handle mistakes, or what happens if the claim turns out to be wrong. Without shared ground rules, two issuers using the same certificate format could have wildly different (or nonexistent) verification practices, leaving anyone relying on the certificate with no way to judge it.
An app wants to show that a user controls a particular email address or X/Discord account, tied to their wallet identity key, without building its own account verification system from scratch. Different apps and wallets could easily disagree about what that badge actually proves, or quietly start treating a historical "we checked this once" observation as proof of current account control or legal identity. This spec pins down exactly what three widely used social certificate types mean, so wallets and apps interpret them the same way.
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.
A developer holding an existing Bitcoin certificate has no way to show it to tools built for the W3C verifiable credential world without either faking a new signature or exposing more than the subject agreed to. This gives a safe, read-only way to describe that certificate in credential terms while keeping the original signature and encrypted fields exactly as issued.
Imagine selling a locked box online, but the "lock" is really just a sign that says "please don't look inside" while the contents sit in plain view for anyone who peeks at the underlying data. That's how paid content has actually been built on this chain: the restriction is a polite fiction, not a real barrier. This makes it possible to actually encrypt content once, publish it openly, and hand out the key only to people who paid or otherwise qualify, so access is real, survives the seller going offline, and gets more reliable the more people buy it.
A tool that deploys an application needs to know its pieces, and every project describing that differently means the tooling only works on projects it was written for. This fixes the shape of that description file.
Right now, if you want to sell access to a song, a page, a video, or a dataset on-chain, you have to invent your own answer to a dozen hard questions: how do I prove I'm allowed to sell this, what exactly did the buyer pay for, how do they get the decryption key, and what happens if someone builds a new song out of three licensed samples. Every app that encrypts content and sells keys for Bitcoin SV payments ends up solving this differently and incompatibly, so a buyer's license from one app means nothing anywhere else.
Apps that show Bitcoin-derived data (like a music catalogue or a task list) often pull information from more than one source: an overlay network, a wallet's own storage, or a direct message from another peer. Without a shared discipline, an app ends up treating whichever source answered first as the single truth, so later corrections, competing hosts, or spends get silently lost or wrongly overwrite each other. This leaves developers unsure how to combine "someone claims this output exists" with "this output is actually verified on-chain" without conflating the two.
Buying access to licensed digital content on Bitcoin SV normally means every app invents its own payment flow and licensing format, so content bought through one app's purchase method cannot be unlocked or re-issued through another. This makes it hard to build a marketplace where sellers set a price once and many different apps can sell and deliver the same protected content correctly.
Recording a long series of events on chain by chaining one transaction to the next gets expensive and slow. This describes carrying the same history as a chain of hashes inside a single transaction that keeps being updated instead.
A miner interface gained wide adoption and an equal amount of criticism, with some of its uses pulling against how the network is meant to work. This sets out which of those uses are legitimate and which are not.
Some ways of tracking blockchain state require every participant to see every transaction, which stops working as volume grows. This argues that indexes watching only the slice they care about are both safer and able to scale.
The standard way for a device to say which network broadcasts it wants was designed for a handful of groups, not for blockchain traffic at scale. This examines where it falls short and what would have to change.
Talk about a decentralised web rarely says concretely what the pieces are or how they fit. This sketches one: wallets, indexes, browsers and payments, and where each belongs.
Discussions of network design tend to jump straight to mechanisms without saying who is doing what. This lays out a three-layer picture, with processors at the core, indexes in the middle and ordinary users at the edge, as a shared vocabulary for the rest.
Once the layers of the network are named, the next question is which pieces of a transaction belong to which layer. This works through where outputs, indexes and scripts sit and how they relate.
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.
Shared systems like a village granary or a blockchain network need someone to actually do the maintenance work, but whoever does that work can start to confuse running the thing with owning what it is for. Without a way to separate the rules of a system from whoever currently claims to enforce them, cooperation ends up depending on trusting one person or group forever, and the whole system becomes fragile the moment that keeper disagrees, retires, or goes bad.
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.
Free blockchain explorer lookups (finding a transaction or checking an address's history by typing its ID) feel like a permanent utility, but someone pays in storage, bandwidth and recovery costs for every address and transaction they index forever. Apps and wallets that rely entirely on a provider's free lookups have no warning if that provider decides to narrow what it indexes for free, and no shared playbook for what "narrower" would even mean. This proposal gives providers a common, predictable schedule for shrinking free coverage, so apps can plan ahead instead of being surprised.
Search standards by number, title, author or topic