32 standards
How two parties produce an unlimited number of keys for each other without ever sending a private key. This is the mathematics most of the rest of the corpus sits on, so it is worth reading before the standards that assume it.
Also searched as key derivation, BKDS, type 42, BIP32, invoice number, derivation.
The key derivation scheme underneath most of the corpus. Two parties compute an ECDH shared secret and combine it with an invoice number, which lets a sender derive a public key for a recipient without knowing the recipient's private key, and lets the recipient later derive the matching private key.
Open in the glossary32 standards, spread across 7 of the 12 topics.
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.
Filed under Key derivation
Keys from one secret is the main subject of these 8.
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.
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.
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 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.
These are about something else, and deal with keys from one secret on the way.
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.
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.
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.
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.
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.
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.
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.
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.
Asking someone to create an account and back up a key before they have seen what an application does loses most of them. This starts them with a temporary key straight away and offers a proper one later, once they care.
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.
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.
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.
A BSV wallet normally logs into every website using the same permanent public key. That means any two sites that compare notes can tell their visitor is the same person, and the user has no way to stop it or start fresh. This makes it hard to build sites where users want separate, unlinkable accounts, like a different presence on each service.
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.
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 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 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.
Giving someone their first on-chain item requires them to have a wallet and coins, which they do not yet have. This lets a publisher fund it in advance so the recipient becomes the owner by clicking a link.
Sending someone a bit of digital cash normally means telling them who you are, because the payment format includes your long-term identity key. That's fine for a friend or a business you trust, but it means every coffee tip or casual peer payment lets the recipient permanently tag it to your identity and link it to every other payment you've ever made them. There was no easy way to pay someone spendable coins for a one-off transaction while keeping your long-term identity out of the record.
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.
Imagine selling a locked box online, but the "lock" is really just a sign that says "please don't look inside" while the contents sit in plain view for anyone who peeks at the underlying data. That's how paid content has actually been built on this chain: the restriction is a polite fiction, not a real barrier. This makes it possible to actually encrypt content once, publish it openly, and hand out the key only to people who paid or otherwise qualify, so access is real, survives the seller going offline, and gets more reliable the more people buy it.
Concepts that keep appearing on the same standards as this one.
Search standards by number, title, author or topic