<p>As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.</p>
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22). David previously worked freelance (2007-15).</p>
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the co-author of the Bitcoin Optech weekly newsletter (2018-23), 21.co Bitcoin Computer tutorials (2015-17), and Bitcoin.org developer documentation (2014-15). He is also a Brink.dev grant committee member (2022-23) and former board member (2020-22).</p>
(UTXO)")))((("UTXO sets")))The use of bitcoin's blockchain to store data
unrelated to bitcoin payments is a controversial subject. Many
(UTXO)")))((("UTXO sets")))The use of Bitcoin's blockchain to store data
unrelated to Bitcoin payments is a controversial subject. Many
people consider such use abusive and want to discourage it. Others
view it as a demonstration of the powerful capabilities of blockchain
technology and want to encourage such experimentation. Those who object
to the inclusion of nonpayment data argue that it causes "blockchain
bloat," burdening those running full Bitcoin nodes with carrying the
to the inclusion of nonpayment data argue that it
burdens those running full Bitcoin nodes with carrying the
cost of disk storage for data that the blockchain was not intended to
carry. Moreover, such transactions create UTXOs that cannot be spent,
using the destination legacy Bitcoin address as a freeform 20-byte field.
carry. Moreover, such transactions may create UTXOs that cannot be spent,
using legacy Bitcoin address as a freeform 20-byte field.
Because the address is used for data, it doesn't correspond to a private
key and the resulting UTXO can _never_ be spent; it's a fake payment.
These transactions that can never be spent are therefore never removed
@ -789,10 +776,10 @@ Let's explain that with the following example.
However:
* Alice can create another transaction, double-spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Alice can create a conflicting transaction, spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Bob has no guarantee that Alice won't do that.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. To guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. One way to guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
==== Check Lock Time Verify (OP_CLTV)
@ -804,7 +791,7 @@ timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
specification in BIP65, a new script operator called
_OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
+OP_CLTV+ is a per-output timelock, rather than a per-transaction timelock
as is the case with lock time. This allows for much greater
as is the case with lock time. This allows for additional
flexibility in the way timelocks are applied.
In simple terms, by committing to the +OP_CLTV+ opcode in an
@ -823,25 +810,24 @@ results in TRUE, execution continues.
In order to use +OP_CLTV+, you insert it into the redeem script of the
output in the transaction that creates the output. For
example, if Alice is paying Bob's address, the output would normally
contain a P2PKH script like this:
example, if Alice is paying Bob, he might usually accept payment to
the following P2SH script:
----
OP_DUP OP_HASH160 <Bob's Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG
<Bob's public key> OP_CHECKSIG
----
To lock it to a time, say 3 months from now, the transaction would be a
P2SH transaction with a redeem script like this:
To lock it to a time, say 3 months from now, his P2SH script would
((("bitcoin improvement proposals", "types of")))Bitcoin Improvement Proposals are design documents providing information to the bitcoin community, or for describing a new feature for bitcoin or its processes or environment.
((("bitcoin improvement proposals", "types of")))Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community, or for describing a new feature for Bitcoin or its processes or environment.
As per BIP1 _BIP Purpose and Guidelines_, there are three kinds of BIPs:
_Standard_ BIP:: Describes any change that affects most or all bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using bitcoin.
_Informational_ BIP:: Describes a bitcoin design issue, or provides general guidelines or information to the bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
_Process_ BIP:: Describes a bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in bitcoin development. Any meta-BIP is also considered a process BIP.
_Standard_ BIP:: Describes any change that affects most or all Bitcoin implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Bitcoin.
_Informational_ BIP:: Describes a Bitcoin design issue, or provides general guidelines or information to the Bitcoin community, but does not propose a new feature. Informational BIPs do not necessarily represent a Bitcoin community consensus or recommendation, so users and implementors may ignore informational BIPs or follow their advice.
_Process_ BIP:: Describes a Bitcoin process, or proposes a change to (or an event in) a process. Process BIPs are like standard BIPs but apply to areas other than the Bitcoin protocol itself. They might propose an implementation, but not to Bitcoin's codebase; they often require community consensus; and unlike informational BIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Bitcoin development. Any meta-BIP is also considered a process BIP.
((("bitcoin improvement proposals", "repository of")))BIPs are recorded in a versioned repository on GitHub: https://github.com/bitcoin/bips[https://github.com/bitcoin/bips].
An MIT-licensed document from the open source Bitcoin Core project,
reproduced here in edited form, describes which BIPs it implements, including listing
the version of Bitcoin Core where support for each BIP was added or
the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or
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.
A grouping of transactions, marked with a timestamp, and a commitment to 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.
@ -41,7 +41,7 @@ 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 blockchain.
When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best blockchain.
Not to be confused with consensus rules.
consensus rules::
@ -58,7 +58,7 @@ 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 blockchain to ensure that the inputs for the transaction had not previously already been spent.
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 blockchain 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.
@ -70,7 +70,7 @@ 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 blockchain. Typically occurs when two or more miners find blocks at nearly the same time. Can also happen as part of an attack.
Fork, also known as accidental fork, occurs when two or more blocks have the same block height, forking the blockchain. 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.
@ -82,8 +82,9 @@ hard 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.
//FIXME: needs improvement
hash::
A digital fingerprint of some binary input.
A digital commitment to 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.
@ -110,7 +111,7 @@ Lightning Networks::
Lightning Network is a proposed 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.
Lock time::
Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the blockchain.
Lock time is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the blockchain.
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.
@ -133,15 +134,12 @@ 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 blockchain. 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.
offchain transactions::
An offchain transaction is the movement of value outside of the blockchain. While an onchain transaction—usually referred to as simply __a transaction__—modifies the blockchain and depends on the blockchain to determine its validity an offchain 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. The Open Assets protocol is an evolution of the concept of colored coins.
OP_RETURN::
An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction.
@ -176,7 +174,7 @@ 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.
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 blockchain but an unlimited or nearly unlimited number of payments can be made between the participants.
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 blockchain 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.
@ -229,7 +227,7 @@ soft fork::
Not to be confused with fork, hard fork, software fork or Git fork.
stale block::
Block that was successfully mined but that isn’t included on the current best blockchain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan block.
Block that was successfully mined but that isn’t included on the current best blockchain, likely because some other block at the same height had its chain extended first. Not to be confused with orphan 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.
@ -36,7 +36,7 @@ transactions. Any participant in the Bitcoin network may operate as a
miner, using their computing devices to help secure
transactions. Every 10 minutes, on average, one Bitcoin miner can add security to
past transactions and is rewarded with both brand new
bitcoin and the fees paid by recent transactions. Essentially, Bitcoin
bitcoins and the fees paid by recent transactions. Essentially, Bitcoin
mining decentralizes the currency-issuance
and clearing functions of a central bank and replaces the need for any
central bank.
@ -54,14 +54,14 @@ mining function across the network. The difficulty of the computational
task that miners must perform is adjusted dynamically so that, on
average, someone succeeds every 10 minutes regardless of how many miners
(and how much processing) are competing at any moment. The protocol also
periodically decreases the number of new bitcoins are created,
limiting the total number of bitcoins that will be created to a fixed total
periodically decreases the number of new bitcoins that are created,
limiting the total number of bitcoins that will ever be created to a fixed total
just below 21 million coins. The result is that the number of bitcoins in
circulation closely follows an easily predictable curve where half of
the remaining coins are added to circulation every four years. At
approximately block 1,411,200, which is expected to be produced around
the year 2035, 99% of all bitcoins
that will ever exist will have been issued. Due to bitcoin's
that will ever exist will have been issued. Due to Bitcoin's
diminishing rate of issuance, over the long term, the Bitcoin currency
is deflationary. Furthermore, nobody can force you to accept
any bitcoins that were created beyond the
@ -70,7 +70,7 @@ expected issuance rate.
Behind the scenes, Bitcoin is also the name of the protocol, a peer-to-peer network, and a distributed computing innovation. Bitcoin builds on decades of research in cryptography and distributed systems and includes at least four key innovations brought together in a unique and powerful combination. Bitcoin consists of:
* A decentralized peer-to-peer network (the Bitcoin protocol)
* A public transaction ledger (the blockchain)
* A public transaction journal (the blockchain)
* ((("mining and consensus", "consensus rules", "satisfying")))A set of rules for independent transaction validation and currency issuance (consensus rules)
* A mechanism for reaching global decentralized consensus on the valid blockchain (Proof-of-Work algorithm)
@ -164,7 +164,6 @@ derived from the original implementation written by Satoshi Nakamoto.
((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the Bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. Therefore it would be pointless to recommend a specific brand or wallet. However, we can categorize Bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. It is worth trying out several different wallets until you find one that fits your needs.
[role="pagebreak-before"]
===== Types of Bitcoin wallets
Bitcoin wallets can be categorized as follows, according to the platform:
@ -203,7 +202,7 @@ role in how much security and privacy the user obtains when using the
hardware signing device.
===== Full-node vs. Lightweight
Another way to categorize bitcoin wallets is by their degree of autonomy and how they interact with the Bitcoin network:
Another way to categorize Bitcoin wallets is by their degree of autonomy and how they interact with the Bitcoin network:
Full-node:: ((("full-node")))A full node is a program that validates the
entire history of Bitcoin transactions (every transaction by every user,
@ -247,8 +246,8 @@ A very important additional consideration is _who controls the keys_. As
we will see in subsequent chapters, access to bitcoins is
controlled by "private keys", which are like very long PIN numbers. If
you are the only one to have *control* over these private
keys, you are in control of your bitcoin. Conversely, if you do not have
control, then your bitcoin is managed by a third-party who
keys, you are in control of your bitcoins. Conversely, if you do not have
control, then your bitcoins are managed by a third-party who
ultimately controls your funds on your behalf. Key management software falls into two
important categories based on control: _wallets_, where you
control the keys, and the funds and accounts with custodians where some
@ -264,16 +263,6 @@ accounts with third parties (you don't control the keys). The lines between diff
are sometimes blurry, as software runs on multiple platforms and can
interact with the network in different ways.
For the purposes of this book, we will be demonstrating the use of a
variety of downloadable Bitcoin software, from the reference
implementation (Bitcoin Core) to mobile and web software. Some of the
examples will require the use of Bitcoin Core, which, in addition to
being a full node, also exposes APIs to the wallet, network, and
transaction services. If you are planning to explore the programmatic
interfaces into the Bitcoin system, you will need to run Bitcoin Core,
or one of the alternative full node implementations.((("", startref="GSwallet01")))((("",
startref="Wselect01")))
==== Quick Start
((("getting started", "quick start example",
@ -374,19 +363,19 @@ ensure you aren't being phished.
==== Bitcoin addresses
Alice is now ready to start using her new bitcoin wallet. ((("", startref="GSquick01")))((("", startref="Wquick01"))) Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service.
Alice is now ready to start using her new Bitcoin wallet. ((("", startref="GSquick01")))((("", startref="Wquick01"))) Her wallet application randomly generated a private key (described in more detail in <<private_keys>>) which will be used to derive Bitcoin addresses that direct to her wallet. At this point, her Bitcoin addresses are not known to the Bitcoin network or "registered" with any part of the Bitcoin system. Her Bitcoin addresses are simply numbers that correspond to her private key that she can use to control access to the funds. The addresses are generated independently by her wallet without reference or registration with any service.
are a variety of Bitcoin addresses and invoice formats. Addresses and
invoices can be shared with other bitcoin users
who can use them to send bitcoin directly to your wallet. You can share
invoices can be shared with other Bitcoin users
who can use them to send bitcoins directly to your wallet. You can share
an address or invoice with other people without worrying about the
security of your bitcoins. Unlike a bank account number, nobody who
learns one of your Bitcoin addresses can withdraw money from your wallet--you
must initiate all spends. However, if you give two people the same
address, they will be able to see how much bitcoin the other person sent
address, they will be able to see how many bitcoins the other person sent
you. If you post your address publicly, everyone will be able to see
how much bitcoin other people sent to that address. To protect your privacy, you
should generate a new invoice with a new address each time you request a
@ -420,10 +409,10 @@ Bitcoin transactions are irreversible. Most electronic payment networks such as
[role="pagebreak-before"]
Here are some methods for acquiring bitcoin as a new user:
* Find a friend who has bitcoin and buy some from him or her directly. Many Bitcoin users start this way. This method is the least complicated. One way to meet people with bitcoin is to attend a local Bitcoin meetup listed at https://meetup.com[Meetup.com].
* Earn bitcoin by selling a product or service for bitcoin. If you are a programmer, sell your programming skills. If you're a hairdresser, cut hair for bitcoin.
* ((("Coin ATM Radar")))((("ATMs, locating")))Use a bitcoin ATM in your city. A bitcoin ATM is a machine that accepts cash and sends bitcoin to your smartphone bitcoin wallet.
* ((("exchange rates", "listing services")))Use a bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoin with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of bitcoin exchanges for each currency.
* Find a friend who has bitcoins and buy some from him or her directly. Many Bitcoin users start this way. This method is the least complicated. One way to meet people with bitcoins is to attend a local Bitcoin meetup listed at https://meetup.com[Meetup.com].
* Earn bitcoin by selling a product or service for bitcoin. If you are a programmer, sell your programming skills. If you're a hairdresser, cut hair for bitcoins.
* ((("Coin ATM Radar")))((("ATMs, locating")))Use a Bitcoin ATM in your city. A Bitcoin ATM is a machine that accepts cash and sends bitcoins to your smartphone Bitcoin wallet.
* ((("exchange rates", "listing services")))Use a Bitcoin currency exchange linked to your bank account. Many countries now have currency exchanges that offer a market for buyers and sellers to swap bitcoins with local currency. Exchange-rate listing services, such as https://bitcoinaverage.com[BitcoinAverage], often show a list of Bitcoin exchanges for each currency.
[TIP]
====
@ -439,26 +428,27 @@ touches traditional systems, such as currency exchanges, national and
international regulations often apply. In order to exchange bitcoin for
your national currency, you will often be required to provide proof of
identity and banking information. Users should be aware that once a
Bitcoin address is attached to an identity, other associated bitcoin
Bitcoin address is attached to an identity, other associated Bitcoin
transactions may also become easy to identify and track--including
transactions made earlier. This is one reason
many users choose to maintain dedicated exchange accounts independent from
their wallets.
====
Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoin. Next, we will look at how she buys bitcoin from her friend Joe and how Joe sends the bitcoin to her wallet.
Alice was introduced to Bitcoin by a friend so she has an easy way to acquire her first bitcoins. Next, we will look at how she buys bitcoins from her friend Joe and how Joe sends the bitcoins to her wallet.
[[bitcoin_price]]
==== Finding the Current Price of Bitcoin
((("getting started", "exchange rates")))((("exchange rates", "determining")))Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to bitcoin: "Who sets the bitcoin price?" The short answer is that the price is set by markets.
((("getting started", "exchange rates")))((("exchange rates", "determining")))Before Alice can buy bitcoin from Joe, they have to agree on the _exchange rate_ between bitcoin and US dollars. This brings up a common question for those new to Bitcoin: "Who sets the price
of bitcoins?" The short answer is that the price is set by markets.
((("exchange rates", "floating")))((("floating exchange rate")))Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoin and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD).
((("exchange rates", "floating")))((("floating exchange rate")))Bitcoin, like most other currencies, has a _floating exchange rate_. That means that the value of bitcoin fluctuates according to supply and demand in the various markets where it is traded. For example, the "price" of bitcoin in US dollars is calculated in each market based on the most recent trade of bitcoins and US dollars. As such, the price tends to fluctuate minutely several times per second. A pricing service will aggregate the prices from several markets and calculate a volume-weighted average representing the broad market exchange rate of a currency pair (e.g., BTC/USD).
There are hundreds of applications and websites that can provide the current market rate. Here are some of the most popular:
https://bitcoinaverage.com/[Bitcoin Average]:: ((("BitcoinAverage")))A site that provides a simple view of the volume-weighted-average for each currency.
https://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of crypto-currencies, including bitcoin.
https://coincap.io/[CoinCap]:: A service listing the market capitalization and exchange rates of hundreds of crypto-currencies, including bitcoins.
https://www.cmegroup.com/markets/cryptocurrencies/cme-cf-cryptocurrency-benchmarks.html?redirect=/trading/cryptocurrency-indices/cf-bitcoin-reference-rate.html[Chicago Mercantile Exchange Bitcoin Reference Rate]:: A reference rate that can be used for institutional and contractual reference, provided as part of investment data feeds by the CME.
In addition to these various sites and applications, some bitcoin
@ -471,7 +461,7 @@ currencies.
((("getting started", "sending and receiving bitcoin",
example")))((("spending bitcoin", see="also transactions")))Alice has
decided to buy 0.001 bitcoin. After she and Joe check the exchange rate,
decided to buy 0.001 bitcoins. After she and Joe check the exchange rate,
she gives Joe an appropriate amount of cash, opens her mobile wallet
application, and selects Receive. This
displays a QR code with Alice's first Bitcoin address.
@ -479,7 +469,7 @@ displays a QR code with Alice's first Bitcoin address.
Joe then selects Send on his smartphone wallet and opens the QR code
scanner. This allows Joe to scan the barcode with his smartphone camera
so that he doesn't have to type in Alice's Bitcoin address, which is
quite long and difficult to type.
quite long.
Joe now has Alice's Bitcoin address set as the recipient. Joe enters the
amount as 0.001 bitcoins (BTC), see <<wallet-send>>. Some wallets may
@ -521,7 +511,7 @@ transaction, Alice's wallet will indicate that it is receiving
[[confirmations]]
.Confirmations
****
((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the bitcoin transaction ledger, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <<mining>>.
((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the Bitcoin transaction journal, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <<mining>>.
****
Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01")))
Alice is now the proud owner of 0.001 BTC that she can spend. Over the next few days, Alice buys more bitcoin using an ATM and an exchange. In the next chapter we will look at her first purchase with Bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01")))
@ -9,7 +9,7 @@ Two years later, after creating a number of small startups to explore various Bi
=== Intended Audience
((("intended audience")))This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of bitcoin and cryptocurrencies.
((("intended audience")))This book is mostly intended for coders. If you can use a programming language, this book will teach you how cryptographic currencies work, how to use them, and how to develop software that works with them. The first few chapters are also suitable as an in-depth introduction to Bitcoin for noncoders—those trying to understand the inner workings of Bitcoin and cryptocurrencies.
=== Why Are There Bugs on the Cover?
@ -55,13 +55,13 @@ All the code snippets can be replicated on most operating systems with a minimal
Some of the code snippets and code output have been reformatted for print. In all such cases, the lines have been split by a backslash (\) character, followed by a newline character. When transcribing the examples, remove those two characters and join the lines again and you should see identical results as shown in the example.
All the code snippets use real values and calculations where possible, so that you can build from example to example and see the same results in any code you write to calculate the same values. For example, many of the private keys and corresponding public keys and addresses are real. The sample transactions, blocks, and blockchain references are all part of the actual Bitcoin blockchain, so you can review them on any Bitcoin system.
All the code snippets use real values and calculations where possible, so that you can build from example to example and see the same results in any code you write to calculate the same values.
=== Using Code Examples
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023 Andreas M. Antonopoulos, 978-1-491-95438-6.”
((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.”
((("open source licenses")))Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
@ -119,7 +119,6 @@ Follow us on Twitter: link:$$https://twitter.com/oreillymedia$$[]
Watch us on YouTube: link:$$https://www.youtube.com/oreillymedia$$[]
[role="pagebreak-before"]
=== Contacting the Authors
You can contact Andreas M. Antonopoulos on his personal site:
@ -147,9 +146,9 @@ link:$$https://dtrt.org/$$[]
_By Andreas M. Antonopoulos_
((("acknowledgments", id="acknowledge0")))This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and bitcoin.
((("acknowledgments", id="acknowledge0")))This book represents the efforts and contributions of many people. I am grateful for all the help I received from friends, colleagues, and even complete strangers, who joined me in this effort to write the definitive technical book on cryptocurrencies and Bitcoin.
It is impossible to make a distinction between the bitcoin technology and the bitcoin community, and this book is as much a product of that community as it is a book on the technology. My work on this book was encouraged, cheered on, supported, and rewarded by the entire bitcoin community from the very beginning until the very end. More than anything, this book has allowed me to be part of a wonderful community for two years and I can't thank you enough for accepting me into this community. There are far too many people to mention by name—people I've met at conferences, events, seminars, meetups, pizza gatherings, and small private gatherings, as well as many who communicated with me by Twitter, on reddit, on bitcointalk.org, and on GitHub who have had an impact on this book. Every idea, analogy, question, answer, and explanation you find in this book was at some point inspired, tested, or improved through my interactions with the community. Thank you all for your support; without you this book would not have happened. I am forever grateful.
It is impossible to make a distinction between the Bitcoin technology and the Bitcoin community, and this book is as much a product of that community as it is a book on the technology. My work on this book was encouraged, cheered on, supported, and rewarded by the entire Bitcoin community from the very beginning until the very end. More than anything, this book has allowed me to be part of a wonderful community for two years and I can't thank you enough for accepting me into this community. There are far too many people to mention by name—people I've met at conferences, events, seminars, meetups, pizza gatherings, and small private gatherings, as well as many who communicated with me by Twitter, on reddit, on bitcointalk.org, and on GitHub who have had an impact on this book. Every idea, analogy, question, answer, and explanation you find in this book was at some point inspired, tested, or improved through my interactions with the community. Thank you all for your support; without you this book would not have happened. I am forever grateful.
The journey to becoming an author starts long before the first book, of course. My first language (and schooling) was Greek, so I had to take a remedial English writing course in my first year of university. I owe thanks to Diana Kordas, my English writing teacher, who helped me build confidence and skills that year. Later, as a professional, I developed my technical writing skills on the topic of data centers, writing for _Network World_ magazine. I owe thanks to John Dix and John Gallant, who gave me my first writing job as a columnist at _Network World_ and to my editor Michael Cooney and my colleague Johna Till Johnson who edited my columns and made them fit for publication. Writing 500 words a week for four years gave me enough experience to eventually consider becoming an author.
@ -157,7 +156,7 @@ Thanks also to those who supported me when I submitted my book proposal to O'Rei
Thanks to Cricket Liu, author of the O'Reilly title _DNS and BIND_, who introduced me to O'Reilly. Thanks also to Michael Loukides and Allyson MacDonald at O'Reilly, who worked for months to help make this book happen. Allyson was especially patient when deadlines were missed and deliverables delayed as life intervened in our planned schedule. For the second edition, I thank Timothy McGovern for guiding the process, Kim Cofer for patiently editing, and Rebecca Panzer for illustrating many new diagrams.
The first few drafts of the first few chapters were the hardest, because bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of bitcoin through the stories of the people using bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
The first few drafts of the first few chapters were the hardest, because Bitcoin is a difficult subject to unravel. Every time I pulled on one thread of the Bitcoin technology, I had to pull on the whole thing. I repeatedly got stuck and a bit despondent as I struggled to make the topic easy to understand and create a narrative around such a dense technical subject. Eventually, I decided to tell the story of Bitcoin through the stories of the people using Bitcoin and the whole book became a lot easier to write. I owe thanks to my friend and mentor, Richard Kagan, who helped me unravel the story and get past the moments of writer's block. I thank Pamela Morgan, who reviewed early drafts of each chapter in the first and second edition of the book, and asked the hard questions to make them better. Also, thanks to the developers of the San Francisco Bitcoin Developers Meetup group as well as Taariq Lewis and Denise Terry for helping test the early material. Thanks also to Andrew Naugler for infographic design.
During the development of the book, I made early drafts available on GitHub and invited public comments. More than a hundred comments, suggestions, corrections, and contributions were submitted in response. Those contributions are explicitly acknowledged, with my thanks, in <<github_contrib>>. Most of all, my sincere thanks to my volunteer GitHub editors Ming T. Nguyen (1st edition) and Will Binns (2nd edition), who worked tirelessly to curate, manage and resolve pull requests, issue reports, and perform bug fixes on GitHub.
@ -201,7 +200,7 @@ of you often and know that my contributions to this book would not have
been possible without all that you've done for me.
[[github_contrib]]
==== Early Release Draft (GitHub Contributions)
=== Early Release Draft (GitHub Contributions)
Many contributors offered comments, corrections, and additions to the early-release draft on GitHub. Thank you all for your contributions to this book.
in the recovery code, a reference to the date when the user created
the wallet database; this allows a restoration process to find all of
the funds associated with a wallet without scanning the entire
blockchain, which is especially useful for privacy-focused wallets.
blockchain, which is especially useful for privacy-focused lightweight clients.
It includes support for changing the passphrase or changing other
aspects of the recovery code without needing to move funds to a new
seed--the user need only back up a new recovery code. One
@ -414,8 +414,9 @@ The most important data in a wallet database is its private keys. If
you lose access to the private keys, you lose the ability to spend your
bitcoins. Deterministic key derivation and recovery codes provide a
reasonably robust solution for backing up and recovering your keys and
the bitcoins they control. But many wallet databases store more than
just keys. They also also store user-provided information about every
the bitcoins they control. However, it's important to consider that
many wallet databases store more than
just keys--they also also store user-provided information about every
transaction they sent or received.
For example, when Bob creates a new address as part of sending an
@ -499,7 +500,7 @@ even a small fraction of every possible key in a BIP32 tree, which means
that recovering from data loss requires knowing more than just the
recovery code, the algorithm for obtaining your seed (e.g. BIP39), and
the deterministic key derivation algorithm
(e.g., BIP32)---it also requires knowing what paths in the tree of keys
(e.g., BIP32)--it also requires knowing what paths in the tree of keys
your wallet application used for generating the specific keys it distributed.
Two solutions to this problem have been adopted. The first is using
@ -592,7 +593,7 @@ A few example descriptors are shown in <<sample_descriptors>>.
| P2SH multi-signature requring two signatures corresponding to these two keys
| pkh([d34db33f/44'/0'/0']xpub6ERA...RcEL/1/*)
| P2PKH scripts for the BIP32 wallet with fingerprint d34db33f with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub.
| P2PKH scripts for the BIP32 +d34db33f+ with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub.
|===
It has long been the trend for wallet applications designed only for
@ -899,18 +900,6 @@ combination with a carefully planned process for backup and recovery,
considering the possibility of surviving the owner and allowing his or
her family to recover the cryptocurrency estate.
===== Working with BIP39 recovery codes
BIP39 is implemented as a library in many different programming
languages:
https://github.com/trezor/python-mnemonic[python-mnemonic]:: The
reference implementation of the standard by the SatoshiLabs team that
proposed BIP39, in Python
https://github.com/bitcoinjs/bip39[bitcoinjs/bip39]:: An implementation
of BIP39, as part of the popular bitcoinJS framework, in JavaScript
[[hd_wallet_details]]
==== Creating an HD Wallet from the Seed
@ -1077,7 +1066,7 @@ An extended public key can be used, therefore, to derive all of the
_public_ keys (and only the public keys) in that branch of the HD wallet
structure.
This shortcut can be used to create very secure public key-only
This shortcut can be used to create public key-only
deployments where a server or application has a copy of an extended
public key and no private keys whatsoever. That kind of deployment can
produce an infinite number of public keys and Bitcoin addresses, but
David A. Harding
8 months ago