mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-25 17:38:26 +00:00
264 lines
19 KiB
Plaintext
264 lines
19 KiB
Plaintext
[preface]
|
||
== Quick Glossary
|
||
|
||
This quick glossary contains many of the terms used in relation to bitcoin. These terms are used throughout the book, so bookmark this for a quick reference.
|
||
|
||
address::
|
||
A bitcoin address looks like +1DSrfJdB2AnWaFNgSbv3MZC2m74996JafV+. It consists of a string of letters and numbers. It's really an encoded base58check version of a public key 160-bit hash. Just as you ask others to send an email to your email address, you would ask others to send you bitcoin to one of your bitcoin addresses.
|
||
|
||
bip::
|
||
Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP-21 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.
|
||
|
||
bitcoin::
|
||
The name of the currency unit (the coin), the network, and the software.
|
||
|
||
block::
|
||
A grouping of transactions, marked with a timestamp, and a fingerprint of the previous block. The block header is hashed to produce a proof of work, thereby validating the transactions. Valid blocks are added to the main blockchain by network consensus.
|
||
|
||
blockchain::
|
||
A list of validated blocks, each linking to its predecessor all the way to the genesis block.
|
||
|
||
block reward (aka coinbase reward)::
|
||
An amount included in each new block as a reward by the network to the miner who found the Proof-of-Work solution. Approximately every four years, or more accurately every 210,000 blocks, the block reward is halved. It is currently 6.25 BTC per block.
|
||
|
||
Byzantine Generals Problem::
|
||
A reliable computer system must be able to cope with the failure of one or more of its components. A failed component may exhibit a type of behavior that is often overlooked--namely, sending conflicting information to different parts of the system. The problem of coping with this type of failure is expressed abstractly as the Byzantine Generals Problem.
|
||
|
||
candidate block::
|
||
A block that a miner is still trying to mine. It is not yet a valid block, because it does not contain a valid Proof-of-Work.
|
||
|
||
coinbase (aka coinbase data)::
|
||
A special field used as the sole input for coinbase transactions. The coinbase data field allows claiming the block reward and provides up to 100 bytes for arbitrary data.
|
||
Not to be confused with coinbase transaction or coinbase reward.
|
||
|
||
coinbase transaction::
|
||
The first transaction in a block. Always created by a miner, it includes a single coinbase.
|
||
Not to be confused with coinbase (coinbase data) or coinbase reward
|
||
|
||
cold storage::
|
||
Refers to keeping a reserve of bitcoin offline. Cold storage is achieved when Bitcoin private keys are created and stored in a secure offline environment. Cold storage is important for anyone with bitcoin holdings. Online computers are vulnerable to hackers and should not be used to store a significant amount of bitcoin.
|
||
|
||
confirmations::
|
||
Once a transaction is included in a block, it has one confirmation. As soon as _another_ block is mined on the same blockchain, the transaction has two confirmations, and so on. Six or more confirmations is considered sufficient proof that a transaction cannot be reversed.
|
||
|
||
consensus::
|
||
When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best block chain.
|
||
Not to be confused with consensus rules.
|
||
|
||
consensus rules::
|
||
The block validation rules that full nodes follow to stay in consensus with other nodes.
|
||
Not to be confused with consensus.
|
||
|
||
difficulty::
|
||
A network-wide setting that controls how much computation is required to produce a proof of work.
|
||
|
||
difficulty retargeting::
|
||
A network-wide recalculation of the difficulty that occurs once every 2,016 blocks and considers the hashing power of the previous 2,016 blocks.
|
||
|
||
difficulty target::
|
||
A difficulty at which all the computation in the network will find blocks approximately every 10 minutes.
|
||
|
||
double-spending::
|
||
Double spending is the result of successfully spending some money more than once. Bitcoin protects against double-spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent.
|
||
|
||
ECDSA::
|
||
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
|
||
|
||
extra nonce::
|
||
As difficulty increased, miners often cycled through all 4 billion values of the nonce without finding a block. Because the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks.
|
||
|
||
fees::
|
||
The sender of a transaction often includes a fee to the network for processing the requested transaction. Most transactions require a minimum fee of 0.5 mBTC.
|
||
|
||
fork::
|
||
Fork, also known as accidental fork, occurs when two or more blocks have the same block height, forking the block chain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack.
|
||
|
||
genesis block::
|
||
The first block in the blockchain, used to initialize the cryptocurrency.
|
||
|
||
halving::
|
||
A halving event occurs when the block reward is cut in half, which happens approximately every four years (or precisely every 210,000 blocks). Bitcoin already had three halving events: in 2012 (from 50 to 25 BTC), in 2016 (from 25 to 12.5 BTC), and in 2020 (from 12.5 to 6.25 BTC).
|
||
|
||
hard fork::
|
||
Hard fork, also known as Hard-Forking Change, is a permanent divergence in the blockchain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.
|
||
Not to be confused with fork, soft fork, software fork or Git fork.
|
||
|
||
hardware wallet::
|
||
A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
|
||
|
||
hash::
|
||
A digital fingerprint of some binary input.
|
||
|
||
hashlocks::
|
||
A hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time.
|
||
|
||
HD protocol::
|
||
The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP-32), which allows creating child keys from parent keys in a hierarchy.
|
||
|
||
HD wallet::
|
||
Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP-32).
|
||
|
||
HD wallet seed::
|
||
HD wallet seed or root seed is a potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet.
|
||
|
||
HTLC::
|
||
A Hashed TimeLock Contract or HTLC is a class of payments that use hashlocks and timelocks to require that the receiver of a payment either acknowledge receiving the payment prior to a deadline by generating cryptographic proof of payment or forfeit the ability to claim the payment, returning it to the payer.
|
||
|
||
KYC::
|
||
Know your customer (KYC) is the process of a business, identifying and verifying the identity of its clients. The term is also used to refer to the bank regulation which governs these activities.
|
||
|
||
LevelDB::
|
||
LevelDB is an open source on-disk key-value store. LevelDB is a light-weight, single-purpose library for persistence with bindings to many platforms.
|
||
|
||
Lightning Networks::
|
||
Lightning Network is an implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.
|
||
|
||
Locktime::
|
||
Locktime, or more technically nLockTime, is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain.
|
||
|
||
mempool::
|
||
The bitcoin Mempool (memory pool) is a collection of all transaction data in a block that have been verified by bitcoin nodes, but are not yet confirmed.
|
||
|
||
merkle root::
|
||
The root node of a merkle tree, a descendant of all the hashed pairs in the tree. Block headers must include a valid merkle root descended from all transactions in that block.
|
||
|
||
merkle tree::
|
||
A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root. In Bitcoin, the leaves are almost always transactions from a single block.
|
||
|
||
miner::
|
||
A network node that finds valid proof of work for new blocks, by repeated hashing.
|
||
|
||
mining reward::
|
||
The reward miners receive in return for the security provided by mining. Includes the new coins created with each new block, also known as a block reward or coinbase reward, and the transaction fees from all the transactions included in the block.
|
||
|
||
multisignature::
|
||
Multisignature (multisig) refers to requiring a minimum number (M) of keys (N) to authorize an M-of-N transaction.
|
||
|
||
network::
|
||
A peer-to-peer network that propagates transactions and blocks to every bitcoin node on the network.
|
||
|
||
nonce::
|
||
The "nonce" in a bitcoin block is a 32-bit (4-byte) field whose value is set so that the hash of the block will contain a run of leading zeros. The rest of the fields may not be changed, as they have a defined meaning.
|
||
|
||
off-chain transactions::
|
||
An off-chain transaction is the movement of value outside of the block chain. While an on-chain transaction—usually referred to as simply __a transaction__—modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction.
|
||
|
||
opcode::
|
||
Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.
|
||
|
||
Open Assets protocol::
|
||
The Open Assets Protocol is a simple and powerful protocol built on top of the bitcoin blockchain. It allows issuance and transfer of user-created assets.
|
||
|
||
OP_RETURN::
|
||
An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction.
|
||
|
||
OP_RETURN transaction::
|
||
A transaction type that adds arbitrary data to a provably unspendable pubkey script that full nodes don’t have to store in their UTXO database. Not to be confused with OP_RETURN opcode.
|
||
|
||
orphan block::
|
||
Blocks whose parent block has not been processed by the local node, so they can’t be fully validated yet. Not to be confused with stale block.
|
||
|
||
orphan transactions::
|
||
Transactions that can't go into the pool due to one or more missing input transactions.
|
||
|
||
output::
|
||
Output, transaction output, or TxOut is an output in a transaction which contains two fields: a value field for transferring zero or more satoshis and a pubkey script for indicating what conditions must be fulfilled for those satoshis to be further spent.
|
||
|
||
P2PKH::
|
||
Transactions that pay a bitcoin address contain P2PKH or Pay To PubKey Hash scripts. An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.
|
||
|
||
P2SH::
|
||
P2SH or Pay-to-Script-Hash is a powerful new type of transaction that greatly simplifies the use of complex transaction scripts. With P2SH the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, only a hash of it is in the locking script.
|
||
|
||
P2SH address::
|
||
P2SH addresses are Base58Check encodings of the 20-byte hash of a script. They use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". P2SH addresses hide all of the complexity, so that the person making a payment does not see the script.
|
||
|
||
P2WPKH::
|
||
The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified.
|
||
|
||
P2WSH::
|
||
The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is about the cryptographic proof location change from the scriptSig field to the witness field and the scriptPubKey that is also modified.
|
||
|
||
paper wallet::
|
||
In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes.
|
||
|
||
passphrase::
|
||
A passphrase is an optional string created by the user that serves as an additional security factor protecting the seed, even when the seed is compromised by a thief. It can also be used as a form of plausible deniability, where a chosen passphrase leads to a wallet with a small amount of funds used to distract an attacker from the “real” wallet that contains the majority of funds.
|
||
|
||
payment channels::
|
||
A micropayment channel or payment channel is class of techniques designed to allow users to make multiple bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants.
|
||
|
||
pooled mining::
|
||
Pooled mining is a mining approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power.
|
||
|
||
Proof-of-Stake::
|
||
Proof-of-Stake (PoS) is a method by which a cryptocurrency blockchain network aims to achieve distributed consensus. Proof-of-Stake asks users to prove ownership of a certain amount of currency (their "stake" in the currency).
|
||
|
||
Proof-of-Work::
|
||
A piece of data that requires significant computation to find. In bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network-wide target, the difficulty target.
|
||
|
||
RIPEMD-160::
|
||
RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more.
|
||
|
||
satoshi::
|
||
A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. ((("satoshi")))
|
||
|
||
Satoshi Nakamoto::
|
||
Satoshi Nakamoto is the name used by the person or people who designed Bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown.
|
||
|
||
Script::
|
||
Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
|
||
|
||
ScriptPubKey (aka pubkey script)::
|
||
ScriptPubKey or pubkey script, is a script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script.
|
||
|
||
ScriptSig (aka signature script)::
|
||
ScriptSig or signature script, is the data generated by a spender which is almost always used as variables to satisfy a pubkey script.
|
||
|
||
secret key (aka private key)::
|
||
The secret number that unlocks bitcoin sent to the corresponding address. pass:[<span class="keep-together">A secret</span>] key looks like the following:
|
||
+
|
||
----
|
||
5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh
|
||
----
|
||
|
||
Segregated Witness::
|
||
Segregated Witness is an upgrade to the Bitcoin protocol in which signature ("witness") data is separated from sender/receiver data to further optimize the structure of transactions. Segregated Witness was implemented as a soft fork; a change that technically makes Bitcoin’s protocol rules more restrictive.
|
||
|
||
SHA::
|
||
The Secure Hash Algorithm or SHA is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST).
|
||
|
||
Simplified Payment Verification (SPV)::
|
||
SPV or simplified payment verification is a method for verifying that particular transactions were included in a block, without downloading the entire block. This method of verification is often used by lightweight Bitcoin clients.
|
||
|
||
soft fork::
|
||
soft fork or Soft-Forking Change is a temporary fork in the blockchain which commonly occurs when miners using non-upgraded nodes don't follow a new consensus rule their nodes don’t know about.
|
||
Not to be confused with fork, hard fork, software fork or Git fork.
|
||
|
||
stale block::
|
||
A valid block that was successfully mined but that isn’t included on the current main branch (with most cumulative Proof-of-Work), because some other valid block that was mined at the same height had its chain extended first. The miner of a stale block doesn't get the block reward or the transactions fees of this block.
|
||
Not to be confused with orphan block or candidate block.
|
||
|
||
timelocks::
|
||
A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts.
|
||
|
||
transaction::
|
||
In simple terms, a transfer of bitcoin from one address to another. More precisely, a transaction is a signed data structure expressing a transfer of value. Transactions are transmitted over the bitcoin network, collected by miners, and included into blocks, made permanent on the blockchain.
|
||
|
||
transaction pool::
|
||
An unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions.
|
||
|
||
Turing completeness::
|
||
A programming language is called "Turing complete" if it can run any program that a Turing machine can run, given enough time and memory.
|
||
|
||
unspent transaction output (UTXO)::
|
||
UTXO is an unspent transaction output that can be spent as an input in a new transaction.
|
||
|
||
wallet::
|
||
Software that holds all your bitcoin addresses and secret keys. Use it to send, receive, and store your bitcoin.
|
||
|
||
Wallet Import Format (WIF)::
|
||
WIF or Wallet Import Format is a data interchange format designed to allow exporting and importing a single private key with a flag indicating whether or not it uses a compressed public key.
|
||
|
||
Some contributed definitions have been sourced under a CC-BY license from the https://en.bitcoin.it/wiki/Main_Page[bitcoin Wiki] or from other open source documentation sources.
|