Beered by 7 people
79 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.
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.
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.
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.
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.
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.
Search standards by number, title, author or topic