- Bitcoin / bitcoin
- Bitcoin client
- Bitcoin Core (client)
- Bitcoin Core (project)
- BIP - Bitcoin improvement proposal
- Coin control
- Derivation path
- Extended private key (xpriv)
- Extended public key (xpub, ypub, zpub)
- Initial block download (IBD)
- Multi-signature wallet (Multisig)
- Output script descriptor
- Private key
- Public key
- Replace-by-fee (RBF)
- Recovery phrase
- Simplified payment verification (SPV)
- PayJoin (P2EP)
- Schnorr signature
- Segregated witness (SegWit)
- Unspent transaction output (UTXO)
- Partially signed bitcoin transaction (PSBT)
- Additional resources
A Bitcoin address is an identifier of 26-35 alphanumeric characters that is used to receive bitcoin. There are several address formats based on different specifications. Users need to know this information during backup for future recovery so applications should inform users which format it uses as support varies across applications.
Just like wallet, the term account can also be used for very different things. In bitcoin wallets that follow the hierarchy described in BIP44, a bitcoin wallet can have multiple accounts, with each one having its own addresses. However, account is also oftentimes used for accounts with third-party service providers.
- Bitcoin wallet account
- Service account
Bitcoin / bitcoin #
Bitcoin with a capital B is typically associated with Bitcoin the protocol and payment network. It is also often used to refer to as the ecosystem as a whole when writing about it in general terms. Bitcoin with a lowercase “b” written as “bitcoin” is usually associated specifically with bitcoin as the currency.
Bitcoin client #
Software that runs and/or connects to the Bitcoin network.
Bitcoin Core (client) #
Software considered the reference implementation for the Bitcoin protocol. It is the continuation of Satoshi Nakamoto’s original Bitcoin client released 9th January, 2009.
Bitcoin Core (project) #
An open-source project that maintains and releases the Bitcoin client of the same name.
BIP - Bitcoin improvement proposal #
A standardized technical document format for suggesting improvements to Bitcoin. They are hosted on Github here. Some important proposals to be aware of:
- BIP39: Mnemonic code for generating deterministic keys
- BIP44: Multi-account hierarchy for HD wallets
- BIP49: Derivation scheme for HD wallets using nested SegWit
- BIP84: Derivation scheme for HD wallets using SegWit
- BIP141: SegWit, changes to transaction structure
- BIP173: Bech32 standard for native SegWit addresses
- BIP174: Partially Signed Bitcoin Transaction Format
Coin control #
The act of choosing which unspent transaction output to forward to another address in a transaction. Wallet-applications can automatically choose the coins to use, but there are scenarios when users may want to manually choose what coins to send.
Fees are based on transaction size, which is based on the number of outputs included. So choosing fewer outputs can reduce fees.
As it is possible to trace the history of coins and see how they were previously spent, it may sometimes be warranted to not send certain coins because the recipient may be able to deduct personal information.
Allow for combining multiple payments from multiple spenders into a single transaction to make it harder to determine which spender paid which recipient(s). See also PayJoin.
Derivation path #
There are several standards for how to notate the path to a key and corresponding address in HD wallets. It is important to know which ones are used and supported by a wallet-application when importing and exporting a wallet. The most common are:
- BIP32: original, deprecated
- BIP44: multi-account for HD wallets
- BIP49: multi-account, for script addresses with nested-SegWit
- BIP84: multi-account, for SegWit addresses
BIP44 introduced the following structure, which BIP49 and BIP84 follow:
m / purpose / coin_type / account / change / index
The path to the first address in a bitcoin-wallet using BIP84 will look like this:
Extended private key (xpriv) #
In a hierarchical deterministic wallet, all addresses and their matching private keys are derived from this extended private key.
Extended public key (xpub, ypub, zpub) #
The master public key of a bitcoin account. All public addresses are generated from it.
Same as xpub however the y denotes that this xpub belongs to a wallet that is following the BIP49 standard that details the derivation scheme for wrapped-segwit addresses (P2WPKH-nested-in-P2SH).
Same as ypub though the z denotes it is an extended public key from a segregated witness enabled wallet following BIP84.
Initial block download (IBD) #
To fully verify that all transactions on the bitcoin network are valid, a full node needs to download and examine all previous block-data. This is called the initial block download, after which the node has caught up with the latest transaction activity. This can take several hours, and only after it is complete can wallets linked to the node be used.
When an address receives bitcoin from another address, this is called an input. Transactions can include multiple inputs.
A language for writing certain types of Bitcoin Scripts in a structured way. Miniscript is easier to read by developers, and also allows for various build-tools to help ensure that scripts are safe, valid, and efficient.
Multi-signature wallet (Multisig) #
Multi-signature wallets are bitcoin wallets that are controlled by more than one keypair. They can be defined by bitcoin scripts and use P2SH addresses. Common usecases and setups include 2-of-3, or 3-of-5 multi-signature wallets that require a subset of the controlling keypairs to sign a transaction.
A standard for multi-signature that uses Schnorr signatures. Previously, the more signers participated in a transaction, the size of the transaction got larger and took more time to verify. It was also possible to see the number of signers in the final transaction. MuSig addresses both issues. It hides the number of signers for better privacy. MuSig also improves scalability by reducing the size of transactions and being more efficient to verify. The original paper that describes MuSig.
- Proposal in the Cryptology ePrint archive
Node refers to software that participates in the Bitcoin network. It exchanges transaction data with other nodes, stores some or all of it, and verifies that transactions are valid. There is also dedicated node hardware.
The opposite of an input, an output is when an address sends bitcoin to another address. Transactions can include multiple outputs.
Output script descriptor #
A small piece of data that has all the information needed to generate a specific set of addresses or keys. Bundling this data in a standardized format has several benefits. It is harder to forget important configuration details, and it is more efficient than transmitting a long list of addresses or keys.
Private key #
Every bitcoin address has a public key and a corresponding private key, together they are called a keypair. If you have access to both the public and private key, you effectively control the funds in the address. As with HD Wallets there are also keypairs that control branches in the hierarchical tree of the wallet, and at the very top is the extended keypair (x-pub and x-prv for short) that control all the addresses in the wallet.
The private key is a 64 hexadecimal (or 256 if described in binary 1’s and 0’s) character string generated by the encryption algorithm. They look something like this in hexadecimal form:
Or for the extended private key:
Public key #
A bitcoin address’ public key can be derived from the private key. The address itself is a hash of the public key.
Replace-by-fee (RBF) #
A node policy that allows an unconfirmed transaction to be replaced with a different transaction that spends at least one of the same inputs and which pays a higher transaction fee. This can sometimes be useful if a transaction has got stuck during times of higher-than-normal network-fees.
Recovery phrase #
Also referred to as Seed, Mnemonic, and Backup phrase.
The controlling keypair of a bitcoin wallet can be derived from a recovery phrase of 12 words (or 18 or 24, which is less common) from a standardized list, defined in BIP39. The recovery phrase provides full access to a bitcoin wallet as it contains the private key and is therefore very valuable. It’s extremely important to keep it safe, both from other people getting access to it and for yourself not to lose it by creating one or several backups of the phrase. In many applications most of this work falls on the user and it’s important to acknowledge the responsibility here of the makers of the application to ensure that the user is able and aware of how to securely store a recovery phrase backup.
Many wallet-applications work with HD Wallets and recovery phrases, and are interoperable, meaning you can change the application that can control your wallet should you wish (although there are some caveats depending on if they support just BIP32 or also BIP44).
Technicalities - Recovery of multisig-wallets needs both the extended public key and the recovery phrase of all paticipating keys as well as the master key fingerprint as defined by BIP32 concatenated with the derivation path of the public key. The derivation path is represented as 32-bit little endian unsigned integer indexes concatenated with each other. The number of 32 bit unsigned integer indexes must match the depth provided in the extended public key.
Simplified payment verification (SPV) #
It is possible to verify bitcoin payments without running a full network node. This is called simplified payment verification, or SPV. A user’s bitcoin spv wallet only needs a copy of the block headers of the longest chain, which are available by querying network nodes until it is apparent that the longest chain has been obtained. SPV lets you validate your transactions without having to worry about anybody else’s transactions. It ensures your transactions are in a block, and it provides confirmations that additional blocks are being added to the chain. An SPV wallet is a type of bitcoin wallet that works this way.
PayJoin (P2EP) #
A type of CoinJoin for direct transactions between two parties that makes it harder to understand the ownership of the inputs included in the transaction. The sender creates a partial transaction that the recipient adds another input to. Then the sender broadcasts the transaction. The same amount of bitcoin is transferred as in a simple bitcoin transaction. However, the additional input from the recipient makes it harder to analyze from the outside what happened in the transaction.
Schnorr signature #
An algorithm to generate cryptographic signatures. One of the benefits is that the size of multi signature transactions can be reduced, resulting in lower fees, and that multisignature transactions will appear equal to single signature, increasing privacy (see MuSig). The code for this improvement was merged in Bitcoin Core in September 2020.
Segregated witness (SegWit) #
Segregated Witness, or SegWit, is the name for a soft fork change in the transaction format of Bitcoin. It was described in BIP141. It was intended to mitigate a blockchain size limitation problem that reduces bitcoin transaction speed. It does this by splitting the transaction into two segments, removing the unlocking signature (witness data) from the original portion and appending it as a separate structure at the end. The original section hold the sender and receiver data, and the new witness structure contain scripts and signatures.
A technique that makes complex multisig transactions look the same as standard transactions on the blockchain. This improves both efficiency and privacy, as multiple signatures are combined into a single one.
Unspent transaction output (UTXO) #
An output that has not been sent to another address. The bitcoin wallet balance is calculated from adding up unspent outputs.
Partially signed bitcoin transaction (PSBT) #
A file format for bitcoin transactions that are not fully signed yet. Allows for passing around a transaction to other applications or devices for signing, for example in a multi signature wallet setup.
- BIP174: Partially Signed Bitcoin Transaction Format
A passphrase can be added to the recovery phrase for extra security. Technically, all recovery phrases have a pass phrase. If it’s not set by the user, an empty string (“”) will be used by default. Using the recovery phrase with or without the user-defined pass phrase will recover two DIFFERENT wallets. Pass phrases are sometimes referred to as the password, the extra word, or the 13th/25th word.
- BIP39: Mnemonic code for generating deterministic keys
A term sometimes used for multi-signature wallets.