3 | Third Edition
5 | 6 |Programming the Open Blockchain
7 | 8 | 9 |Dedicated to my mum, Theresa (1946–2017)
4 |She taught me to love books and question authority
5 |Thank you, mum
6 |—Andreas
7 |For Amanda
10 |It wasn't until I met you that I
11 |actually began living in paradise
12 | 13 | 14 |—Dave
15 |4 |9 |Mastering Bitcoin is very useful for anyone who wants or needs to understand the 5 | technology of Bitcoin and the concepts of the protocol. 6 |
7 |René Pickhardt, Bitcoin Lightning Network developer
8 |
10 |15 |Delve into the fascinating world of Bitcoin with Mastering Bitcoin, the definitive guide that navigates through the intricacies of this digital currency. Whether you're a developer, an investor, or simply curious about the future of money, this comprehensive book serves as your roadmap, providing essential knowledge and empowering you to participate confidently in the Internet of money era. 11 | 12 |
13 |Jorge Lesmes, Senior Director at NTT DATA
14 |
16 |19 |Nearly a decade after the initial publishing, the third edition of Mastering Bitcoin cements the book’s role as the go-to source of technical Bitcoin educational content. No other book is as comprehensive or up-to-date.
17 |Olaoluwa Osuntokun, CTO at Lightning Labs
18 |
20 |25 |A comprehensive overview of what goes on under Bitcoin’s hood and how things fit together. 21 | 22 |
23 |Mark "Murch" Erhardt, Bitcoin engineer, Chaincode Labs
24 |
The animal on the cover of Mastering Bitcoin is a leafcutter ant (Atta colombica). The leafcutter ant (a nongeneric name) is a tropical, fungus-growing ant endemic to South and Central America, Mexico, and southern United States. Aside from humans, leafcutter ants form the largest and most complex animal societies on the planet. They are named for the way they chew leaves, which serve as nutrition for their fungal garden.
6 | 7 |Winged ants, both male and female, take part in a mass exit of their nest known as the revoada, or a nuptial flight. Females mate with multiple males to collect the 300 million sperm necessary to set up a colony. Females also store bits of the parental fungus garden mycelium in the infrabuccal pocket located in their oral cavity; they will use this to start their own fungal gardens. Once grounded, the female loses her wings and sets up an underground lair for her colony. The success rate for new queens is low: 2.5% establish a long-lived colony.
8 | 9 |Once a colony has matured, ants are divided into castes based on size, with each caste performing various functions. There are usually four castes: minims, the smallest workers that tend to the young and fungus gardens; minors, slightly larger than minima, are the first line of defense for the colony and patrol the surrounding terrain and attack enemies; mediae, the general foragers that cut leaves and bring back leaf fragments to the nest; and majors, the largest worker ants that act as soldiers, defending the nest from intruders. Recent research has shown that majors also clear main foraging trails and carry bulky items back to the nest.
10 | 11 |Many of the animals on O'Reilly covers are endangered; all of them are important to the world. To learn more about how you can help, go to animals.oreilly.com.
12 | 13 |The cover illustration is by Karen Montgomery, based on an image from Insects Abroad. The cover fonts are Gilroy Semibold and Guardian Sans. The text font is Adobe Minion Pro; the heading font is Adobe Myriad Condensed; and the code font is Dalton Maag's Ubuntu Mono.
14 |Copyright © 2024 David Harding. All rights reserved.
7 | 8 |Printed in the United States of America.
9 | 10 |Published by O'Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472.
11 | 12 |O'Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (https://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com.
13 | 14 |See https://oreilly.com/catalog/errata.csp?isbn=9781098150099 for release details.
46 | 47 |The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Mastering Bitcoin, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc.
49 | 50 |While the publisher and the authors have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the authors disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
54 |978-1-098-15009-9
58 | 59 |[LSI]
60 |Abdussamad Abdurrazzaq (AbdussamadA)
Michael C. Ippolito (michaelcippolito)
Michael Newman (michaelbnewman)
Paul Desmond Parker (sunwukonga)
Reproducibility Matters (TheCharlatan)
Mastering Bitcoin: Programming the Open Blockchain (Third Edition) by Andreas M. Antonopoulos, David A. Harding is licensed under Creative Commons Attribution-ShareAlike 4.0 International License
130 | You can contact Andreas M. Antonopoulos on his personal site:
131 | https://antonopoulos.com.
38 |
39 | # Other Editions and Languages
40 |
41 | ## Mastering Bitcoin - First Edition
42 |
43 | The tags [Edition1Print1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print1), [Edition1Print2](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print2) correspond to the two existing prints of Mastering Bitcoin (First Edition) as published by O'Reilly Media.
44 |
45 | 
Mastering Bitcoin - First Edition by aantonop Books LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
46 |
47 | ## Mastering Bitcoin - Second Edition
48 |
49 | The tags, [second_edition_print_1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print_1) [second_edition_print2](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print2), [second_edition_print3](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print3), correspond to the first (June 8th, 2017), second (July 20th, 2017) and third (March 23rd, 2018) print of Mastering Bitcoin (Second Edition), as published by O'Reilly Media.
50 |
51 | 
Mastering Bitcoin - Second Edition by aantonop Books LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
52 |
53 | Mastering Bitcoin (Open Second Edition), based on the Seond Edition, is also available in English and Spanish at https://aantonop.com. Mastering Bitcoin 2nd Edition is also published in German, Polish, Japanese, Korean, Chinese and other languages by publishers in the respective countries.
54 |
55 | # Issues, Errors, Comments, Contributions
56 |
57 | To contribute to this book, see [CONTRIBUTING.md](CONTRIBUTING.md). All contributions must be your original work and contributed under a public domain (CC0), or attribution (CC-BY) license. You must include your own attribution in the pull request, as an edit to the github_contrib.asciidoc file.
58 |
59 | If you know how to make a pull request to contribute a fix, please write the correction and use a pull request to submit it for consideration against the [develop branch](https://github.com/bitcoinbook/bitcoinbook/tree/develop). If you are making several changes, please use a separate commit for each to make it easier to cherry-pick or resolve conflicts. Otherwise, please submit an issue, explaining the error or comment. If you would like to contribute extensive changes or new material, please coordinate with the author first; contact information can be found on his website: https://aantonop.com/
60 |
61 | # Translations
62 |
63 | If you are interested in translating this book, please join our team of volunteers at: https://www.transifex.com/bitcoinbook/mastering-bitcoin/
64 |
--------------------------------------------------------------------------------
/appc_bips.adoc:
--------------------------------------------------------------------------------
1 | [[appdxbitcoinimpproposals]]
2 | [appendix]
3 | == Bitcoin Improvement Proposals
4 |
5 | Bitcoin Improvement Proposals are design documents providing information to the Bitcoin community or describing a new feature for Bitcoin or its processes or environment.
6 |
7 | As per BIP1 _BIP Purpose and Guidelines_, there are three((("BIPs (Bitcoin Improvement Proposals)", "types of"))) kinds of BIPs:
8 |
9 | _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.
10 | _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.
11 | _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. 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.
12 |
13 | BIPs are recorded in a https://oreil.ly/jjO0R[versioned repository on GitHub].
14 | An MIT-licensed document from the open source Bitcoin Core project,
15 | reproduced here in edited form, describes which BIPs it implements, including listing
16 | the Pull Request (PR) and version of Bitcoin Core where support for each BIP was added or
17 | significantly changed.
18 |
19 | BIPs that are ((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin Core", id="bips-implement")))((("Bitcoin Core", "BIPs implemented by", id="bitcoin-core-bips")))implemented by Bitcoin Core:
20 |
21 | - BIP9: The changes allowing multiple soft forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575).
22 | - BIP11: Multisig outputs are standard since v0.6.0 (PR #669).
23 | - BIP13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669).
24 | - BIP14: The subversion string is being used as User Agent since v0.6.0 (PR #669).
25 | - BIP16: The pay-to-script-hash evaluation rules have been implemented since v0.6.0, and took effect on April 1st 2012 (PR #748).
26 | - BIP21: The URI format for Bitcoin payments has been implemented since v0.6.0 (PR #176).
27 | - BIP22: The 'getblocktemplate' (GBT) RPC protocol for mining has been implemented since v0.7.0 (PR #936).
28 | - BIP23: Some extensions to GBT have been implemented since v0.10.0rc1, including longpolling and block proposals (PR #1816).
29 | - BIP30: The evaluation rules to forbid creating new transactions with the same txid as previous not-fully-spent transactions were implemented since v0.6.0, and the rule took effect on March 15th 2012 (PR #915).
30 | - BIP31: The 'pong' protocol message (and the protocol version bump to 60001) has been implemented since v0.6.1 (PR #1081).
31 | - BIP32: Hierarchical Deterministic Wallets has been implemented since v0.13.0 (PR #8035).
32 | - BIP34: The rule that requires blocks to contain their height (number) in the coinbase input, and the introduction of version 2 blocks has been implemented since v0.7.0. The rule took effect for version 2 blocks as of block 224413 (March 5th 2013), and version 1 blocks are no longer allowed since block 227931 (March 25th 2013) (PR #1526).
33 | - BIP35: The 'mempool' protocol message (and the protocol version bump to 60002) has been implemented since v0.7.0 (PR #1641). As of v0.13.0, this is only available for +NODE_BLOOM+ (BIP111) peers.
34 |
35 | [role="less_space pagebreak-before"]
36 | - BIP37: The bloom filtering for transaction relaying, partial Merkle trees for blocks, and the protocol version bump to 70001 (enabling low-bandwidth lightweight clients) has been implemented since v0.8.0 (PR #1795). Disabled by default since v0.19.0, can be enabled by the +-peerbloomfilters+ option.
37 | - BIP42: The bug that would have caused the subsidy schedule to resume after block 13440000 was fixed in v0.9.2 (PR #3842).
38 | - BIP43: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP43 (PR #16528).
39 | - BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44 (PR #16528).
40 | - BIP49: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP49 (PR #16528).
41 | - BIP61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185). Starting v0.17.0, whether to send reject messages can be configured with the ++-enablebip61++ option, and support is deprecated (disabled by default) as of v0.18.0. Support was removed in v0.20.0 (PR #15437).
42 | - BIP65: The ++CHECKLOCKTIMEVERIFY++ soft fork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only +CLTV+ was added in PR #6124.
43 | - BIP66: The strict DER rules and associated version 3 blocks have been implemented since v0.10.0 (PR #5713).
44 | - BIP68: Sequence locks have been implemented as of v0.12.1 (PR #7184), and have been buried since v0.19.0 (PR #16060).
45 | - BIP70 71 72: Payment Protocol support has been available in Bitcoin Core GUI since v0.9.0 (PR #5216). Support can be optionally disabled at build time since v0.18.0 (PR 14451), and it is disabled by default at build time since v0.19.0 (PR #15584). It has been removed as of v0.20.0 (PR 17165).
46 | - BIP84: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP84. (PR #16528)
47 | - BIP86: Descriptor wallets by default use the Hierarchical Deterministic Wallet derivation proposed by BIP86 since v23.0 (PR #22364).
48 | - BIP90: Trigger mechanism for activation of BIPs 34, 65, and 66 has been simplified to block height checks since v0.14.0 (PR #8391).
49 | - BIP111: +NODE_BLOOM+ service bit added and enforced for all peer versions as of v0.13.0 (PR #6579 and PR #6641).
50 | - BIP112: The +CHECKSEQUENCEVERIFY+ opcode has been implemented since v0.12.1 (PR #7524), and has been buried since v0.19.0 (PR #16060).
51 | - BIP113: Median time past lock-time calculations have been implemented since v0.12.1 (PR #6566), and has been buried since v0.19.0 (PR #16060).
52 | - BIP125: Opt-in full replace-by-fee signaling partially implemented.
53 | - BIP130: direct headers announcement is negotiated with peer versions ≥70012 as of v0.12.0 (PR 6494).
54 | - BIP133: feefilter messages are respected and sent for peer versions ≥70013 as of v0.13.0 (PR 7542).
55 | - BIP141: Segregated Witness (Consensus Layer) as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060).
56 | - BIP143: Transaction Signature Verification for Version 0 Witness Program as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060).
57 | - BIP144: Segregated Witness as of 0.13.0 (PR 8149).
58 | - BIP145: getblocktemplate updates for Segregated Witness as of v0.13.0 (PR 8149).
59 | - BIP147: +NULLDUMMY+ soft fork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060).
60 | - BIP152: Compact block transfer and related optimizations are used as of v0.13.0 (PR 8068).
61 | - BIP155: The 'addrv2' and 'sendaddrv2' messages which enable relay of Tor V3 addresses (and other networks) are supported as of v0.21.0 (PR 19954).
62 | - BIP157 158: Compact Block Filters for Light Clients can be indexed as of v0.19.0 (PR #14121) and served to peers on the P2P network as of v0.21.0 (PR #16442).
63 | - BIP159: The +NODE_NETWORK_LIMITED+ service bit is signalled as of v0.16.0 (PR 11740), and such nodes are connected to as of v0.17.0 (PR 10387).
64 | - BIP173: Bech32 addresses for native Segregated Witness outputs are supported as of v0.16.0 (PR 11167). Bech32 addresses are generated by default as of v0.20.0 (PR 16884).
65 | - BIP174: RPCs to operate on Partially Signed Bitcoin Transactions (PSBT) are present as of v0.17.0 (PR 13557).
66 | - BIP176: Bits Denomination [QT only] is supported as of v0.16.0 (PR 12035).
67 | - BIP325: Signet test network is supported as of v0.21.0 (PR 18267).
68 | - BIP339: Relay of transactions by wtxid is supported as of v0.21.0 (PR 18044).
69 | - BIP340 341 342: Validation rules for Taproot (including Schnorr signatures and Tapscript leaves) are implemented as of v0.21.0 (PR 19953), with mainnet activation as of v0.21.1 (PR 21377, PR 21686).
70 | - BIP350: Addresses for native v1+ segregated Witness outputs use bech32m instead of bech32 as of v22.0 (PR 20861).
71 | - BIP371: Taproot fields for PSBT as of v24.0 (PR 22558).
72 | - BIP380 381 382 383 384 385: Output Script Descriptors, and most of Script Expressions are implemented as of v0.17.0 (PR 13697).
73 | - BIP386: +tr()+ Output Script Descriptors are implemented as((("BIPs (Bitcoin Improvement Proposals)", "implemented by Bitcoin Core", startref="bips-implement")))((("Bitcoin Core", "BIPs implemented by", startref="bitcoin-core-bips"))) of v22.0 (PR 22051).
74 |
--------------------------------------------------------------------------------
/appb_errata.adoc:
--------------------------------------------------------------------------------
1 | [appendix]
2 | == Errata to the Bitcoin Whitepaper
3 |
4 | This ((("Bitcoin whitepaper", "errata", id="bitcoin-whitepaper-errata")))((("whitepaper (Bitcoin)", "errata", id="whitepaper-errata")))appendix contains a description of known problems in Satoshi Nakamoto’s paper, "Bitcoin:
5 | A Peer-to-Peer Electronic Cash System," as well as notes on terminology
6 | changes and how Bitcoin's implementation differs from that described in
7 | the paper.
8 |
9 | This document was originally published by a coauthor of this book in
10 | 2016; it is reproduced here with updates. The names of
11 | sections in this errata correspond to the names of the
12 | sections in Nakamoto's original paper.
13 |
14 | === Abstract
15 |
16 | ____
17 | "The longest chain not only serves as proof of the sequence of events
18 | witnessed, but proof that it came from the largest pool of CPU power."
19 | ____
20 |
21 | * *Implementation detail:* If each link in the chain (called "blocks"
22 | in Bitcoin) was built using the same amount of _proof of work_ (PoW), the
23 | longest chain would be the one backed by the largest pool of
24 | computational power. However, Bitcoin was implemented in such a way that
25 | the amount of PoW can vary between blocks, so it became important not to
26 | check for the "the longest chain" but rather "the chain demonstrating
27 | the most PoW"; this is often shortened to "most-work chain."
28 | +
29 | The
30 | https://oreil.ly/XYZzx[change]
31 | from checking for the longest chain to checking for the most-work chain
32 | occurred in July 2010, long after Bitcoin’s initial release:
33 | +
34 | [source,diff]
35 | ----
36 | - if (pindexNew->nHeight > nBestHeight)
37 | + if (pindexNew->bnChainWork > bnBestChainWork)
38 | ----
39 |
40 | [role="less_space pagebreak-before"]
41 | * *Terminology change:* General CPUs were used to generate the PoW for
42 | the earliest Bitcoin blocks, but PoW generation today is mostly performed
43 | by specialist Application Specific Integrated Circuits (ASICs), so
44 | instead of saying "CPU power" it is perhaps more correct to say
45 | "computational power" or, simply, "hash rate" for the hashing used
46 | in generating the PoW.
47 |
48 | ____
49 | "As long as a majority of CPU power is controlled by nodes that are not
50 | cooperating to attack the network, they’ll generate the longest chain
51 | and outpace attackers."
52 | ____
53 |
54 | * *Terminology change:* The term "nodes" today is used to refer to
55 | full validation nodes, which are programs that enforce all the rules of
56 | the system. Programs (and hardware) that extend the chain today are
57 | called "miners" based on Nakamoto’s analogy to gold miners in section
58 | 6 of the paper. Nakamoto expected all miners to be nodes but the
59 | software he released did not require all nodes to be miners. In the
60 | original software, a simple menu item in the node GUI allowed toggling
61 | the mining function on or off.
62 | +
63 | Today it is the case that the overwhelming number of nodes are not
64 | miners and that many individuals who own mining hardware do not use it
65 | with their own nodes (and even those that do mine with their own nodes
66 | often mine for short periods of time on top of newly discovered blocks
67 | without ensuring their node considers the new block valid). The early
68 | parts of the paper where "nodes" is mostly used without modification
69 | refer to mining using a full validation node; the later parts of the
70 | paper which refer to "network nodes" is mainly about what nodes can do
71 | even if they aren’t mining.
72 | * *Post-publication discovery:* When a new block is produced, the miner
73 | who produces that block can begin working on its sequel immediately but
74 | all other miners are unaware of the new block and cannot begin working
75 | on it until it has propagated across the
76 | network to them. This gives miners who produce many blocks an edge over
77 | miners who produce fewer blocks, and this can be exploited in what’s
78 | known as the _selfish mining attack_ to allow an attacker with around
79 | 30% of total network hash rate to make other miners less profitable,
80 | perhaps driving them into following the attacking miner’s policy. So
81 | instead of saying "a majority of CPU power is controlled by nodes that
82 | are not cooperating to attack the network," it is perhaps more correct
83 | to say "as long as nodes cooperating to attack the network control less
84 | than about 30% of the network."
85 |
86 | === Transactions
87 |
88 | ____
89 | "We define((("transactions", "errata in Bitcoin whitepaper", id="transaction-errata"))) an electronic coin as a chain of digital signatures. Each
90 | owner transfers the coin to the next by digitally signing a hash of the
91 | previous transaction and the public key of the next owner and adding
92 | these to the end of the coin."
93 | ____
94 |
95 | * *Implementation detail:* Bitcoin implements a more general version of
96 | this system where digital signatures are not used directly but rather a
97 | "deterministic expression" is used instead. Just as a signature that
98 | matches a known public key can be used to enable a payment, the data
99 | that satisfies a known expression can also enable a payment.
100 | Generically, the expression that must be satisfied in Bitcoin in order
101 | to spend a coin is known as an "encumbrance." Almost all encumbrances
102 | in Bitcoin to date require providing at least one signature. So instead
103 | of saying "a chain of digital signatures," it is more correct to say
104 | "a chain of encumbrances." Given that transactions often have more
105 | than one input and more than one output, the structure is not very
106 | chain-like; it’s more accurately described as a directed acyclic ((("transactions", "errata in Bitcoin whitepaper", startref="transaction-errata")))graph
107 | (DAG).
108 |
109 | === Proof of Work
110 |
111 | ____
112 | "...we((("proof-of-work algorithm", "errata in Bitcoin whitepaper", id="proof-errata"))) implement the proof-of-work by incrementing a nonce in the block
113 | until a value is found that gives the block’s hash the required zero
114 | bits."
115 | ____
116 |
117 | * *Implementation detail:* Adam Back’s Hashcash implementation requires
118 | finding a hash with the required number of leading zero bits. Bitcoin
119 | treats the hash as an integer and requires that it be less than a
120 | specified integer, which effectively allows a fractional number of bits
121 | to be specified.
122 |
123 | ____
124 | "Proof-of-work is essentially one-CPU-one-vote."
125 | ____
126 |
127 | * *Important note:* The vote here is not on the rules of the system but
128 | merely on the ordering of the transactions in order to provide
129 | assurances that an "electronic coin" cannot be easily double spent.
130 | This is described in more detail in section 11 of the paper where it
131 | says, "We consider the scenario of an attacker trying to generate an
132 | alternate chain faster than the honest chain. Even if this is
133 | accomplished, it does not throw the system open to arbitrary changes,
134 | such as creating value out of thin air or taking money that never
135 | belonged to the attacker. Nodes are not going to accept an invalid
136 | transaction as payment, and honest nodes will never accept a block
137 | containing them."
138 |
139 | ____
140 | "...proof-of-work difficulty is determined by a moving average targeting an
141 | average number of blocks per hour."
142 | ____
143 |
144 | * *Implementation detail:* A moving average is not used. Instead, every
145 | 2,016th block has its reported generation time compared to the
146 | generation time for an earlier block, and the difference between them is
147 | used to calculate the average used for adjustment.
148 | +
149 | Further, the average implemented in Bitcoin targets an average number of
150 | blocks per two weeks (not per hour as might be implied by the text).
151 | Other implemented rules may further slow adjustments, such as a rule
152 | that the adjustment cannot increase block production speed by more than
153 | 300% per period, nor slow it by more ((("proof-of-work algorithm", "errata in Bitcoin whitepaper", startref="proof-errata")))than 75%.
154 |
155 | === Reclaiming Disk Space
156 |
157 | ____
158 | "Once the ((("disk space, reclaiming")))((("reclaiming disk space")))((("blocks", "reclaiming disk space")))latest transaction in a coin is buried under enough blocks, the
159 | spent transactions before it can be discarded to save disk space."
160 | ____
161 |
162 | * *Possible post-publication discovery:* Although the merkle tree
163 | structure described in this section can prove a transaction was included
164 | in a particular block, there is currently no way in Bitcoin to prove
165 | that a transaction has not been spent except to process all subsequent
166 | data in the blockchain. This means the method described here cannot be
167 | universally used for reclaiming disk space among all nodes, as all new
168 | nodes will need to process all transactions.
169 |
170 | === Simplified Payment Verification
171 |
172 | ____
173 | "One strategy((("payment verification", "errata in Bitcoin whitepaper")))((("verifying", "payment", "errata in Bitcoin whitepaper"))) to protect against this would be to accept alerts from
174 | network nodes when they detect an invalid block, prompting the user’s
175 | software to download the full block and alerted transactions to confirm
176 | the inconsistency."
177 | ____
178 |
179 | * *Important Note:* Although software has been produced that implements
180 | some parts of this section and calls that Simplified Payment
181 | Verification (SPV), none of these programs currently accepts alerts from
182 | network nodes (full validation nodes) when invalid blocks have been
183 | detected. This has placed bitcoins in so-called SPV wallets at risk in
184 | the past.
185 |
186 | === Privacy
187 |
188 | ____
189 | "Some linking((("privacy", "errata in Bitcoin whitepaper"))) is still unavoidable with multi-input transactions, which
190 | necessarily reveal that their inputs were owned by the same owner."
191 | ____
192 |
193 | * *Post-publication invention:* It isn't clear that different inputs
194 | in the same transaction have the same owner if owners often mix their
195 | inputs with
196 | inputs belonging to other owners. For example, there’s no public
197 | difference between Alice and Bob each contributing one of their inputs
198 | toward paying Charlie and Dan than there is between just Alice
199 | contributing two of her inputs toward paying Charlie and Dan.
200 | +
201 | This technique is known today as
202 | https://oreil.ly/UBEJX[CoinJoin], and software implementing
203 | it has been in use since 2015.
204 |
205 | === Calculations
206 |
207 | ____
208 | "The receiver ((("calculations", "errata in Bitcoin whitepaper")))generates a new key pair and gives the public key to the
209 | sender shortly before signing. This prevents the sender from preparing a
210 | chain of blocks ahead of time by working on it continuously until he is
211 | lucky enough to get far enough ahead, then executing the transaction at
212 | that moment."
213 | ____
214 |
215 | * *Post-publication discovery:* Nothing about the receiver generating a
216 | public key shortly before the spender signs a transaction prevents the
217 | spender from preparing a chain of blocks ahead of time. Early Bitcoin
218 | user Hal Finney discovered this attack and
219 | https://oreil.ly/kg_Xe[described
220 | it]: "Suppose the attacker is generating blocks occasionally. In each
221 | block he generates, he includes a transfer from address A to address B,
222 | both of which he controls.
223 | +
224 | "To cheat you, when he generates a block, he doesn’t broadcast it.
225 | Instead, he runs down to your store and makes a payment to your address
226 | C with his address A. You wait a few seconds, don’t hear anything, and
227 | transfer the goods. He broadcasts his block now, and his transaction
228 | will take precedence over yours."
229 | +
230 | The attack works for any number of confirmations, and is sometimes named
231 | the Finney Attack.
232 |
233 | '''''
234 |
235 | *Disclaimer:* The author of this document was not the first person to
236 | identify any of the problems described here—he has merely collected them
237 | into a single document.
238 |
239 | *License:* This errata document is released under the
240 | https://oreil.ly/xZeBR[CC0] 1.0 Universal
241 | Public Domain Dedication
242 |
243 | For updates made ((("Bitcoin whitepaper", "errata", startref="bitcoin-whitepaper-errata")))((("whitepaper (Bitcoin)", "errata", startref="whitepaper-errata")))after the publication of this book, please see the
244 | https://oreil.ly/ygExa[Original
245 | document].
246 |
--------------------------------------------------------------------------------
/glossary.asciidoc:
--------------------------------------------------------------------------------
1 | [preface]
2 | == Quick Glossary
3 |
4 | //FIXME:include this?
5 |
6 | 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.
7 |
8 | address::
9 | 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.
10 |
11 | bip::
12 | Bitcoin Improvement Proposals. A set of proposals that members of the bitcoin community have submitted to improve bitcoin. For example, BIP21 is a proposal to improve the bitcoin uniform resource identifier (URI) scheme.
13 |
14 | bitcoin::
15 | The name of the currency unit (the coin), the network, and the software.
16 |
17 | block::
18 | 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.
19 |
20 | blockchain::
21 | A list of validated blocks, each linking to its predecessor all the way to the genesis block.
22 |
23 | Byzantine Generals Problem::
24 | 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.
25 |
26 | coinbase::
27 | A special field used as the sole input for coinbase transactions. The coinbase allows claiming the block reward and provides up to 100 bytes for arbitrary data.
28 | Not to be confused with Coinbase transaction.
29 |
30 | coinbase transaction::
31 | The first transaction in a block. Always created by a miner, it includes a single coinbase.
32 | Not to be confused with Coinbase.
33 |
34 | cold storage::
35 | 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.
36 |
37 | colored coins::
38 | An open source Bitcoin 2.0 protocol that enables developers to create digital assets on top of bitcoin blockchain utilizing its functionalities beyond currency.
39 |
40 | confirmations::
41 | 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.
42 |
43 | consensus::
44 | When several nodes, usually most nodes on the network, all have the same blocks in their locally-validated best blockchain.
45 | Not to be confused with consensus rules.
46 |
47 | consensus rules::
48 | The block validation rules that full nodes follow to stay in consensus with other nodes.
49 | Not to be confused with consensus.
50 |
51 | difficulty::
52 | A network-wide setting that controls how much computation is required to produce a proof of work.
53 |
54 | difficulty retargeting::
55 | 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.
56 |
57 | difficulty target::
58 | A difficulty at which all the computation in the network will find blocks approximately every 10 minutes.
59 |
60 | double-spending::
61 | 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.
62 |
63 | ECDSA::
64 | 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.
65 |
66 | extra nonce::
67 | 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.
68 |
69 | fees::
70 | 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.
71 |
72 | fork::
73 | 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.
74 |
75 | genesis block::
76 | The first block in the blockchain, used to initialize the cryptocurrency.
77 |
78 | hard fork::
79 | 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.
80 | Not to be confused with fork, soft fork, software fork or Git fork.
81 |
82 | hardware wallet::
83 | A hardware wallet is a special type of bitcoin wallet which stores the user's private keys in a secure hardware device.
84 |
85 | //FIXME: needs improvement
86 | hash::
87 | A digital commitment to some binary input.
88 |
89 | hashlocks::
90 | 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.
91 |
92 | HD protocol::
93 | The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy.
94 |
95 | HD wallet::
96 | Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP32).
97 |
98 | HD wallet seed::
99 | 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.
100 |
101 | HTLC::
102 | 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.
103 |
104 | KYC::
105 | 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.
106 |
107 | LevelDB::
108 | 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.
109 |
110 | Lightning Networks::
111 | 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.
112 |
113 | Lock time::
114 | 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.
115 |
116 | mempool::
117 | 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.
118 |
119 | merkle root::
120 | 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.
121 |
122 | merkle tree::
123 | 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.
124 |
125 | miner::
126 | A network node that finds valid proof of work for new blocks, by repeated hashing.
127 |
128 | multisignature::
129 | Multisignature (multisig) refers to requiring more than one key to authorize a bitcoin transaction.
130 |
131 | network::
132 | A peer-to-peer network that propagates transactions and blocks to every Bitcoin node on the network.
133 |
134 | nonce::
135 | 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.
136 |
137 | offchain transactions::
138 | 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.
139 |
140 | opcode::
141 | Operation codes from the Bitcoin Script language which push data or perform functions within a pubkey script or signature script.
142 |
143 | OP_RETURN::
144 | An opcode used in one of the outputs in an OP_RETURN transaction. Not to be confused with OP_RETURN transaction.
145 |
146 | OP_RETURN transaction::
147 | 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.
148 |
149 | orphan block::
150 | 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.
151 |
152 | orphan transactions::
153 | Transactions that can't go into the pool due to one or more missing input transactions.
154 |
155 | output::
156 | 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.
157 |
158 | P2PKH::
159 | 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.
160 |
161 | P2SH::
162 | 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.
163 |
164 | P2SH address::
165 | P2SH addresses are Base58Check encodings of the 20-byte hash of a script, P2SH addresses 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.
166 |
167 | P2WPKH::
168 | 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 structure instead of the input script. The output script is also modified.
169 |
170 | P2WSH::
171 | The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is about the cryptographic proof location change from the input script to the witness structure and the output script that is also modified.
172 |
173 | paper wallet::
174 | 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.
175 |
176 | payment channels::
177 | 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.
178 |
179 | pooled mining::
180 | 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.
181 |
182 | Proof-of-Stake::
183 | 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).
184 |
185 | Proof-of-Work::
186 | 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.
187 |
188 | reward::
189 | An amount included in each new block as a reward by the network to the miner who found the Proof-of-Work solution. It is currently 12.5 BTC per block.
190 |
191 | RIPEMD-160::
192 | 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.
193 |
194 | satoshi::
195 | 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.
196 |
197 | Satoshi Nakamoto::
198 | 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.
199 |
200 | Script::
201 | 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.
202 |
203 | Output script::
204 | 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.
205 |
206 | Input script::
207 | The data generated by a spender which is almost always used as variables to satisfy an output script.
208 |
209 | secret key (aka private key)::
210 | The secret number that unlocks bitcoin sent to the corresponding address. pass:[A secret] key looks like the following:
211 | +
212 | ----
213 | 5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh
214 | ----
215 |
216 | Segregated Witness::
217 | Segregated Witness is a proposed upgrade to the Bitcoin protocol which technological innovation separates signature data from bitcoin transactions. Segregated Witness is a proposed soft fork; a change that technically makes Bitcoin’s protocol rules more restrictive.
218 |
219 | SHA::
220 | The Secure Hash Algorithm or SHA is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST).
221 |
222 | Simplified Payment Verification (SPV)::
223 | A method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
224 |
225 | soft fork::
226 | 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.
227 | Not to be confused with fork, hard fork, software fork or Git fork.
228 |
229 | stale block::
230 | 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.
231 |
232 | timelocks::
233 | 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.
234 |
235 | transaction::
236 | 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.
237 |
238 | transaction pool::
239 | An unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions.
240 |
241 | Turing completeness::
242 | A program language is called "Turing complete" if it can run any program that a Turing machine can run, given enough time and memory.
243 |
244 | unspent transaction output (UTXO)::
245 | UTXO is an unspent transaction output that can be spent as an input in a new transaction.
246 |
247 | wallet::
248 | Software that holds all your Bitcoin addresses and secret keys. Use it to send, receive, and store your bitcoin.
249 |
250 | Wallet Import Format (WIF)::
251 | 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.
252 |
253 | 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.
254 |
--------------------------------------------------------------------------------
/ch13_security.adoc:
--------------------------------------------------------------------------------
1 | [[ch11]]
2 | == Bitcoin Security
3 |
4 | Securing your bitcoins is challenging because bitcoins are
5 | are not like a balance in a bank account. Your bitcoins are very
6 | much like digital cash or gold. You've probably heard the expression,
7 | "Possession is nine-tenths of the law." Well, in Bitcoin, possession is
8 | ten-tenths of the law. Possession of the keys to spend certain bitcoins is
9 | equivalent to possession of cash or a chunk of precious metal. You can
10 | lose it, misplace it, have it stolen, or accidentally give the wrong
11 | amount to someone. In every one of these cases, users have no recourse
12 | within the protocol, just as if they dropped cash on a public sidewalk.
13 |
14 | However, the Bitcoin system has capabilities that cash, gold, and bank accounts do
15 | not. A Bitcoin wallet, containing your keys, can be backed up like any
16 | file. It can be stored in multiple copies, even printed on paper for
17 | hard-copy backup. You can't "back up" cash, gold, or bank accounts.
18 | Bitcoin is different enough from anything that has come before that we
19 | need to think about securing our bitcoins in a novel way too.
20 |
21 | === Security Principles
22 |
23 | The ((("Bitcoin", "security", "principles of", id="bitcoin-security-principle")))((("security", "principles of", id="security-principle")))((("decentralized consensus", "as security principle", secondary-sortas="security principle", id="decentral-consensus-principle")))core principle in Bitcoin is
24 | decentralization and it has important implications for security. A
25 | centralized model, such as a traditional bank or payment network,
26 | depends on access control and vetting to keep bad actors out of the
27 | system. By comparison, a decentralized system like Bitcoin pushes the
28 | responsibility and control to the users. Because the security of the network
29 | is based on independent verification, the network can be open
30 | and no encryption is required for Bitcoin traffic (although encryption
31 | can still be useful).
32 |
33 | On a traditional payment network, such as a credit card system, the
34 | payment is open-ended because it contains the user's private identifier
35 | (the credit card number). After the initial charge, anyone with access
36 | to the identifier can "pull" funds and charge the owner again and again.
37 | Thus, the payment network has to be secured end-to-end with encryption
38 | and must ensure that no eavesdroppers or intermediaries can compromise
39 | the payment traffic in transit or when it is stored (at rest). If a bad
40 | actor gains access to the system, he can compromise current transactions
41 | _and_ payment tokens that can be used to create new transactions. Worse,
42 | when customer data is compromised, the customers are exposed to identity
43 | theft and must take action to prevent fraudulent use of the compromised
44 | accounts.
45 |
46 | Bitcoin is dramatically different. A Bitcoin transaction authorizes only
47 | a specific value to a specific recipient and cannot be forged.
48 | It does not reveal any private information, such as the
49 | identities of the parties, and cannot be used to authorize additional
50 | payments. Therefore, a Bitcoin payment network does not need to be
51 | encrypted or protected from eavesdropping. In fact, you can broadcast
52 | Bitcoin transactions over an open public channel, such as unsecured WiFi
53 | or Bluetooth, with no loss of security.
54 |
55 | Bitcoin's decentralized security model puts a lot of power in the hands
56 | of the users. With that power comes responsibility for maintaining the
57 | secrecy of their keys. For most users that is not easy to do, especially
58 | on general-purpose computing devices such as internet-connected
59 | smartphones or laptops. Although Bitcoin's decentralized model prevents
60 | the type of mass compromise seen with credit cards, many users are not
61 | able to adequately secure their keys and get hacked, one by one.
62 |
63 | ==== Developing Bitcoin Systems Securely
64 |
65 | A critical principle
66 | for Bitcoin developers is decentralization. Most developers will be
67 | familiar with centralized security models and might be tempted to apply
68 | these models to their Bitcoin applications, with disastrous results.
69 |
70 | Bitcoin's security relies on decentralized control over keys and on
71 | independent transaction validation by users. If you want to leverage
72 | Bitcoin's security, you need to ensure that you remain within the
73 | Bitcoin security model. In simple terms: don't take control of keys away
74 | from users and don't outsource validation.
75 |
76 | For example, many early Bitcoin exchanges concentrated all user funds in
77 | a single "hot" wallet with keys stored on a single server. Such a design
78 | removes control from users and centralizes control over keys in a single
79 | system. Many such systems have been hacked, with disastrous consequences
80 | for their customers.
81 |
82 | Unless you are prepared to invest heavily in operational security,
83 | multiple layers of access control, and audits (as the traditional banks
84 | do), you should think very carefully before taking funds outside of
85 | Bitcoin's decentralized security context. Even if you have the funds and
86 | discipline to implement a robust security model, such a design merely
87 | replicates the fragile model of traditional financial networks, plagued
88 | by identity theft, corruption, and embezzlement. To take advantage of
89 | Bitcoin's unique decentralized security model, you have to avoid the
90 | temptation of centralized architectures that might feel familiar but
91 | ultimately subvert Bitcoin's ((("decentralized consensus", "as security principle", secondary-sortas="security principle", startref="decentral-consensus-principle")))security.
92 |
93 | ==== The Root of Trust
94 |
95 | Traditional ((("root of trust", id="root-trust")))security architecture is based
96 | upon a concept called the _root of trust_, which is a trusted core used
97 | as the foundation for the security of the overall system or application.
98 | Security architecture is developed around the root of trust as a series
99 | of concentric circles, like layers in an onion, extending trust outward
100 | from the center. Each layer builds upon the more-trusted inner layer
101 | using access controls, digital signatures, encryption, and other
102 | security primitives. As software systems become more complex, they are
103 | more likely to contain bugs, which make them vulnerable to security
104 | compromise. As a result, the more complex a software system becomes, the
105 | harder it is to secure. The root of trust concept ensures that most of
106 | the trust is placed within the least complex part of the system, and
107 | therefore the least vulnerable parts of the system, while more complex
108 | software is layered around it. This security architecture is repeated at
109 | different scales, first establishing a root of trust within the hardware
110 | of a single system, then extending that root of trust through the
111 | operating system to higher-level system services, and finally across
112 | many servers layered in concentric circles of diminishing trust.
113 |
114 | Bitcoin security
115 | architecture is different. In Bitcoin, the consensus system creates a
116 | trusted blockchain that is completely decentralized. A correctly
117 | validated blockchain uses the genesis block as the root of trust,
118 | building a chain of trust up to the current block. Bitcoin systems can
119 | and should use the blockchain as their root of trust. When designing a
120 | complex Bitcoin application that consists of services on many different
121 | systems, you should carefully examine the security architecture in order
122 | to ascertain where trust is being placed. Ultimately, the only thing
123 | that should be explicitly trusted is a fully validated blockchain. If
124 | your application explicitly or implicitly vests trust in anything but
125 | the blockchain, that should be a source of concern because it introduces
126 | vulnerability. A good method to evaluate the security architecture of
127 | your application is to consider each individual component and evaluate a
128 | hypothetical scenario where that component is completely compromised and
129 | under the control of a malicious actor. Take each component of your
130 | application, in turn, and assess the impacts on the overall security if
131 | that component is compromised. If your application is no longer secure
132 | when components are compromised, that shows you have misplaced trust in
133 | those components. A Bitcoin application without vulnerabilities should
134 | be vulnerable only to a compromise of the Bitcoin consensus mechanism,
135 | meaning that its root of trust is based on the strongest part of the
136 | Bitcoin security architecture.
137 |
138 | The numerous examples of hacked Bitcoin exchanges serve to underscore
139 | this point because their security architecture and design fails even
140 | under the most casual scrutiny. These centralized implementations had
141 | invested trust explicitly in numerous components outside the Bitcoin
142 | blockchain, such as hot wallets, centralized databases,
143 | vulnerable encryption keys, and ((("Bitcoin", "security", "principles of", startref="bitcoin-security-principle")))((("security", "principles of", startref="security-principle")))((("root of trust", startref="root-trust")))similar schemes.
144 |
145 | === User Security Best Practices
146 |
147 | Humans ((("Bitcoin", "security", "best practices", id="bitcoin-security-best-practice")))((("security", "best practices", id="security-best-practice")))((("best practices, security", id="best-practice-security")))have
148 | used physical security controls for thousands of years. By comparison,
149 | our experience with digital security is less than 50 years old. Modern
150 | general-purpose operating systems are not very secure and not
151 | particularly suited to storing digital money. Our computers are
152 | constantly exposed to external threats via always-on internet
153 | connections. They run thousands of software components from hundreds of
154 | authors, often with unconstrained access to the user's files. A single
155 | piece of rogue software, among the many thousands installed on your
156 | computer, can compromise your keyboard and files, stealing any bitcoins
157 | stored in wallet applications. The level of computer maintenance
158 | required to keep a computer virus-free and trojan-free is beyond the
159 | skill level of all but a tiny minority of computer users.
160 |
161 | Despite decades of research and advancements in information security,
162 | digital assets are still woefully vulnerable to a determined adversary.
163 | Even the most highly protected and restricted systems, in financial
164 | services companies, intelligence agencies, and defense contractors, are
165 | frequently breached. Bitcoin creates digital assets that have intrinsic
166 | value and can be stolen and diverted to new owners instantly and
167 | irrevocably. This creates a massive incentive for hackers. Until now,
168 | hackers had to convert identity information or account tokens—such as
169 | credit cards and bank accounts—into value after compromising them.
170 | Despite the difficulty of fencing and laundering financial information,
171 | we have seen ever-escalating thefts. Bitcoin escalates this problem
172 | because it doesn't need to be fenced or laundered; bitcoins are valuable
173 | by themselves.
174 |
175 | Bitcoin also creates the incentives to improve computer
176 | security. Whereas previously the risk of computer compromise was vague
177 | and indirect, Bitcoin makes these risks clear and obvious. Holding
178 | bitcoins on a computer serves to focus the user's mind on the need for
179 | improved computer security. As a direct result of the proliferation and
180 | increased adoption of Bitcoin and other digital currencies, we have seen
181 | an escalation in both hacking techniques and security solutions. In
182 | simple terms, hackers now have a very juicy target and users have a
183 | clear incentive to defend themselves.
184 |
185 | Over the past three years, as a direct result of Bitcoin adoption, we
186 | have seen tremendous innovation in the realm of information security in
187 | the form of hardware encryption, key storage and hardware signing devices,
188 | multisignature technology, and digital escrow. In the following sections
189 | we will examine various best practices for practical user security.
190 |
191 | ==== Physical Bitcoin Storage
192 |
193 | Because most ((("bitcoins", "physical storage")))((("physical bitcoin storage")))((("storing bitcoins", id="storing-bitcoin")))users are far more
194 | comfortable with physical security than information security, a very
195 | effective method for protecting bitcoins is to convert them into physical
196 | form. Bitcoin keys, and the seeds used to create them, are nothing more than long numbers. This means that
197 | they can be stored in a physical form, such as printed on paper or
198 | etched on a metal plate. Securing the keys then becomes as simple as
199 | physically securing a printed copy of the key seed. A seed
200 | that is printed on paper is called a "paper backup," and
201 | many wallets can create them.
202 | Keeping bitcoins
203 | offline is ((("cold storage")))called _cold storage_ and it is one of the most effective
204 | security techniques. A cold storage system is one where the keys are
205 | generated on an offline system (one never connected to the internet) and
206 | stored offline either on paper or on digital media, such as a USB memory
207 | stick.
208 |
209 | ==== Hardware Signing Devices
210 |
211 | In the ((("hardware signing devices")))long term, Bitcoin security may increasingly take the
212 | form of tamper-proof hardware signing devices. Unlike a smartphone or desktop
213 | computer, a Bitcoin hardware signing device only needs to hold keys and
214 | use them to generate signatures. Without general-purpose software to
215 | compromise and
216 | with limited interfaces, hardware signing devices can deliver strong
217 | security to nonexpert users. Hardware
218 | signing devices may become the predominant method of storing bitcoins.
219 |
220 | ==== Ensuring Your Access
221 |
222 | Although
223 | most users ((("backing up", "importance of")))are rightly concerned about theft of their bitcoins, there is an even
224 | bigger risk. Data files get lost all the time. If they contain Bitcoin keys,
225 | the loss is much more painful. In the effort to secure their Bitcoin
226 | wallets, users must be very careful not to go too far and end up losing
227 | their bitcoins. In July 2011, a well-known Bitcoin awareness and education
228 | project lost almost 7,000 bitcoin. In their effort to prevent theft, the
229 | owners had implemented a complex series of encrypted backups. In the end
230 | they accidentally lost the encryption keys, making the backups worthless
231 | and losing a fortune. Like hiding money by burying it in the desert, if
232 | you secure your bitcoins too well you might not be able to find them again.
233 |
234 | [WARNING]
235 | ====
236 | To spend bitcoins, you may((("wallets", "recovery codes")))((("recovery codes"))) need to back up more than just your private
237 | keys or the BIP32 seed used to derive them. This is especially the case
238 | when multisignatures or complex scripts are being used. Most output
239 | scripts commit to the actual conditions that must be fulfilled to spend
240 | the bitcoins in that output, and it's not possible to fulfill that
241 | commitment unless your wallet software can reveal those conditions to
242 | the network. Wallet recovery codes must include this information. For
243 | more details, see <
100 |
109 | ++++
110 |
111 | We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at link:$$https://oreil.ly/MasteringBitcoin3e$$[].
112 |
113 | ++++
114 |
115 | ++++
116 |
117 | For news and information about our books and courses, visit link:$$https://oreilly.com$$[].
118 |
119 | Find us on LinkedIn: link:$$https://linkedin.com/company/oreilly-media$$[].
120 |
121 | Follow us on Twitter: link:$$https://twitter.com/oreillymedia$$[].
122 |
123 | Watch us on YouTube: link:$$https://youtube.com/oreillymedia$$[].
124 |
125 |
126 | === Contacting the Authors
127 |
128 | ++++
129 |