diff --git a/.gitattributes b/.gitattributes
deleted file mode 100644
index 09e2d14d..00000000
--- a/.gitattributes
+++ /dev/null
@@ -1 +0,0 @@
-*.asciidoc linguist-detectable
diff --git a/.gitignore b/.gitignore
index 440ef0e6..cd4b7c95 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ code/python-env
.debris
_build/
dist/
+_build/
diff --git a/README.md b/README.md
index a18687d4..a6a061fb 100644
--- a/README.md
+++ b/README.md
@@ -4,34 +4,25 @@ Code Examples: ![travis_ci](https://travis-ci.org/bitcoinbook/bitcoinbook.svg?br
Mastering Bitcoin is a book for developers, although the first two chapters cover bitcoin at a level that is also approachable to non-programmers. Anyone with a basic understanding of technology can read the first two chapters to get a great understanding of bitcoin.
-This repository contains the complete [first edition, second print](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print2), published in December 2014, and the complete [second edition, third print](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print3_rc1), published in March 2018, as published by O'Reilly Media in paperback and ebook formats.
+This repository contains the complete [first edition, second print](https://github.com/bitcoinbook/bitcoinbook/releases/tag/Edition1Print2), published in December 2014, and the complete [second edition, second print](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print2), published in July 2017, as published by O'Reilly Media in paperback and ebook formats.
# Issues, Errors, Comments, Contributions
-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://antonopoulos.com/
+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 web site: https://antonopoulos.com/
-# Reading this book
+# Reading this book (Where is the PDF?)
-To read this book, see [book.asciidoc](https://github.com/bitcoinbook/bitcoinbook/blob/develop/book.asciidoc). Click on each of the chapters to read in your browser. Other parties may choose to release PDFs of the book online.
+To read this book, see [book.asciidoc](https://github.com/bitcoinbook/bitcoinbook/blob/develop/book.asciidoc). Click on each of the chapters to read in your browser. This is not as convenient as reading a PDF or an ebook on your e-reader, for which there is a cost (see below).
-## Chapters
+The 2nd edition of "Mastering Bitcoin" is available under a CC-BY-NC-ND license, not a CC-BY-SA license.
-+ Chapter 1: '[Introduction](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch01.asciidoc)'
-+ Chapter 2: '[How Bitcoin Works](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch02.asciidoc)'
-+ Chapter 3: '[Bitcoin Core: The Reference Implementation](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch03.asciidoc)'
-+ Chapter 4: '[Keys, Addresses](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch04.asciidoc)'
-+ Chapter 5: '[Wallets](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch05.asciidoc)'
-+ Chapter 6: '[Transactions](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06.asciidoc)'
-+ Chapter 7: '[Advanced Transactions and Scripting](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc)'
-+ Chapter 8: '[The Bitcoin Network](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidoc)'
-+ Chapter 9: '[The Blockchain](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch09.asciidoc)'
-+ Chapter 10: '[Mining and Consensus](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch10.asciidoc)'
-+ Chapter 11: '[Bitcoin Security](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch11.asciidoc)'
-+ Chapter 12: '[Blockchain Applications](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch12.asciidoc)'
+It is deliberately not available as a PDF. Why? Because a PDF is a "derivative" product, which is what the ND prohibits. That's because the publisher (O'Reilly Media) is a for-profit publisher who puts considerable resources behind distributing the book. The book will eventually (within a year of publication) be released under a CC-BY-SA license, at which point the PDF format and translations will be allowed. Until then, making PDF copies violates the license and interferes with the publisher's (and the author's) ability to make a living. Furthermore, if you make it so the publisher can't recoup their investment, they will delay the release into CC-BY-SA.
+
+Please don't create or distribute PDFs until the license is changed to CC-BY-SA. It is rare for a publisher to even agree to a CC-BY-NC-ND license. Don't make it harder for free culture by violating even that, already generous, license.
# Published
-"Mastering Bitcoin (Second Edition, Second Print): Programming the Open Blockchain" is now available in paperback and ebook formats by many booksellers worldwide:
+"Mastering Bitcoin (Second Edition, Second Print): Programming the Open Blockchain" is now available in paperback and ebook formats by many book sellers worldwide:
* [Amazon](https://www.amazon.com/Mastering-Bitcoin-Programming-Open-Blockchain/dp/1491954388)
@@ -47,7 +38,7 @@ The book's source code, found in this repository, is kept synchronized with the
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.
-
Mastering Bitcoin - First Edition by Andreas M. Antonopoulos LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
+
Mastering Bitcoin - First Edition by Andreas M. Antonopoulos LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
This "Free Culture" compliant license was approved by my publisher O'Reilly Media (http://oreilly.com), who understands the value of open source. O'Reilly Media is not just the world's best publisher of technical books, but is also a strong supporter of this open culture and the sharing of knowledge.
@@ -55,12 +46,14 @@ Thank you O'Reilly Media!
## Mastering Bitcoin - Second Edition
-The tags, [second_edition_print_1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print_1) and [second_edition_print2](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print2), correspond to the first (June 8th, 2017) and second (July 20th, 2017) print of Mastering Bitcoin (Second Edition), as published by O'Reilly Media.
+The tags, [second_edition_print_1](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print_1) and [second_edition_print2](https://github.com/bitcoinbook/bitcoinbook/releases/tag/second_edition_print2), correspond to the first (June 8th 2017) and second (July 20th 2017) print of Mastering Bitcoin (Second Edition), as published by O'Reilly Media.
+
+
Mastering Bitcoin - Second Edition by Andreas M. Antonopoulos LLC is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.
-
Mastering Bitcoin - Second Edition by Andreas M. Antonopoulos LLC is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
+It is expected that the second edition will be released under a CC-BY-SA license within a year of publication.
# Translations
-If you are interested in translating this book, please join our team of volunteers at: https://www.transifex.com/aantonop/mastering-bitcoin
+If you are interested in translating this book, please join our team of volunteers at: https://www.transifex.com/bitcoinbook/mastering-bitcoin/
Free copies of "Mastering Bitcoin Open Edition," translated in many languages, can be downloaded from: https://bitcoinbook.info
diff --git a/appdx-bips.asciidoc b/appdx-bips.asciidoc
index c6021c97..969b63d9 100644
--- a/appdx-bips.asciidoc
+++ b/appdx-bips.asciidoc
@@ -43,6 +43,7 @@ _Process_ BIP:: Describes a bitcoin process, or proposes a change to (or an even
|[[bip-35]]https://github.com/bitcoin/bips/blob/master/bip-0035.mediawiki[BIP-35] |mempool message |Jeff Garzik |Standard |Final
|[[bip-36]]https://github.com/bitcoin/bips/blob/master/bip-0036.mediawiki[BIP-36] |Custom Services |Stefan Thomas |Standard |Draft
|[[bip-37]]https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki[BIP-37] |Connection Bloom filtering |Mike Hearn, Matt Corallo |Standard |Final
+|[[bip-38]]https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki[BIP-38] |Passphrase-protected private key |Mike Caldwell, Aaron Voisine |Standard |Draft
|[[bip-39]]https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki[BIP-39] |Mnemonic code for generating deterministic keys |Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe |Standard |Proposed
|[[bip-40]]https://github.com/bitcoin/bips/blob/master/bip-0040.mediawiki[BIP-40] |Stratum wire protocol |Marek Palatinus |Standard |BIP number allocated
|[[bip-41]]https://github.com/bitcoin/bips/blob/master/bip-0041.mediawiki[BIP-41] |Stratum mining protocol |Marek Palatinus |Standard |BIP number allocated
diff --git a/appdx-bitcoinwhitepaper.asciidoc b/appdx-bitcoinwhitepaper.asciidoc
index 3c9e1938..464ad9a4 100644
--- a/appdx-bitcoinwhitepaper.asciidoc
+++ b/appdx-bitcoinwhitepaper.asciidoc
@@ -75,7 +75,7 @@ The incentive may help encourage nodes to stay honest. If a greedy attacker is a
image::images/mbc2_abin04.png["disk"]
-A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, +80 bytes * 6 * 24 * 365 = 4.2MB+ per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
+A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, +80 bytes * 6 * 24 * 365 == 4.2MB+ per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
==== Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
@@ -107,11 +107,11 @@ The race between the honest chain and an attacker chain can be characterized as
The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:
++++ -p = probability an honest node finds the next block +p == probability an honest node finds the next block -q = probability the attacker finds the next block +q == probability the attacker finds the next block -q~z~ = probability the attacker will ever catch up from z blocks behind +q~z~ == probability the attacker will ever catch up from z blocks behind image::images/mbc2_abin08.png["eq1"] @@ -140,16 +140,16 @@ Converting to C code... #includeBOOLOR
], and +NOT+.
At first glance, you may find the bitcoin's flow control scripts confusing. That is because Bitcoin Script is a stack language. The same way that +1 {plus} 1+ looks "backward" when expressed as +1 1 ADD+, flow control clauses in bitcoin also look "backward."
@@ -468,7 +464,7 @@ When reading Bitcoin Script, remember that the condition being evaluated comes _
((("guard clauses")))Unlike an +IF+ clause, which offers alternative execution paths, the +VERIFY+ suffix acts as a _guard clause_, continuing only if a precondition is met.
-For example, the following script requires Bob's signature and a pre-image (secret) that produces a specific hash. Both conditions must be satisfied to unlock it:
+For example, the following script requires Bob's signature and a pre-image (secret) that produces a specific hash. Both conditions must be satisfied to unlock:
.A redeem script with an +EQUALVERIFY+ guard clause.
----
@@ -608,7 +604,7 @@ The second execution path can only be used after 30 days have elapsed from the c
.Unlocking script for the second execution path (Lawyer + 1-of-3)
----
-0 Transaction A fee: 28,590 satoshi
-Transaction B fee: 20,760 satoshi
+Transaction A fee: 25,710 satoshi
+Transaction B fee: 18,990 satoshi
Transaction A fee: 12,255 satoshi
-Transaction B fee: 10,425 satoshi
+Transaction A fee: 8,130 satoshi
+Transaction B fee: 12,045 satoshi
/Satoshi:0.9.2.1/
])
+BestHeight+:: The block height of this node's blockchain
-(See https://bit.ly/1qlsC7w[GitHub] for an example of the +version+ network message.)
+(See http://bit.ly/1qlsC7w[GitHub] for an example of the +version+ network message.)
-The +version+ message is always the first message sent by any peer to another peer. The local peer receiving a +version+ message will examine the remote peer's reported +nVersion+ and decide if the remote peer is compatible. If the remote peer is compatible, the local peer will acknowledge the +version+ message and establish a connection by sending a +verack+ message.
+The +version+ message is always the first message sent by any peer to another peer. The local peer receiving a +version+ message will examine the remote peer's reported +nVersion+ and decide if the remote peer is compatible. If the remote peer is compatible, the local peer will acknowledge the +version+ message and establish a connection by sending a +verack+.
-How does a new node find peers? The first method is to query DNS using a number of "DNS seeds," which are DNS servers that provide a list of IP addresses of Bitcoin nodes. Some of those DNS seeds provide a static list of IP addresses of stable bitcoin listening nodes. Some of the DNS seeds are custom implementations of BIND (Berkeley Internet Name Daemon) that return a random subset from a list of Bitcoin node addresses collected by a crawler or a long-running Bitcoin node. The Bitcoin Core client contains the names of nine different DNS seeds. The diversity of ownership and diversity of implementation of the different DNS seeds offers a high level of reliability for the initial bootstrapping process. In the Bitcoin Core client, the option to use the DNS seeds is controlled by the option switch +-dnsseed+ (set to 1 by default, to use the DNS seed).
+How does a new node find peers? The first method is to query DNS using a number of "DNS seeds," which are DNS servers that provide a list of IP addresses of Bitcoin nodes. Some of those DNS seeds provide a static list of IP addresses of stable Bitcoin listening nodes. Some of the DNS seeds are custom implementations of BIND (Berkeley Internet Name Daemon) that return a random subset from a list of Bitcoin node addresses collected by a crawler or a long-running bitcoin node. The Bitcoin Core client contains the names of five different DNS seeds. The diversity of ownership and diversity of implementation of the different DNS seeds offers a high level of reliability for the initial bootstrapping process. In the Bitcoin Core client, the option to use the DNS seeds is controlled by the option switch +-dnsseed+ (set to 1 by default, to use the DNS seed).
Alternatively, a bootstrapping node that knows nothing of the network must be given the IP address of at least one Bitcoin node, after which it can establish connections through further introductions. The command-line argument +-seednode+ can be used to connect to one node just for introductions using it as a seed. After the initial seed node is used to form introductions, the client will disconnect from it and use the newly discovered peers.
@@ -91,7 +93,7 @@ Once one or more connections are established, the new node will send an +addr+ m
.Address propagation and discovery
image::images/mbc2_0805.png["AddressPropagation"]
-A node must connect to a few different peers in order to establish diverse paths into the Bitcoin network. Paths are not persistent—nodes come and go—and so the node must continue to discover new nodes as it loses old connections as well as assist other nodes when they bootstrap. Only one connection is needed to bootstrap, because the first node can offer introductions to its peer nodes and those peers can offer further introductions. It's also unnecessary and wasteful of network resources to connect to more than a handful of nodes. After bootstrapping, a node will remember its most recent successful peer connections, so that if it is rebooted it can quickly reestablish connections with its former peer network. If none of the former peers respond to its connection request, the node can use the seed nodes to bootstrap again.
+A node must connect to a few different peers in order to establish diverse paths into the Bitcoin network. Paths are not reliable—nodes come and go—and so the node must continue to discover new nodes as it loses old connections as well as assist other nodes when they bootstrap. Only one connection is needed to bootstrap, because the first node can offer introductions to its peer nodes and those peers can offer further introductions. It's also unnecessary and wasteful of network resources to connect to more than a handful of nodes. After bootstrapping, a node will remember its most recent successful peer connections, so that if it is rebooted it can quickly reestablish connections with its former peer network. If none of the former peers respond to its connection request, the node can use the seed nodes to bootstrap again.
On a node running the Bitcoin Core client, you can list the peer connections with the command +getpeerinfo+:
@@ -171,7 +173,7 @@ image::images/mbc2_0806.png["InventorySynchronization"]
[[spv_nodes]]
=== Simplified Payment Verification (SPV) Nodes
-((("Bitcoin network", "SPV nodes", id="BNspvnodes08")))((("Bitcoin nodes", "SPV nodes", id="BNospv08")))((("simplified-payment-verification (SPV)", id="simple08")))Not all nodes have the ability to store the full blockchain. Many Bitcoin clients are designed to run on space- and power-constrained devices, such as smartphones, tablets, or embedded systems. For such devices, a _simplified payment verification_ (SPV) method is used to allow them to operate without storing the full blockchain. These types of clients are called SPV clients or lightweight clients. As bitcoin adoption surges, the SPV node is becoming the most common form of Bitcoin node, especially for bitcoin wallets.
+((("bitcoin network", "SPV nodes", id="BNspvnodes08")))((("bitcoin nodes", "SPV nodes", id="BNospv08")))((("simple-payment-verification (SPV)", id="simple08")))Not all nodes have the ability to store the full blockchain. Many Bitcoin clients are designed to run on space- and power-constrained devices, such as smartphones, tablets, or embedded systems. For such devices, a _simplified payment verification_ (SPV) method is used to allow them to operate without storing the full blockchain. These types of clients are called SPV clients or lightweight clients. As Bitcoin adoption surges, the SPV node is becoming the most common form of Bitcoin node, especially for Bitcoin wallets.
SPV nodes download only the block headers and do not download the transactions included in each block. The resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain. SPV nodes cannot construct a full picture of all the UTXOs that are available for spending because they do not know about all the transactions on the network. SPV nodes verify transactions using a slightly different method that relies on peers to provide partial views of relevant parts of the blockchain on demand.
@@ -203,7 +205,7 @@ Shortly after the introduction of SPV/lightweight nodes, bitcoin developers adde
[[bloom_filters]]
=== Bloom Filters
-((("Bitcoin network", "bloom filters", id="BNebloom08")))((("bloom filters", id="bloom08")))((("privacy, maintaining", id="privacy08")))((("security", "maintaining privacy", id="Sprivacy08")))A bloom filter is a probabilistic search filter that offers an efficient way to express a search pattern while protecting privacy. They are used by SPV nodes to ask their peers for transactions matching a specific pattern, without revealing exactly which addresses, keys, or transactions they are searching for.
+((("bitcoin network", "bloom filters", id="BNebloom08")))((("bloom filters", id="bloom08")))((("privacy, maintaining", id="privacy08")))((("security", "maintaining privacy", id="Sprivacy08")))A bloom filter is a probabilistic search filter, a way to describe a desired pattern without specifying it exactly. Bloom filters offer an efficient way to express a search pattern while protecting privacy. They are used by SPV nodes to ask their peers for transactions matching a specific pattern, without revealing exactly which addresses, keys, or transactions they are searching for.
In our previous analogy, a tourist without a map is asking for directions to a specific address, "23 Church St." If she asks strangers for directions to this street, she inadvertently reveals her destination. A bloom filter is like asking, "Are there any streets in this neighborhood whose name ends in R-C-H?" A question like that reveals slightly less about the desired destination than asking for "23 Church St." Using this technique, a tourist could specify the desired address in more detail such as "ending in U-R-C-H" or less detail as "ending in H." By varying the precision of the search, the tourist reveals more or less information, at the expense of getting more or less specific results. If she asks a less specific pattern, she gets a lot more possible addresses and better privacy, but many of the results are irrelevant. If she asks for a very specific pattern, she gets fewer results but loses privacy.
@@ -268,7 +270,7 @@ Bloom filters are used to filter the transactions (and blocks containing them) t
By checking against all these components, bloom filters can be used to match public key hashes, scripts, +OP_RETURN+ values, public keys in signatures, or any future component of a smart contract or complex script.
-After a filter is established, the peer will then test each transaction's output against the bloom filter. Only transactions that match the filter are sent to the node.
+After a filter is established, the peer will then test each transaction's outputs against the bloom filter. Only transactions that match the filter are sent to the node.
In response to a +getdata+ message from the node, peers will send a +merkleblock+ message that contains only block headers for blocks matching the filter and a merkle path (see </P2SH/
], which indicates that the mining node that mined this block provides support for the P2SH improvement defined in BIP-16. The introduction of the P2SH capability required signaling by miners to endorse either BIP-16 or BIP-17. Those endorsing the BIP-16 implementation were to include the string +/P2SH/+ in their coinbase data. Those endorsing the BIP-17 implementation of P2SH were to include the string +p2sh/CHV+ in their coinbase data. Finally, the BIP-16 was elected as the winner, and many miners continued including the string +/P2SH/+ in their coinbase to indicate that they provide support for this feature.
+((("bitcoin improvement proposals", "Pay to Script Hash (BIP-16)")))((("bitcoin improvement proposals", "CHECKHASHVERIFY (BIP-17)")))((("CHECKHASHVERIFY (CHV)")))((("Pay-to-Script-Hash (P2SH)", "coinbase data")))The final part of the coinbase data (+2f503253482f+) is the ASCII-encoded string pass:[/P2SH/
], which indicates that the mining node that mined this block supports the P2SH improvement defined in BIP-16. The introduction of the P2SH capability required signaling by miners to endorse either BIP-16 or BIP-17. Those endorsing the BIP-16 implementation were to include +/P2SH/+ in their coinbase data. Those endorsing the BIP-17 implementation of P2SH were to include the string +p2sh/CHV+ in their coinbase data. The BIP-16 was elected as the winner, and many miners continued including the string +/P2SH/+ in their coinbase to indicate support for this feature.
<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.
-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.
+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.
The cover image is from Insects Abroad. The cover fonts are URW Typewriter 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.
diff --git a/copyright.html b/copyright.html index d182436f..f21721ce 100644 --- a/copyright.html +++ b/copyright.html @@ -3,7 +3,7 @@ -Copyright © 2022 aantonop Books, LLC. All rights reserved.
+Copyright © 2017 Andreas M. Antonopoulos, LLC. All rights reserved.
Printed in the United States of America.
@@ -13,7 +13,6 @@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.
-While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author 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.
978-1-491-95438-6
diff --git a/github_contrib.asciidoc b/github_contrib.asciidoc deleted file mode 100644 index feb6fdfd..00000000 --- a/github_contrib.asciidoc +++ /dev/null @@ -1,189 +0,0 @@ -* Abdussamad Abdurrazzaq (AbdussamadA) -* Adán SDPC (aesedepece) -* Akira Chiku (achiku) -* Alex Waters (alexwaters) -* Andrew Donald Kennedy (grkvlt) -* Andrey Esaulov (andremaha) -* andronoob -* AnejaBK -* Appaji (CITIZENDOT) -* ariesunny -* Arthur O'Dwyer (Quuxplusone) -* bargitta -* Basem Alasi (Bamskki) -* bisqfan -* bitcoinctf -* blip151 -* Bryan Gmyrek (physicsdude) -* Carlos Sims (simsbluebox) -* Casey Flynn (cflynn07) -* cclauss -* Chapman Shoop (belovachap) -* chrisd95 -* Christie D'Anna (avocadobreath) -* Cihat Imamoglu (cihati) -* Cody Scott (Siecje) -* coinradar -* Cragin Godley (cgodley) -* Craig Dodd (cdodd) -* dallyshalla -* Dan Nolan (Dan-Nolan) -* Dan Raviv (danra) -* Darius Kramer (dkrmr) -* Darko Janković (trulex) -* David Huie (DavidHuie) -* didongke -* Diego Viola (diegoviola) -* Dimitris Tsapakidis (dimitris-t) -* Dirk Jäckel (biafra23) -* Dmitry Marakasov (AMDmi3) -* drakos (Jolly-Pirate) -* drstrangeM -* Ed Eykholt (edeykholt) -* Ed Leafe (EdLeafe) -* Edward Posnak (edposnak) -* Elias Rodrigues (elias19r) -* Eric Voskuil (evoskuil) -* Eric Winchell (winchell) -* Erik Wahlström (erikwam) -* effectsToCause (vericoin) -* Esteban Ordano (eordano) -* ethers -* Evlix -* fabienhinault -* Fan (whiteath) -* Felix Filozov (ffilozov) -* Francis Ballares (fballares) -* François Wirion (wirion) -* Frank Höger (francyi) -* Gabriel Montes (gabmontes) -* Gaurav Rana (bitcoinsSG) -* genjix -* Geremia -* Gerry Smith (Hermetic) -* gmr81 -* Greg (in3rsha) -* Gregory Trubetskoy (grisha) -* Gus (netpoe) -* halseth -* harelw -* Harry Moreno (morenoh149) -* Hennadii Stepanov (hebasto) -* Holger Schinzel (schinzelh) -* Ioannis Cherouvim (cherouvim) -* Ish Ot Jr. (ishotjr) -* ivangreene -* James Addison (jayaddison) -* Jameson Lopp (jlopp) -* Jason Bisterfeldt (jbisterfeldt) -* Javier Rojas (fjrojasgarcia) -* Jordan Baczuk (JBaczuk) -* Jeremy Bokobza (bokobza) -* JerJohn15 -* jerzybrzoska -* Jimmy DeSilva (jimmydesilva) -* Jo Wo (jowo-io) -* Joe Bauers (joebauers) -* joflynn -* Johnson Lau (jl2012) -* Jonathan Cross (jonathancross) -* Jorgeminator -* jwbats -* Kai Bakker (kaibakker) -* kollokollo -* krupawan5618 -* kynnjo -* Liangzx -* lightningnetworkstores -* lilianrambu -* Liu Yue (lyhistory) -* Lobbelt -* Lucas Betschart (lclc) -* Matt Wesley (MatthewWesley) -* Magomed Aliev (30mb1) -* Mai-Hsuan Chia (mhchia) -* Marco Falke (MarcoFalke) -* María Martín (mmartinbar) -* Marcus Kiisa (mkiisa) -* Mark Erhardt (Xekyo) -* Mark Pors (pors) -* Martin Harrigan (harrigan) -* Martin Vseticka (MartyIX) -* Marzig (marzig76) -* Matt McGivney (mattmcgiv) -* Matthijs Roelink (Matthiti) -* Maximilian Reichel (phramz) -* MG-ng (MG-ng) -* Michalis Kargakis (kargakis) -* Michael C. Ippolito (michaelcippolito) -* Michael Galero (mikong) -* Michael Newman (michaelbnewman) -* Mihail Russu (MihailRussu) -* mikew (mikew) -* milansismanovic -* Minh T. Nguyen (enderminh) -* montvid -* Morfies (morfies) -* Nagaraj Hubli (nagarajhubli) -* Nekomata (nekomata-3) -* nekonenene -* Nhan Vu (jobnomade) -* Nicholas Chen (nickycutesc) -* Ning Shang (syncom) -* Oge Nnadi (ogennadi) -* Oliver Maerz (OliverMaerz) -* Omar Boukli-Hacene (oboukli) -* Óscar Nájera (Titan-C) -* Parzival (Parz-val) -* Paul Desmond Parker (sunwukonga) -* Philipp Gille (philippgille) -* ratijas -* rating89us -* Raul Siles (raulsiles) -* Reproducibility Matters (TheCharlatan) -* Reuben Thomas (rrthomas) -* Robert Furse (Rfurse) -* Roberto Mannai (robermann) -* Richard Kiss (richardkiss) -* rszheng -* Ruben Alexander (hizzvizz) -* Sam Ritchie (sritchie) -* Samir Sadek (netsamir) -* Sandro Conforto (sandroconforto) -* Sanjay Sanathanan (sanjays95) -* Sebastian Falbesoner (theStack) -* Sergei Tikhomirov (s-tikhomirov) -* Sergej Kotliar (ziggamon) -* Seiichi Uchida (topecongiro) -* shaysw -* Simon de la Rouviere (simondlr) -* simone-cominato -* sindhoor7 -* Stacie (staciewaleyko) -* Stephan Oeste (Emzy) -* Stéphane Roche (Janaka-Steph) -* takaya-imai -* Thiago Arrais (thiagoarrais) -* Thomas Kerin (afk11) -* Tochi Obudulu (tochicool) -* Tosin (tkuye) -* Vasil Dimov (vasild) -* venzen -* Vlad Stan (motorina0) -* Vijay Chavda (VijayChavda) -* Vincent Déniel (vincentdnl) -* weinim -* wenxiaolong (QingShiLuoGu) -* wenzhenxiang -* Will Binns (wbnns) -* wintercooled -* wjx -* wll2007 -* Wojciech Langiewicz (wlk) -* Yancy Ribbens (yancyribbens) -* yjjnls -* Yoshimasa Tanabe (emag) -* yuntai -* yurigeorgiev4 -* Zheng Jia (zhengjia) -* Zhou Liang (zhouguoguo)((("", startref="acknowledge0"))) diff --git a/glossary.asciidoc b/glossary.asciidoc index 942c43f9..6a4fca9b 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -18,25 +18,22 @@ block:: blockchain:: A list of validated blocks, each linking to its predecessor all the way to the genesis block. -block reward (aka coinbase reward):: - An amount included in each new block as a reward by the network to the miner who found the Proof-of-Work solution. Approximately every four years, or more accurately every 210,000 blocks, the block reward is halved. It is currently 6.25 BTC per block. - Byzantine Generals Problem:: A reliable computer system must be able to cope with the failure of one or more of its components. A failed component may exhibit a type of behavior that is often overlooked--namely, sending conflicting information to different parts of the system. The problem of coping with this type of failure is expressed abstractly as the Byzantine Generals Problem. -candidate block:: - A block that a miner is still trying to mine. It is not yet a valid block, because it does not contain a valid Proof-of-Work. - -coinbase (aka coinbase data):: - A special field used as the sole input for coinbase transactions. The coinbase data field allows claiming the block reward and provides up to 100 bytes for arbitrary data. - Not to be confused with coinbase transaction or coinbase reward. +coinbase:: + 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. + Not to be confused with Coinbase transaction. coinbase transaction:: The first transaction in a block. Always created by a miner, it includes a single coinbase. - Not to be confused with coinbase (coinbase data) or coinbase reward + Not to be confused with Coinbase. cold storage:: - Refers to keeping a reserve of bitcoin offline. Cold storage is achieved when bitcoin private keys are created and stored in a secure offline environment. Cold storage is important for anyone with bitcoin holdings. Online computers are vulnerable to hackers and should not be used to store a significant amount of bitcoin. + 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. + +colored coins:: + An open source Bitcoin 2.0 protocol that enables developers to create digital assets on top of bitcoin blockchain utilizing its functionalities beyond currency. 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. @@ -62,7 +59,7 @@ double-spending:: Double spending is the result of successfully spending some money more than once. Bitcoin protects against double-spending by verifying each transaction added to the block chain to ensure that the inputs for the transaction had not previously already been spent. ECDSA:: - Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by bitcoin to ensure that funds can only be spent by their rightful owners. + Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners. extra nonce:: As difficulty increased, miners often cycled through all 4 billion values of the nonce without finding a block. Because the coinbase script can store between 2 and 100 bytes of data, miners started using that space as extra nonce space, allowing them to explore a much larger range of block header values to find valid blocks. @@ -76,9 +73,6 @@ fork:: genesis block:: The first block in the blockchain, used to initialize the cryptocurrency. -halving:: - A halving event occurs when the block reward is cut in half, which happens approximately every four years (or precisely every 210,000 blocks). Bitcoin already had three halving events: in 2012 (from 50 to 25 BTC), in 2016 (from 25 to 12.5 BTC), and in 2020 (from 12.5 to 6.25 BTC). - hard fork:: Hard fork, also known as Hard-Forking Change, is a permanent divergence in the blockchain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules. Not to be confused with fork, soft fork, software fork or Git fork. @@ -93,10 +87,10 @@ hashlocks:: A hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time. HD protocol:: - The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP-32), which allows creating child keys from parent keys in a hierarchy. + The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP32), which allows creating child keys from parent keys in a hierarchy. HD wallet:: - Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP-32). + Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP32). HD wallet seed:: HD wallet seed or root seed is a potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet. @@ -111,7 +105,7 @@ LevelDB:: LevelDB is an open source on-disk key-value store. LevelDB is a light-weight, single-purpose library for persistence with bindings to many platforms. Lightning Networks:: - Lightning Network is an implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other. + 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. Locktime:: Locktime, or more technically nLockTime, is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the block chain. @@ -123,16 +117,13 @@ merkle root:: The root node of a merkle tree, a descendant of all the hashed pairs in the tree. Block headers must include a valid merkle root descended from all transactions in that block. merkle tree:: - A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root. In bitcoin, the leaves are almost always transactions from a single block. + A tree constructed by hashing paired data (the leaves), then pairing and hashing the results until a single hash remains, the merkle root. In Bitcoin, the leaves are almost always transactions from a single block. miner:: A network node that finds valid proof of work for new blocks, by repeated hashing. -mining reward:: - The reward miners receive in return for the security provided by mining. Includes the new coins created with each new block, also known as a block reward or coinbase reward, and the transaction fees from all the transactions included in the block. - multisignature:: - Multisignature (multisig) refers to requiring a minimum number (M) of keys (N) to authorize an M-of-N transaction. + Multisignature (multisig) refers to requiring more than one key to authorize a bitcoin transaction. network:: A peer-to-peer network that propagates transactions and blocks to every Bitcoin node on the network. @@ -144,10 +135,10 @@ off-chain transactions:: An off-chain transaction is the movement of value outside of the block chain. While an on-chain transaction—usually referred to as simply __a transaction__—modifies the blockchain and depends on the blockchain to determine its validity an off-chain transaction relies on other methods to record and validate the transaction. opcode:: - Operation codes from the bitcoin Script language which push data or perform functions within a pubkey script or signature script. + 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 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. @@ -171,7 +162,7 @@ P2SH:: P2SH or Pay-to-Script-Hash is a powerful new type of transaction that greatly simplifies the use of complex transaction scripts. With P2SH the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, only a hash of it is in the locking script. P2SH address:: - P2SH addresses are Base58Check encodings of the 20-byte hash of a script. They use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". P2SH addresses hide all of the complexity, so that the person making a payment does not see the script. + 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. P2WPKH:: The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified. @@ -180,13 +171,10 @@ P2WSH:: The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is about the cryptographic proof location change from the scriptSig field to the witness field and the scriptPubKey that is also modified. paper wallet:: - In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes. + In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes. -passphrase:: - A passphrase is an optional string created by the user that serves as an additional security factor protecting the seed, even when the seed is compromised by a thief. It can also be used as a form of plausible deniability, where a chosen passphrase leads to a wallet with a small amount of funds used to distract an attacker from the “real” wallet that contains the majority of funds. - payment channels:: - A micropayment channel or payment channel is a class of techniques designed to allow users to make multiple bitcoin transactions without committing all of the transactions to the Bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants. + A micropayment channel or payment channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants. pooled mining:: Pooled mining is a mining approach where multiple generating clients contribute to the generation of a block, and then split the block reward according the contributed processing power. @@ -197,14 +185,17 @@ Proof-of-Stake:: Proof-of-Work:: A piece of data that requires significant computation to find. In bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network-wide target, the difficulty target. +reward:: + 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. + RIPEMD-160:: RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more. satoshi:: - A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of bitcoin, Satoshi Nakamoto. ((("satoshi"))) + A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. ((("satoshi"))) Satoshi Nakamoto:: - Satoshi Nakamoto is the name used by the person or people who designed bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown. + Satoshi Nakamoto is the name used by the person or people who designed Bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown. Script:: Bitcoin uses a scripting system for transactions. Forth-like, Script is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops. @@ -223,24 +214,23 @@ secret key (aka private key):: ---- Segregated Witness:: - Segregated Witness is an upgrade to the Bitcoin protocol in which signature ("witness") data is separated from sender/receiver data to further optimize the structure of transactions. Segregated Witness was implemented as a soft fork; a change that technically makes bitcoin’s protocol rules more restrictive. + 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. SHA:: The Secure Hash Algorithm or SHA is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST). Simplified Payment Verification (SPV):: - SPV or simplified payment verification is a method for verifying that particular transactions were included in a block, without downloading the entire block. This method of verification is often used by lightweight Bitcoin clients. + SPV or simplified payment verification is 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. soft fork:: soft fork or Soft-Forking Change is a temporary fork in the blockchain which commonly occurs when miners using non-upgraded nodes don't follow a new consensus rule their nodes don’t know about. Not to be confused with fork, hard fork, software fork or Git fork. stale block:: - A valid block that was successfully mined but that isn’t included on the current main branch (with most cumulative Proof-of-Work), because some other valid block that was mined at the same height had its chain extended first. The miner of a stale block doesn't get the block reward or the transactions fees of this block. - Not to be confused with orphan block or candidate block. + Block that was successfully mined but that isn’t included on the current best block chain, 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. + A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and hashed timelock contracts. transaction:: In simple terms, a transfer of bitcoin from one address to another. More precisely, a transaction is a signed data structure expressing a transfer of value. Transactions are transmitted over the Bitcoin network, collected by miners, and included into blocks, made permanent on the blockchain. @@ -249,7 +239,7 @@ transaction pool:: An unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions. Turing completeness:: - A programming language is called "Turing complete" if it can run any program that a Turing machine can run, given enough time and memory. + A program language is called "Turing complete" if it can run any program that a Turing machine can run, given enough time and memory. unspent transaction output (UTXO):: UTXO is an unspent transaction output that can be spent as an input in a new transaction. diff --git a/images/ew_0101.png b/images/ew_0101.png deleted file mode 100644 index 3332afae..00000000 Binary files a/images/ew_0101.png and /dev/null differ diff --git a/images/mbc2_0201.png b/images/mbc2_0201.png index 22f0d90c..0f8bfe15 100755 Binary files a/images/mbc2_0201.png and b/images/mbc2_0201.png differ diff --git a/images/mbc2_0204.png b/images/mbc2_0204.png index 672bdc52..9bb1adea 100644 Binary files a/images/mbc2_0204.png and b/images/mbc2_0204.png differ diff --git a/images/mbc2_0205.png b/images/mbc2_0205.png index 90f47a66..8e52f7dc 100755 Binary files a/images/mbc2_0205.png and b/images/mbc2_0205.png differ diff --git a/images/mbc2_0206.png b/images/mbc2_0206.png index ed026b47..d3859104 100755 Binary files a/images/mbc2_0206.png and b/images/mbc2_0206.png differ diff --git a/images/mbc2_0207.png b/images/mbc2_0207.png index 45bd8def..793be129 100755 Binary files a/images/mbc2_0207.png and b/images/mbc2_0207.png differ diff --git a/images/mbc2_0209.png b/images/mbc2_0209.png index e901dccf..46c66445 100755 Binary files a/images/mbc2_0209.png and b/images/mbc2_0209.png differ diff --git a/images/mbc2_0210.png b/images/mbc2_0210.png index 14383d5d..b77ce4e6 100755 Binary files a/images/mbc2_0210.png and b/images/mbc2_0210.png differ diff --git a/images/mbc2_0502.png b/images/mbc2_0502.png index 84aec900..74e6be24 100755 Binary files a/images/mbc2_0502.png and b/images/mbc2_0502.png differ diff --git a/images/mbc2_0505.png b/images/mbc2_0505.png index 128b9a7f..a8db4fd4 100755 Binary files a/images/mbc2_0505.png and b/images/mbc2_0505.png differ diff --git a/images/mbc2_0508.png b/images/mbc2_0508.png new file mode 100755 index 00000000..6a115506 Binary files /dev/null and b/images/mbc2_0508.png differ diff --git a/images/mbc2_0512.png b/images/mbc2_0512.png index 48c5ec8e..a0d524d0 100755 Binary files a/images/mbc2_0512.png and b/images/mbc2_0512.png differ diff --git a/images/mbc2_0609.png b/images/mbc2_0609.png deleted file mode 100644 index bf146cad..00000000 Binary files a/images/mbc2_0609.png and /dev/null differ diff --git a/images/mbc2_1003.png b/images/mbc2_1003.png index ce292847..6f237323 100755 Binary files a/images/mbc2_1003.png and b/images/mbc2_1003.png differ diff --git a/images/mbc2_1004.png b/images/mbc2_1004.png index a13964ae..032c76d7 100755 Binary files a/images/mbc2_1004.png and b/images/mbc2_1004.png differ diff --git a/images/mbc2_1005.png b/images/mbc2_1005.png index bb9dc739..d47ce4be 100755 Binary files a/images/mbc2_1005.png and b/images/mbc2_1005.png differ diff --git a/images/mbc2_1006.png b/images/mbc2_1006.png index 7a5c6b9a..10474d3b 100755 Binary files a/images/mbc2_1006.png and b/images/mbc2_1006.png differ diff --git a/images/mbc2_1007.png b/images/mbc2_1007.png index 434de5f0..88f00ec5 100755 Binary files a/images/mbc2_1007.png and b/images/mbc2_1007.png differ diff --git a/images/mbc2_1008.png b/images/mbc2_1008.png index 0dec9086..d5351923 100755 Binary files a/images/mbc2_1008.png and b/images/mbc2_1008.png differ diff --git a/images/mbc2_1201.png b/images/mbc2_1201.png index 7d197182..bf6311a8 100755 Binary files a/images/mbc2_1201.png and b/images/mbc2_1201.png differ diff --git a/images/mbc2_1202.png b/images/mbc2_1202.png index 877b4448..54446df2 100755 Binary files a/images/mbc2_1202.png and b/images/mbc2_1202.png differ diff --git a/images/mbc2_1203.png b/images/mbc2_1203.png index 5dc7d260..3d320f3d 100755 Binary files a/images/mbc2_1203.png and b/images/mbc2_1203.png differ diff --git a/images/mbc2_1204.png b/images/mbc2_1204.png index ff2617d6..7d197182 100755 Binary files a/images/mbc2_1204.png and b/images/mbc2_1204.png differ diff --git a/images/mbc2_1205.png b/images/mbc2_1205.png index 2b5c23f3..877b4448 100755 Binary files a/images/mbc2_1205.png and b/images/mbc2_1205.png differ diff --git a/images/mbc2_1206.png b/images/mbc2_1206.png index 4a84950a..5dc7d260 100755 Binary files a/images/mbc2_1206.png and b/images/mbc2_1206.png differ diff --git a/images/mbc2_1207.png b/images/mbc2_1207.png index 385224ee..ff2617d6 100755 Binary files a/images/mbc2_1207.png and b/images/mbc2_1207.png differ diff --git a/images/mbc2_1208.png b/images/mbc2_1208.png new file mode 100755 index 00000000..2b5c23f3 Binary files /dev/null and b/images/mbc2_1208.png differ diff --git a/images/mbc2_1209.png b/images/mbc2_1209.png new file mode 100755 index 00000000..4a84950a Binary files /dev/null and b/images/mbc2_1209.png differ diff --git a/images/mbc2_1210.png b/images/mbc2_1210.png new file mode 100755 index 00000000..385224ee Binary files /dev/null and b/images/mbc2_1210.png differ diff --git a/images/sighash_combinations.png b/images/sighash_combinations.png deleted file mode 100644 index 8a12f93f..00000000 Binary files a/images/sighash_combinations.png and /dev/null differ diff --git a/preface.asciidoc b/preface.asciidoc index b22357de..8e72582c 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -85,12 +85,12 @@ DO NOT SEND MONEY TO ANY OF THE ADDRESSES IN THIS BOOK. Your money will be taken [role = "safarienabled"] [NOTE] ==== -pass:[Safari] (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals. +pass:[Safari] (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals. ==== Members have access to thousands of books, training videos, Learning Paths, interactive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others. -For more information, please visit pass:[https://oreilly.com/safari]. +For more information, please visit pass:[http://oreilly.com/safari]. === How to Contact Us @@ -109,19 +109,19 @@ For more information, please visit pass:[bookquestions@oreilly.com]. -For more information about our books, courses, conferences, and news, see our website at link:$$https://www.oreilly.com$$[]. +For more information about our books, courses, conferences, and news, see our website at link:$$http://www.oreilly.com$$[]. -Find us on Facebook: link:$$https://facebook.com/oreilly$$[] +Find us on Facebook: link:$$http://facebook.com/oreilly$$[] -Follow us on Twitter: link:$$https://twitter.com/oreillymedia$$[] +Follow us on Twitter: link:$$http://twitter.com/oreillymedia$$[] -Watch us on YouTube: link:$$https://www.youtube.com/oreillymedia$$[] +Watch us on YouTube: link:$$http://www.youtube.com/oreillymedia$$[] [role="pagebreak-before"] === Contacting the Author You can contact me, Andreas M. Antonopoulos, on my personal site: -link:$$https://aantonop.com/$$[] +link:$$https://antonopoulos.com/$$[] Information about _Mastering Bitcoin_ as well as the Open Edition and translations are available on: link:$$https://bitcoinbook.info/$$[] @@ -132,7 +132,7 @@ link:$$https://facebook.com/AndreasMAntonopoulos$$[] Follow me on Twitter: link:$$https://twitter.com/aantonop$$[] -Follow me on LinkedIn: +Follow me on Linkedin: link:$$https://linkedin.com/company/aantonop$$[] Many thanks to all my patrons who support my work through monthly donations. You can follow my Patreon page here: @@ -167,9 +167,90 @@ Thank you all for supporting me throughout this journey. Many contributors offered comments, corrections, and additions to the early-release draft on GitHub. Thank you all for your contributions to this book. -The following is a list of notable GitHub contributors: - -//// -Github contributor acknowledgments in a new file... -//// -include::github_contrib.asciidoc[] +Following is a list of notable GitHub contributors, including their GitHub ID in parentheses: + +* Akira Chiku (achiku) +* Alex Waters (alexwaters) +* Andrew Donald Kennedy (grkvlt) +* bitcoinctf +* Bryan Gmyrek (physicsdude) +* Casey Flynn (cflynn07) +* cclauss +* Chapman Shoop (belovachap) +* Christie D'Anna (avocadobreath) +* Cody Scott (Siecje) +* coinradar +* Cragin Godley (cgodley) +* Craig Dodd (cdodd) +* dallyshalla +* Darius Kramer (dkrmr) +* David Huie (DavidHuie) +* Diego Viola (diegoviola) +* Dirk Jäckel (biafra23) +* Dimitris Tsapakidis (dimitris-t) +* Dmitry Marakasov (AMDmi3) +* drstrangeM +* Ed Eykholt (edeykholt) +* Ed Leafe (EdLeafe) +* Edward Posnak (edposnak) +* Elias Rodrigues (elias19r) +* Eric Voskuil (evoskuil) +* Eric Winchell (winchell) +* Erik Wahlström (erikwam) +* effectsToCause (vericoin) +* Esteban Ordano (eordano) +* ethers +* fabienhinault +* Frank Höger (francyi) +* Gaurav Rana (bitcoinsSG) +* genjix +* halseth +* Holger Schinzel (schinzelh) +* Ioannis Cherouvim (cherouvim) +* Ish Ot Jr. (ishotjr) +* ivangreene +* James Addison (jayaddison) +* Jameson Lopp (jlopp) +* Jason Bisterfeldt (jbisterfeldt) +* Javier Rojas (fjrojasgarcia) +* Jeremy Bokobza (bokobza) +* JerJohn15 +* Joe Bauers (joebauers) +* joflynn +* Johnson Lau (jl2012) +* Jonathan Cross (jonathancross) +* Jorgeminator +* Kai Bakker (kaibakker) +* Lucas Betschart (lclc) +* Magomed Aliev (30mb1) +* Mai-Hsuan Chia (mhchia) +* marcofalke +* Marzig (marzig76) +* Matt McGivney (mattmcgiv) +* Maximilian Reichel (phramz) +* Michalis Kargakis (kargakis) +* Michael C. Ippolito (michaelcippolito) +* Mihail Russu (MihailRussu) +* Minh T. Nguyen (enderminh) +* Nagaraj Hubli (nagarajhubli) +* Nekomata (nekomata-3) +* Philipp Gille (philippgille) +* Robert Furse (Rfurse) +* Richard Kiss (richardkiss) +* Ruben Alexander (hizzvizz) +* Sam Ritchie (sritchie) +* Sebastian Falbesoner (theStack) +* Sergej Kotliar (ziggamon) +* Seiichi Uchida (topecongiro) +* Simon de la Rouviere (simondlr) +* Stephan Oeste (Emzy) +* takaya-imai +* Thiago Arrais (thiagoarrais) +* Thomas Kerin (afk11) +* venzen +* Will Binns (wbnns) +* wintercooled +* wjx +* Wojciech Langiewicz (wlk) +* Yancy Ribbens (yancyribbens) +* yurigeorgiev4((("", startref="acknowledge0"))) diff --git a/segwit_v1.asciidoc b/segwit_v1.asciidoc index cdd5c421..b781e73a 100644 --- a/segwit_v1.asciidoc +++ b/segwit_v1.asciidoc @@ -1,5 +1,3 @@ [[segwitv1]] [[taproot]] === SegWit v1 - -https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki diff --git a/titlepage.html b/titlepage.html index 4b24e536..13fb89b8 100644 --- a/titlepage.html +++ b/titlepage.html @@ -1,6 +1,6 @@Third Edition
+Second Edition
Programming the Open Blockchain