161 standards in 12 topics. Press ⌘K to search.
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.
Some wallets live inside the browser itself rather than running as a separate program. This gives applications one way to reach those, so a developer writes the same code regardless of where the user's wallet actually runs.
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.
An application that has received a payment on someone's behalf has no standard way to hand it over. This defines how a transaction and its proofs are submitted into a wallet, so the wallet recognises the funds as the user's own.
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.
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.
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.
Asking a wallet for activity within a date range means fetching everything and filtering it yourself. This adds a way to express the range in the request, without changing what comes back.
Wallets each decide in their own way what an application is allowed to do and how long consent lasts, so the same application behaves differently depending on the wallet. This specifies the whole lifecycle of a permission, without ambiguity.
Reserving a naming space for future permission schemes is only half the job: somebody still has to decide who gets which name. This sets out how a scheme is registered and who maintains the list.
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.
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.
Some wallets live inside the browser itself rather than running as a separate program. This gives applications one way to reach those, so a developer writes the same code regardless of where the user's wallet actually runs.
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.
An application that has received a payment on someone's behalf has no standard way to hand it over. This defines how a transaction and its proofs are submitted into a wallet, so the wallet recognises the funds as the user's own.
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.
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.
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.
Asking a wallet for activity within a date range means fetching everything and filtering it yourself. This adds a way to express the range in the request, without changing what comes back.
Wallets each decide in their own way what an application is allowed to do and how long consent lasts, so the same application behaves differently depending on the wallet. This specifies the whole lifecycle of a permission, without ambiguity.
Reserving a naming space for future permission schemes is only half the job: somebody still has to decide who gets which name. This sets out how a scheme is registered and who maintains the list.
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.
Several documents refer to the same existing merkle proof format, and calling it different things invites confusion. This gives that format a number in this series so other proposals can point at it without ambiguity.
Merkle proofs identify the block they belong to by its hash, which means anyone checking one has to keep every block hash to look it up. This argues for using the block's height instead, roughly halving what a lightweight client needs to store.
Bitcoin transactions travel as raw bytes, and anyone writing software that reads or builds them needs to know exactly what those bytes mean. This documents that layout, field by field.
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.
A transaction on its own does not carry enough to check that its signatures are valid: the amounts and locks being spent live in earlier transactions. This adds those missing pieces, so a service can validate what it is given without looking anything up.
A lightweight client asking a service for proof that a transaction is in a block needs that proof in a form it can read over an ordinary web request. This gives it a plain readable shape rather than raw bytes.
Sending proofs for several transactions separately repeats the same hashes over and over. This defines a compact form that carries proofs for many transactions at once with the shared parts included only once.
A recipient cannot check a payment without the transactions it came from and the proofs tying them to the chain, and fetching those separately is slow and reveals what you are looking at. This packages everything needed to verify a payment into one compact bundle.
Earlier descriptions of how a light client checks a payment were spread across documents and leaned on each other. This states the process on its own terms so it can be read and implemented without following a trail of references.
Storing a proof in a database means keeping it small and quick to read back. This defines a compact binary shape for a single transaction's proof, aimed at storage rather than transmission.
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.
Two parties who each hold part of a transaction history need to reconcile without sending each other everything. This describes a back-and-forth that works out exactly what is missing and fills only the gaps.
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.
Two parties who have already exchanged proofs for a transaction resend all of it every time it comes up again. This lets a bundle name a transaction the other side already has instead of repeating it.
A proof spanning a whole block is larger than needed when the transactions of interest sit close together. This encodes the path within a subtree instead, which is smaller for that common case.
Sending transactions across a network at high volume needs an agreed wire format, and the old one carries too little information to route or reorder anything. This adds the fields needed to identify a flow and track position within it.
One-to-many network delivery does not tell the sender when a piece went missing. This lets a receiver report exactly what it did not get, and the sender resend only that.
A receiver has to know which network group carries the slice of traffic it wants before it can subscribe. This has senders announce that mapping periodically, so a listener can join without being told out of band.
The same frame is useful for a transaction that already carries the details needed to validate it on its own. This defines that variant while leaving the header untouched, so existing readers still work.
Splitting traffic across many network groups only works if everyone agrees which group is which. This assigns the address ranges, separating the groups carrying data from those carrying control messages.
A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.
Clients need to know when a new block arrives, and polling for it wastes time and bandwidth. This pushes the block's summary to everyone listening as soon as it exists.
Knowing a subtree exists is not the same as having the transaction hashes in it. This defines a frame carrying those contents to everyone subscribed, so nobody has to request them.
The first transaction in a block is a special case, and it does not travel with the ordinary transaction stream. This says how it is carried and who receives it.
The first transaction in a chain has to arrive before any that depend on it, or the rest cannot be checked. This gives it its own frame so it can be treated as the prerequisite it is.
A client that only tracks block headers should not have to receive a whole block announcement to get one. This carries the eighty-byte header on its own.
Nothing tells a participant which slices of the traffic anyone else is actually carrying. This has each one announce what it holds, so the gaps become visible.
Sending many tiny transactions as separate packets spends more on overhead than on content. This packs the ones heading the same way into a single frame.
The list of transaction hashes making up a subtree also needs to travel over an ordinary byte stream, not just one-to-many delivery. This defines that form and how a receiver takes it in.
A block pushed over a stream connection needs an agreed layout for its header, its parts and its first transaction. This defines it.
The address space carrying transactions was not designed to carry anything else, so a second kind of object has nowhere to go. This divides it into planes, giving each kind of object its own room.
Once a second kind of object has its own space, it needs a frame to travel in and a route back for submissions. This defines those wire forms.
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.
Several documents refer to the same existing merkle proof format, and calling it different things invites confusion. This gives that format a number in this series so other proposals can point at it without ambiguity.
Merkle proofs identify the block they belong to by its hash, which means anyone checking one has to keep every block hash to look it up. This argues for using the block's height instead, roughly halving what a lightweight client needs to store.
Bitcoin transactions travel as raw bytes, and anyone writing software that reads or builds them needs to know exactly what those bytes mean. This documents that layout, field by field.
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.
A transaction on its own does not carry enough to check that its signatures are valid: the amounts and locks being spent live in earlier transactions. This adds those missing pieces, so a service can validate what it is given without looking anything up.
A lightweight client asking a service for proof that a transaction is in a block needs that proof in a form it can read over an ordinary web request. This gives it a plain readable shape rather than raw bytes.
Sending proofs for several transactions separately repeats the same hashes over and over. This defines a compact form that carries proofs for many transactions at once with the shared parts included only once.
A recipient cannot check a payment without the transactions it came from and the proofs tying them to the chain, and fetching those separately is slow and reveals what you are looking at. This packages everything needed to verify a payment into one compact bundle.
Earlier descriptions of how a light client checks a payment were spread across documents and leaned on each other. This states the process on its own terms so it can be read and implemented without following a trail of references.
Storing a proof in a database means keeping it small and quick to read back. This defines a compact binary shape for a single transaction's proof, aimed at storage rather than transmission.
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.
Two parties who each hold part of a transaction history need to reconcile without sending each other everything. This describes a back-and-forth that works out exactly what is missing and fills only the gaps.
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.
Two parties who have already exchanged proofs for a transaction resend all of it every time it comes up again. This lets a bundle name a transaction the other side already has instead of repeating it.
A proof spanning a whole block is larger than needed when the transactions of interest sit close together. This encodes the path within a subtree instead, which is smaller for that common case.
Sending transactions across a network at high volume needs an agreed wire format, and the old one carries too little information to route or reorder anything. This adds the fields needed to identify a flow and track position within it.
One-to-many network delivery does not tell the sender when a piece went missing. This lets a receiver report exactly what it did not get, and the sender resend only that.
A receiver has to know which network group carries the slice of traffic it wants before it can subscribe. This has senders announce that mapping periodically, so a listener can join without being told out of band.
The same frame is useful for a transaction that already carries the details needed to validate it on its own. This defines that variant while leaving the header untouched, so existing readers still work.
Splitting traffic across many network groups only works if everyone agrees which group is which. This assigns the address ranges, separating the groups carrying data from those carrying control messages.
A transaction can be larger than the biggest packet the network will carry. This splits it into numbered pieces the receiver can reassemble, and says how to tell when one is missing.
Clients need to know when a new block arrives, and polling for it wastes time and bandwidth. This pushes the block's summary to everyone listening as soon as it exists.
Knowing a subtree exists is not the same as having the transaction hashes in it. This defines a frame carrying those contents to everyone subscribed, so nobody has to request them.
The first transaction in a block is a special case, and it does not travel with the ordinary transaction stream. This says how it is carried and who receives it.
The first transaction in a chain has to arrive before any that depend on it, or the rest cannot be checked. This gives it its own frame so it can be treated as the prerequisite it is.
A client that only tracks block headers should not have to receive a whole block announcement to get one. This carries the eighty-byte header on its own.
Nothing tells a participant which slices of the traffic anyone else is actually carrying. This has each one announce what it holds, so the gaps become visible.
Sending many tiny transactions as separate packets spends more on overhead than on content. This packs the ones heading the same way into a single frame.
The list of transaction hashes making up a subtree also needs to travel over an ordinary byte stream, not just one-to-many delivery. This defines that form and how a receiver takes it in.
A block pushed over a stream connection needs an agreed layout for its header, its parts and its first transaction. This defines it.
The address space carrying transactions was not designed to carry anything else, so a second kind of object has nowhere to go. This divides it into planes, giving each kind of object its own room.
Once a second kind of object has its own space, it needs a frame to travel in and a route back for submissions. This defines those wire forms.
Keeping a separate backup for every key is impractical, so wallets generate many keys from a single seed. This documents the long-established scheme for doing that, along with the limitations worth understanding before adopting it.
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.
A master key is a long string nobody can write down reliably, and losing it loses everything. This adapts the familiar twelve-to-twenty-four word phrase so a single key can be recorded as words and restored from them.
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.
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.
A single key is a single point of failure: lose it and everything is gone, and copying it multiplies the chance of theft. This splits it into pieces where a chosen number of them rebuild it and any fewer reveal nothing.
Keeping a separate backup for every key is impractical, so wallets generate many keys from a single seed. This documents the long-established scheme for doing that, along with the limitations worth understanding before adopting it.
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.
A master key is a long string nobody can write down reliably, and losing it loses everything. This adapts the familiar twelve-to-twenty-four word phrase so a single key can be recorded as words and restored from them.
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.
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.
A single key is a single point of failure: lose it and everything is gone, and copying it multiplies the chance of theft. This splits it into pieces where a chosen number of them rebuild it and any fewer reveal nothing.
Search standards by number, title, author or topic