Glossary

A transaction as the wallet interface talks about it: the transaction itself plus the description, labels and output metadata a wallet keeps alongside it.

A BEEF bundle restricted to exactly one subject transaction and its ancestry, for cases where a general bundle of several transactions would be ambiguous about which one matters.

A named grouping a wallet uses to track the outputs belonging to one application or purpose. An application can list what is in its basket, and spending an output removes it from the basket.

A format that bundles a transaction together with the ancestor transactions and merkle proofs needed to check it. The recipient can verify it against block headers alone, without asking a node or an indexer for anything.

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.

A compact binary format for a merkle path, carrying the hashes needed to prove a transaction is in a block. It is the proof format BEEF carries.

The party that issues an identity certificate. Anyone relying on the certificate is trusting the certifier, not the site showing it.

The other party a key is derived with respect to. Because derivation uses a shared secret between two identity keys, a key derived for one counterparty is meaningless to anyone else.

A way for two parties to compute the same shared secret from their own private key and the other party's public key, without either private key being sent anywhere.

A signed statement by a certifier about someone's identity, with the fields encrypted so the holder chooses which to reveal and to whom.

The master public key that identifies a wallet, and by extension its user. It is safe to share, and other standards derive per-purpose keys from it rather than using it directly.

The string fed into key derivation that makes each derived key unique. It is open-ended by design, so a protocol can number its keys however suits it.

Distinguishes one key from another within the same protocol, so an application can hold many keys for the same purpose.

The conditions attached to an output that say how it may be spent. The spender supplies an unlocking script that has to satisfy them.

The read side of an overlay: the interface for querying the outputs it is tracking, as opposed to submitting new transactions to it.

The sequence of hashes that connects one transaction to the merkle root in a block header. Following it proves the transaction was included in that block without needing the rest of the block.

A single hash at the top of a tree built from every transaction in a block, stored in the block header. Any change to any transaction changes it.

A reference to one specific transaction output, written as the transaction id followed by the index of the output within it.

An index that watches the chain for the subset of transactions one application cares about, grouped under a topic. It exists because scanning the whole chain for your own data does not scale.

The most common way to lock an output: it can be spent by whoever proves they hold the private key for a given public key hash. What a traditional Bitcoin address encodes.

An addressing scheme that uses a human-readable name at a domain in place of a Bitcoin address, resolving to a payment destination over HTTPS.

Names what a derived key is for, so keys used for one purpose cannot be reused for another. Paired with a security level that decides how much the user is asked to approve.

A script template that pushes arbitrary data onto the stack, drops it, then applies an ordinary key lock. The result is an output that carries metadata and is still spendable, which is how these standards represent tokens.

The specific elliptic curve Bitcoin uses for its keys and signatures. Every public key in these standards is a point on it.

How broadly a user's permission applies when an application asks to use a key: whether the approval covers the protocol generally, or is scoped to a specific counterparty.

Advertisements that let overlay nodes find each other: SHIP, Service Host Interconnect, announces which topics a host tracks, and SLAP, Service Lookup Availability, announces which lookup services it offers.

Checking that a transaction is in a block by verifying a merkle proof against block headers, instead of downloading and validating the whole chain. It is what lets a wallet on a phone accept a payment.

The transport an application uses to reach a wallet on the same device, such as HTTP to a local port or a browser window message. The calls are the same whichever is used.

The label an overlay tracks outputs under. Submitting a transaction to a topic returns which of its outputs that overlay admitted and which earlier outputs it retained.

An earlier format for sending a transaction together with the input transactions and merkle proofs a recipient needs to verify it. BEEF is the format that replaced it.

A way to find a file by its hash rather than by a URL, with hosts advertising on an overlay that they are holding it. Content survives any one host going offline.

An output of a past transaction that has not yet been spent. A wallet's balance is the sum of the UTXOs it can unlock, and several standards here treat a UTXO as a token rather than as loose change.

The vendor-neutral set of calls an application uses to ask a wallet to do things: build transactions, derive keys, encrypt data, sign messages, prove identity. Defined by BRC-100.