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.
When an app asks a wallet to build a transaction, the wallet hands back a temporary token needed to finish or cancel that transaction later. If the app crashes, loses memory, or the signing process gets interrupted before that token is used, there was previously no standard way to get it back, leaving the transaction stuck half-finished with no way to complete or cancel it.
If you want a backup copy of a wallet's secret key material held outside the wallet, there has never been a common way for different storage providers to speak the same language. Without it, a wallet app would have to hand-roll a custom recovery API for every provider, and users would end up trusting a single company with their entire recovery path. This makes it possible to spread recovery pieces across independent services that all understand the same request and response shapes.
A wallet can hand out a fresh receive address to anyone, but if that sender is a custodial exchange, swap service, or anyone who just sends money without telling the wallet, there is no way for the wallet to notice the payment arrived. Watching every possible address the wallet could ever generate is slow, leaks privacy, and can still miss late payments. This lets a wallet reliably notice payments to addresses it gave out, without the sender's cooperation and without scanning forever.
Wallet apps often need to find one specific coin they are holding again later, for example after a restart, or to spend exactly that one and not another, but the usual way to look through a wallet's holdings means scanning everything and hoping the details still match. There was no agreed, simple way to give a single held item a durable nickname that a lookup could search for directly.
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.
A wallet or AI-agent tool server ends up with a long list of callable methods, and once a new method is registered it is simply live, with no signed record of exactly what was turned on and no way for anyone reviewing the build afterward to tell whether the exposed surface quietly grew. This makes it hard to trust that a wallet used by autonomous software, where a rogue or newly-added method could move funds or sign things, has actually been reviewed and locked down rather than just shipped.
An AI agent or automated script that holds a wallet's keys can be tricked or malfunction into sending money to the wrong place, and the usual safeguard, a human approving every transaction, defeats the whole point of letting software act on its own. Before this, a wallet could only grant a monthly spending ceiling to an app, which limits how much but says nothing about to whom, how fast, or under what conditions, so a single bad request could still drain the budget to an attacker.
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.
When an AI agent spends money on your behalf, it usually does so with a password-like credential that can drain whatever account sits behind it, and if something goes wrong you have to notice, log in, and revoke that credential while the agent keeps spending in the meantime. There was no way to hand an autonomous agent a fixed amount of money it could use on its own, anywhere, while guaranteeing the owner could never lose more than that amount and could always take the rest back in a single action.
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."
Smart contracts sometimes need to check a signature over arbitrary data, like a price or a game move, but Bitcoin's scripting language can only verify one kind of signature cheaply, and that kind does not work for arbitrary data. Until now, apps that needed this had to generate and hold the special signing key themselves, which meant the user had no way to see, control, or recover it through their wallet. This lets the wallet hold and use that key instead, so the app never has to.
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.
Someone running a wallet app for several separate purposes, a personal account, a shop, a brand, normally ends up juggling a different seed phrase or backup for each one, which is tedious to secure and easy to lose track of. This describes a way for one single backed-up secret to safely produce as many separate, unlinkable accounts as needed, each behaving like its own independent wallet, and for all of them to be found again from that one secret alone.
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.
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".
Wallets that show balances for chains other than BSV, like Litecoin or Dogecoin, usually have to trust a custodian holding wrapped tokens or an indexer reporting balances and confirmations, putting a third party between the user and their money. This makes it possible for a wallet to hold and spend coins on another chain directly, verifying everything itself from raw transaction bytes and its own copy of that chain's block headers.
A wallet can hold many different kinds of value, like Bitcoin, other coins, collectable items, and tokens, but there has been no shared rule for keeping them separate when an app asks to see or spend them. Without that, an app given permission to spend a small amount of Bitcoin could end up able to grab an item or token it was never meant to touch, and apps have no clean way to ask a wallet what kinds of value it even holds before trying.
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.
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.
Some multi-party card and shuffle games need each player to secretly scramble and later unscramble shared data using a private number only they know, in a way that works no matter what order players apply or remove their scrambling. Normal wallet features can derive keys or encrypt data, but there was no way to ask a wallet to multiply an arbitrary point someone else gave you by your own secret number without ever learning that number or exposing it to the app.
A wallet backup can be restored on more than one phone or laptop, but if two devices both treat the same account as theirs to spend from, they can each build a payment from coins the other has already spent, and the blockchain will only accept one of them. Before this, the only fix was asking a server before every payment, which is slow and breaks when offline. This makes it possible to keep a vault's accounts spread across several trusted devices safely, without that per-payment check.
Signing in to a self-custodial wallet on a new phone is normally stuck between two bad options: either some server holds enough of your secret to log you in (so it can also be hacked or coerced into logging someone else in), or you have to manually copy a long recovery phrase between devices every time. This makes it hard to offer a simple "sign in with your email" experience without quietly giving a company the power to open your wallet.
A web app can only find the Bitcoin wallet running on a user's own computer by poking a handful of local addresses, and newer browsers treat that poke as suspicious and interrupt the user with a security dialog that never mentions the word "wallet". If the user clicks the wrong button, nothing explains what just happened, and the browser locks out that discovery permanently for that site. This leaves developers needing a way to prepare the user before that dialog appears, so a refusal is recoverable instead of final.
When a wallet request fails, today's wallets each write their own error sentence and hand it straight to the app, which has no choice but to show it to the user unchanged. That sentence rarely says whose fault the failure was, whether trying again is safe, or whether the payment might actually have gone through anyway. The result is users double-spending after a timeout, support tickets full of mismatched wording, and apps that cannot translate or shorten a message they did not write.
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.
When an app asks a wallet to build a transaction, the wallet hands back a temporary token needed to finish or cancel that transaction later. If the app crashes, loses memory, or the signing process gets interrupted before that token is used, there was previously no standard way to get it back, leaving the transaction stuck half-finished with no way to complete or cancel it.
If you want a backup copy of a wallet's secret key material held outside the wallet, there has never been a common way for different storage providers to speak the same language. Without it, a wallet app would have to hand-roll a custom recovery API for every provider, and users would end up trusting a single company with their entire recovery path. This makes it possible to spread recovery pieces across independent services that all understand the same request and response shapes.
A wallet can hand out a fresh receive address to anyone, but if that sender is a custodial exchange, swap service, or anyone who just sends money without telling the wallet, there is no way for the wallet to notice the payment arrived. Watching every possible address the wallet could ever generate is slow, leaks privacy, and can still miss late payments. This lets a wallet reliably notice payments to addresses it gave out, without the sender's cooperation and without scanning forever.
Wallet apps often need to find one specific coin they are holding again later, for example after a restart, or to spend exactly that one and not another, but the usual way to look through a wallet's holdings means scanning everything and hoping the details still match. There was no agreed, simple way to give a single held item a durable nickname that a lookup could search for directly.
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.
A wallet or AI-agent tool server ends up with a long list of callable methods, and once a new method is registered it is simply live, with no signed record of exactly what was turned on and no way for anyone reviewing the build afterward to tell whether the exposed surface quietly grew. This makes it hard to trust that a wallet used by autonomous software, where a rogue or newly-added method could move funds or sign things, has actually been reviewed and locked down rather than just shipped.
An AI agent or automated script that holds a wallet's keys can be tricked or malfunction into sending money to the wrong place, and the usual safeguard, a human approving every transaction, defeats the whole point of letting software act on its own. Before this, a wallet could only grant a monthly spending ceiling to an app, which limits how much but says nothing about to whom, how fast, or under what conditions, so a single bad request could still drain the budget to an attacker.
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.
When an AI agent spends money on your behalf, it usually does so with a password-like credential that can drain whatever account sits behind it, and if something goes wrong you have to notice, log in, and revoke that credential while the agent keeps spending in the meantime. There was no way to hand an autonomous agent a fixed amount of money it could use on its own, anywhere, while guaranteeing the owner could never lose more than that amount and could always take the rest back in a single action.
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."
Smart contracts sometimes need to check a signature over arbitrary data, like a price or a game move, but Bitcoin's scripting language can only verify one kind of signature cheaply, and that kind does not work for arbitrary data. Until now, apps that needed this had to generate and hold the special signing key themselves, which meant the user had no way to see, control, or recover it through their wallet. This lets the wallet hold and use that key instead, so the app never has to.
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.
Someone running a wallet app for several separate purposes, a personal account, a shop, a brand, normally ends up juggling a different seed phrase or backup for each one, which is tedious to secure and easy to lose track of. This describes a way for one single backed-up secret to safely produce as many separate, unlinkable accounts as needed, each behaving like its own independent wallet, and for all of them to be found again from that one secret alone.
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.
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".
Wallets that show balances for chains other than BSV, like Litecoin or Dogecoin, usually have to trust a custodian holding wrapped tokens or an indexer reporting balances and confirmations, putting a third party between the user and their money. This makes it possible for a wallet to hold and spend coins on another chain directly, verifying everything itself from raw transaction bytes and its own copy of that chain's block headers.
A wallet can hold many different kinds of value, like Bitcoin, other coins, collectable items, and tokens, but there has been no shared rule for keeping them separate when an app asks to see or spend them. Without that, an app given permission to spend a small amount of Bitcoin could end up able to grab an item or token it was never meant to touch, and apps have no clean way to ask a wallet what kinds of value it even holds before trying.
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.
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.
Some multi-party card and shuffle games need each player to secretly scramble and later unscramble shared data using a private number only they know, in a way that works no matter what order players apply or remove their scrambling. Normal wallet features can derive keys or encrypt data, but there was no way to ask a wallet to multiply an arbitrary point someone else gave you by your own secret number without ever learning that number or exposing it to the app.
A wallet backup can be restored on more than one phone or laptop, but if two devices both treat the same account as theirs to spend from, they can each build a payment from coins the other has already spent, and the blockchain will only accept one of them. Before this, the only fix was asking a server before every payment, which is slow and breaks when offline. This makes it possible to keep a vault's accounts spread across several trusted devices safely, without that per-payment check.
Signing in to a self-custodial wallet on a new phone is normally stuck between two bad options: either some server holds enough of your secret to log you in (so it can also be hacked or coerced into logging someone else in), or you have to manually copy a long recovery phrase between devices every time. This makes it hard to offer a simple "sign in with your email" experience without quietly giving a company the power to open your wallet.
A web app can only find the Bitcoin wallet running on a user's own computer by poking a handful of local addresses, and newer browsers treat that poke as suspicious and interrupt the user with a security dialog that never mentions the word "wallet". If the user clicks the wrong button, nothing explains what just happened, and the browser locks out that discovery permanently for that site. This leaves developers needing a way to prepare the user before that dialog appears, so a refusal is recoverable instead of final.
When a wallet request fails, today's wallets each write their own error sentence and hand it straight to the app, which has no choice but to show it to the user unchanged. That sentence rarely says whose fault the failure was, whether trying again is safe, or whether the payment might actually have gone through anyway. The result is users double-spending after a timeout, support tickets full of mismatched wording, and apps that cannot translate or shorten a message they did not write.
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.
Sometimes you need to prove something about one specific piece of a transaction, like a single stamped token, rather than the whole transaction. Existing proof formats bundle everything needed to trust a transaction, but they assume the thing you care about is the transaction itself, not one output buried inside it. Without a way to say "prove this particular output," you either send far more data than needed or leave out the odd extra transactions a token proof actually depends on.
Some BSV transaction bundles need to say 'here is everything about this one transaction' without being limited to only its ancestor history. Before this, a format that pinned down a single subject transaction, Atomic BEEF, forced the bundle to contain only ancestors and nothing else, which breaks when a protocol needs sibling or related transactions included too. Without a way to say 'this bag is about transaction X, and it can contain whatever a given use case requires,' a developer had no clean way to hand over a flexible, well-identified bundle.
Two different wallets checking the same unconfirmed payment describe what they verified in totally different ways, so there is no way to compare "three hops back to a confirmed block" against "a valid BEEF" or to let an app set one acceptance rule that works regardless of which wallet it is talking to. This leaves users and apps guessing what was actually checked before goods change hands, with no shared way to say it.
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.
Sometimes you need to prove something about one specific piece of a transaction, like a single stamped token, rather than the whole transaction. Existing proof formats bundle everything needed to trust a transaction, but they assume the thing you care about is the transaction itself, not one output buried inside it. Without a way to say "prove this particular output," you either send far more data than needed or leave out the odd extra transactions a token proof actually depends on.
Some BSV transaction bundles need to say 'here is everything about this one transaction' without being limited to only its ancestor history. Before this, a format that pinned down a single subject transaction, Atomic BEEF, forced the bundle to contain only ancestors and nothing else, which breaks when a protocol needs sibling or related transactions included too. Without a way to say 'this bag is about transaction X, and it can contain whatever a given use case requires,' a developer had no clean way to hand over a flexible, well-identified bundle.
Two different wallets checking the same unconfirmed payment describe what they verified in totally different ways, so there is no way to compare "three hops back to a confirmed block" against "a valid BEEF" or to let an app set one acceptance rule that works regardless of which wallet it is talking to. This leaves users and apps guessing what was actually checked before goods change hands, with no shared way to say it.
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.
Wallet users end up locked into one backup method forever. If your wallet was set up with a written-down word phrase, you cannot later split your backup into shares you hand to trusted people, and if it was set up with shares, you cannot get a word phrase out of it. Someone switching wallets or wanting both options at once has been stuck picking one at creation time.
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.
Wallet users end up locked into one backup method forever. If your wallet was set up with a written-down word phrase, you cannot later split your backup into shares you hand to trusted people, and if it was set up with shares, you cannot get a word phrase out of it. Someone switching wallets or wanting both options at once has been stuck picking one at creation time.
Search standards by number, title, author or topic