From b991b93414a095d0b779210fb15337e0e06aeca9 Mon Sep 17 00:00:00 2001 From: cclauss Date: Sun, 23 Jul 2017 19:50:41 +0200 Subject: [PATCH 01/36] Add free automated flake8 testing on all pull requests The owner of the this repo would need to go to https://travis-ci.org/profile and flip on the repository switch to enable free automated linting of all Python files each pull requests to the `develop` branch. --- .travis.yml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 .travis.yml diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 00000000..3115b7e9 --- /dev/null +++ b/.travis.yml @@ -0,0 +1,19 @@ +language: python +python: + - 2.7.13 + - 3.6.2 +branches: + only: + - develop +install: + - pip install flake8 # pytest # add other testing frameworks later +before_script: + # stop the build if there are Python syntax errors or undefined names + - time flake8 . --count --select=E901,E999,F821,F822,F823 --show-source --statistics + # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide + - time flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics +script: + - true # add other tests here +notifications: + on_success: change + on_failure: always From 691fd4f3b5e5cc5a96639ccc52c8120dbb4398e5 Mon Sep 17 00:00:00 2001 From: Lane Rettig Date: Sat, 9 Sep 2017 13:59:13 -0400 Subject: [PATCH 02/36] Fix typo --- ch12.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index d973eaf8..84d99334 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -426,7 +426,7 @@ IF ELSE # Refund after timeout. CHECKLOCKTIMEVERIFY DROP - CHECKSIG + CHECKSIG ENDIF ---- From eb4116f8b47b211f5748fa816138a2d2906a22c6 Mon Sep 17 00:00:00 2001 From: jachiang <26572234+jachiang@users.noreply.github.com> Date: Mon, 11 Sep 2017 21:07:16 +0200 Subject: [PATCH 03/36] ch06 sighash flag typo: one input (s) --- ch06.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index 30ee8c07..dd687964 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -610,8 +610,8 @@ In addition, there is a modifier flag +SIGHASH_ANYONECANPAY+, which can be combi [options="header"] |======================= |SIGHASH flag| Value | Description -| ALL\|ANYONECANPAY | 0x81 | Signature applies to one inputs and all outputs -| NONE\|ANYONECANPAY | 0x82 | Signature applies to one inputs, none of the outputs +| ALL\|ANYONECANPAY | 0x81 | Signature applies to one input and all outputs +| NONE\|ANYONECANPAY | 0x82 | Signature applies to one input, none of the outputs | SINGLE\|ANYONECANPAY | 0x83 | Signature applies to one input and the output with the same index number |======================= From 06378864c58efced07e4d8a7265d7100fa88708d Mon Sep 17 00:00:00 2001 From: jachiang <26572234+jachiang@users.noreply.github.com> Date: Mon, 11 Sep 2017 21:16:41 +0200 Subject: [PATCH 04/36] ch06 typo: first part of an input is tx reference and output index (vs sequence number, which is the 3rd part) --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index dd687964..66c27672 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -171,7 +171,7 @@ Here are some hints: To build a transaction, a wallet selects from the UTXO it controls, UTXO with enough value to make the requested payment. Sometimes one UTXO is enough, other times more than one is needed. For each UTXO that will be consumed to make this payment, the wallet creates one input pointing to the UTXO and unlocks it with an unlocking script. -Let's look at the components of an input in greater detail. The first part of an input is a pointer to an UTXO by reference to the transaction hash and sequence number where the UTXO is recorded in the blockchain. The second part is an unlocking script, which the wallet constructs in order to satisfy the spending conditions set in the UTXO. Most often, the unlocking script is a digital signature and public key proving ownership of the bitcoin. However, not all unlocking scripts contain signatures. The third part is a sequence number, which will be discussed later. +Let's look at the components of an input in greater detail. The first part of an input is a pointer to an UTXO by reference to the transaction hash and an output index, which identifies the specific UTXO from that transaction. The second part is an unlocking script, which the wallet constructs in order to satisfy the spending conditions set in the UTXO. Most often, the unlocking script is a digital signature and public key proving ownership of the bitcoin. However, not all unlocking scripts contain signatures. The third part is a sequence number, which will be discussed later. Consider our example in <>. The transaction inputs are an array (list) called +vin+: From 8f1075f42340715b37e835bad77d2937a10f5852 Mon Sep 17 00:00:00 2001 From: jachiang <26572234+jachiang@users.noreply.github.com> Date: Mon, 11 Sep 2017 21:24:53 +0200 Subject: [PATCH 05/36] ch06 correction: First part of input is transaction ID & output index (vs. sequence, which is the 3rd part) --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index 66c27672..4e4b56c8 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -171,7 +171,7 @@ Here are some hints: To build a transaction, a wallet selects from the UTXO it controls, UTXO with enough value to make the requested payment. Sometimes one UTXO is enough, other times more than one is needed. For each UTXO that will be consumed to make this payment, the wallet creates one input pointing to the UTXO and unlocks it with an unlocking script. -Let's look at the components of an input in greater detail. The first part of an input is a pointer to an UTXO by reference to the transaction hash and an output index, which identifies the specific UTXO from that transaction. The second part is an unlocking script, which the wallet constructs in order to satisfy the spending conditions set in the UTXO. Most often, the unlocking script is a digital signature and public key proving ownership of the bitcoin. However, not all unlocking scripts contain signatures. The third part is a sequence number, which will be discussed later. +Let's look at the components of an input in greater detail. The first part of an input is a pointer to an UTXO by reference to the transaction hash and an output index, which identifies the specific UTXO in that transaction. The second part is an unlocking script, which the wallet constructs in order to satisfy the spending conditions set in the UTXO. Most often, the unlocking script is a digital signature and public key proving ownership of the bitcoin. However, not all unlocking scripts contain signatures. The third part is a sequence number, which will be discussed later. Consider our example in <>. The transaction inputs are an array (list) called +vin+: From 1d56d3629e5e422d40e2a97ce814006dcdb26d69 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?G=C3=BCnter=20Rote?= Date: Sat, 30 Sep 2017 21:06:05 +0200 Subject: [PATCH 06/36] invisible typo: replaced 11 by ll --- appdx-bitcoinwhitepaper.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/appdx-bitcoinwhitepaper.asciidoc b/appdx-bitcoinwhitepaper.asciidoc index 4033a031..464ad9a4 100644 --- a/appdx-bitcoinwhitepaper.asciidoc +++ b/appdx-bitcoinwhitepaper.asciidoc @@ -15,7 +15,7 @@ _satoshin@gmx.com_ pass:[www.bitcoin.org] -*Abstract.* A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'11 generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. +*Abstract.* A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. ==== Introduction Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. From 4939a827eb2d121c1cfa147bc93bbbfe7f3fae56 Mon Sep 17 00:00:00 2001 From: Janus Troelsen Date: Wed, 18 Oct 2017 14:52:20 +0200 Subject: [PATCH 07/36] segwit has activated --- ch09.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch09.asciidoc b/ch09.asciidoc index 42c5ea3d..f441ce10 100644 --- a/ch09.asciidoc +++ b/ch09.asciidoc @@ -343,7 +343,7 @@ $ bitcoin-cli -testnet getblockchaininfo You can also run on testnet3 with other full-node implementations, such as +btcd+ (written in Go) and +bcoin+ (written in JavaScript), to experiment and learn in other programming languages and frameworks. -In early 2017, testnet3 supports all the features of mainnet, in addition to Segregated Witness (see <>), which has yet to activate on mainnet. Therefore, testnet3 can also be used to test Segregated Witness features.((("", startref="testnet09"))) +In early 2017, testnet3 supports all the features of mainnet, including Segregated Witness (see <>). Therefore, testnet3 can also be used to test Segregated Witness features.((("", startref="testnet09"))) ==== Segnet—The Segregated Witness Testnet From d8e26e8d53b592ac905a75c370fd20faaad4160b Mon Sep 17 00:00:00 2001 From: Marcin Zduniak Date: Sat, 11 Nov 2017 21:11:55 +0100 Subject: [PATCH 08/36] Update ch06.asciidoc --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index 80b31ca6..31207e45 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -507,7 +507,7 @@ image::images/mbc2_0606.png["Tx_Script_P2PubKeyHash_2"] ((("digital signatures", "algorithm used")))((("Elliptic Curve Digital Signature Algorithm (ECDSA)")))The digital signature algorithm used in bitcoin is the _Elliptic Curve Digital Signature Algorithm_, or _ECDSA_. ECDSA is the algorithm used for digital signatures based on elliptic curve private/public key pairs, as described in <>. ECDSA is used by the script functions +OP_CHECKSIG+, +OP_CHECKSIGVERIFY+, +OP_CHECKMULTISIG+, and +OP_CHECKMULTISIGVERIFY+. Any time you see those in a locking script, the unlocking script must contain an ECDSA signature. -((("digital signatures", "purposes of")))A digital signature serves three purposes in bitcoin (see the following sidebar). First, the signature proves that the owner of the private key, who is by implication the owner of the funds, has _authorized_ the spending of those funds. Secondly, the proof of authorization is _undeniable_ (nonrepudiation). Thirdly, the signature proves that the transaction (or specific parts of the transaction) have not and _cannot be modified_ by anyone after it has been been signed. +((("digital signatures", "purposes of")))A digital signature serves three purposes in bitcoin (see the following sidebar). First, the signature proves that the owner of the private key, who is by implication the owner of the funds, has _authorized_ the spending of those funds. Secondly, the proof of authorization is _undeniable_ (nonrepudiation). Thirdly, the signature proves that the transaction (or specific parts of the transaction) have not and _cannot be modified_ by anyone after it has been signed. Note that each transaction input is signed independently. This is critical, as neither the signatures nor the inputs have to belong to or be applied by the same "owners." In fact, a specific transaction scheme called "CoinJoin" uses this fact to create multi-party transactions for privacy. From c4ea9cd470c9b9ff7171fa8d50d9a4b27f3330d7 Mon Sep 17 00:00:00 2001 From: cclauss Date: Sat, 18 Nov 2017 08:02:06 +0100 Subject: [PATCH 09/36] Test all three branches --- .travis.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.travis.yml b/.travis.yml index 3115b7e9..b1892a58 100644 --- a/.travis.yml +++ b/.travis.yml @@ -5,6 +5,8 @@ python: branches: only: - develop + - first_edition + - second_edition install: - pip install flake8 # pytest # add other testing frameworks later before_script: From 4541dc5a960778b1364a08a440722966f12e1f2b Mon Sep 17 00:00:00 2001 From: cclauss Date: Sat, 18 Nov 2017 08:02:35 +0100 Subject: [PATCH 10/36] Update .travis.yml --- .travis.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.travis.yml b/.travis.yml index b1892a58..dcb212e8 100644 --- a/.travis.yml +++ b/.travis.yml @@ -1,7 +1,7 @@ language: python python: - - 2.7.13 - - 3.6.2 + - 2.7 + - 3.6 branches: only: - develop From a594496c6cdef48835f37e498ebb3ac441490398 Mon Sep 17 00:00:00 2001 From: Himanshu Dabas Date: Wed, 22 Nov 2017 03:59:16 +0530 Subject: [PATCH 11/36] updated the "Structure of a Block" updated the value of average transaction size, average transactions in a block and total block size compared to the block header size in accordance with the current structure of the Bitcoin Blockchain. --- ch09.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch09.asciidoc b/ch09.asciidoc index 04da1788..c4678493 100644 --- a/ch09.asciidoc +++ b/ch09.asciidoc @@ -15,7 +15,7 @@ One way to think about the blockchain is like layers in a geological formation, === Structure of a Block -((("blocks", "structure of")))((("blockchain (the)", "block structure")))A block is a container data structure that aggregates transactions for inclusion in the public ledger, the blockchain. The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of its size. The block header is 80 bytes, whereas the average transaction is at least 250 bytes and the average block contains more than 500 transactions. A complete block, with all transactions, is therefore 1,000 times larger than the block header. <> describes the structure of a block. +((("blocks", "structure of")))((("blockchain (the)", "block structure")))A block is a container data structure that aggregates transactions for inclusion in the public ledger, the blockchain. The block is made of a header, containing metadata, followed by a long list of transactions that make up the bulk of its size. The block header is 80 bytes, whereas the average transaction is at least 400 bytes and the average block contains more than 1900 transactions. A complete block, with all transactions, is therefore 10,000 times larger than the block header. <> describes the structure of a block. [[block_structure1]] [role="pagebreak-before"] From 552867346e14ba75ec166bb5c02426734537cc2f Mon Sep 17 00:00:00 2001 From: Himanshu Dabas Date: Wed, 22 Nov 2017 04:43:22 +0530 Subject: [PATCH 12/36] Fixed grammar mistake --- ch09.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch09.asciidoc b/ch09.asciidoc index c4678493..19a92fb5 100644 --- a/ch09.asciidoc +++ b/ch09.asciidoc @@ -57,7 +57,7 @@ The nonce, difficulty target, and timestamp are used in the mining process and w Note that the block hash is not actually included inside the block's data structure, neither when the block is transmitted on the network, nor when it is stored on a node's persistence storage as part of the blockchain. Instead, the block's hash is computed by each node as the block is received from the network. The block hash might be stored in a separate database table as part of the block's metadata, to facilitate indexing and faster retrieval of blocks from disk. -A second way to identify a block is by its position in the blockchain, called the pass:[block height. The first block ever created is at block height 0 (zero) and is the] pass:[same block that was previously referenced by the following block hash] +000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+. A block can thus be identified two ways: by referencing the block hash or by referencing the block height. Each subsequent block added "on top" of that first block is one position "higher" in the blockchain, like boxes stacked one on top of the other. The block height on January 1, 2017 was approximately 446,000, meaning there were 446,000 blocks stacked on top of the first block created in January 2009. +A second way to identify a block is by its position in the blockchain, called the pass:[block height. The first block ever created is at block height 0 (zero) and is the] pass:[same block that was previously referenced by the following block hash] +000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+. A block can thus be identified in two ways: by referencing the block hash or by referencing the block height. Each subsequent block added "on top" of that first block is one position "higher" in the blockchain, like boxes stacked one on top of the other. The block height on January 1, 2017 was approximately 446,000, meaning there were 446,000 blocks stacked on top of the first block created in January 2009. Unlike the block hash, the block height is not a unique identifier. Although a single block will always have a specific and invariant block height, the reverse is not true—the block height does not always identify a single block. Two or more blocks might have the same block height, competing for the same position in the blockchain. This scenario is discussed in detail in the section <>. The block height is also not a part of the block's data structure; it is not stored within the block. Each node dynamically identifies a block's position (height) in the blockchain when it is received from the bitcoin network. The block height might also be stored as metadata in an indexed database table for faster retrieval. From b1041171c8ea450ff4fab58b993ff4e6ec27f1a5 Mon Sep 17 00:00:00 2001 From: Matthew Sedaghatfar Date: Thu, 23 Nov 2017 12:52:34 -0500 Subject: [PATCH 13/36] Update ch01.asciidoc --- ch01.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index c7bc6945..b98dc781 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -54,7 +54,7 @@ Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibil .A Solution to a Distributed Computing Problem **** -((("Byzantine Generals' Problem")))Satoshi Nakamoto's invention is also a practical and novel solution to a problem in distributed computing, known as the "Byzantine Generals' Problem." Briefly, the problem consists of trying to agree on a course of action or the state of a system by exchanging information over an unreliable and potentially compromised network. ((("central trusted authority")))Satoshi Nakamoto's solution, which uses the concept of Proof-of-Work to achieve consensus _without a central trusted authority_, represents a breakthrough in distributed computing and has wide applicability beyond currency. It can be used to achieve consensus on decentralized networks to prove the fairness of elections, lotteries, asset registries, digital notarization, and more. +((("Byzantine Generals' Problem")))Satoshi Nakamoto's invention is also a practical and novel solution to a problem in distributed computing, known as the "Byzantine Generals' Problem." Briefly, the problem consists of trying to agree on a course of action or the state of a system by exchanging information over an unreliable and potentially compromised network. ((("central trusted authority")))Satoshi Nakamoto's solution, which uses the concept of Proof-of-Work to achieve consensus _without a centrally trusted authority_, represents a breakthrough in distributed computing and has wide applicability beyond currency. It can be used to achieve consensus on decentralized networks to prove the fairness of elections, lotteries, asset registries, digital notarization, and more. **** @@ -92,7 +92,7 @@ Each of these stories is based on the real people and real industries currently ==== Choosing a Bitcoin Wallet -((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. It is therefore impossible to recommend a specific brand or project of wallet. However, we can categorize bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. Better yet, moving money between bitcoin wallets is easy, cheap, and fast, so it is worth trying out several different wallets until you find one that fits your needs. +((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. It is therefore impossible to recommend a specific brand or wallet. However, we can categorize bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. Better yet, moving money between bitcoin wallets is easy, cheap, and fast, so it is worth trying out several different wallets until you find one that fits your needs. [role="pagebreak-before"] Bitcoin wallets can be categorized as follows, according to the platform: From f443db4a14257f70b6b9a0e98c60bd19322b45d0 Mon Sep 17 00:00:00 2001 From: Matthew Sedaghatfar Date: Thu, 23 Nov 2017 13:01:19 -0500 Subject: [PATCH 14/36] Update ch01.asciidoc Updated Market cap value --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index c7bc6945..6d09d867 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -47,7 +47,7 @@ When cryptography started becoming more broadly available and understood in the ((("Nakamoto, Satoshi")))((("distributed computing")))((("bitcoin", "history of")))Bitcoin was invented in 2008 with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System,"footnote:["Bitcoin: A Peer-to-Peer Electronic Cash System," Satoshi Nakamoto (https://bitcoin.org/bitcoin.pdf).] written under the alias of Satoshi Nakamoto (see <>). Nakamoto combined several prior inventions such as b-money and HashCash to create a completely decentralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation of transactions. ((("Proof-of-Work algorithm")))((("decentralized systems", "consensus in")))((("mining and consensus", "Proof-of-Work algorithm")))The key innovation was to use a distributed computation system (called a "Proof-of-Work" algorithm) to conduct a global "election" every 10 minutes, allowing the decentralized network to arrive at _consensus_ about the state of transactions. ((("double-spend problem")))((("spending bitcoin", "double-spend problem")))This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions through a central clearinghouse. -The bitcoin network started in 2009, based on a reference implementation published by Nakamoto and since revised by many other programmers. The implementation of the Proof-of-Work algorithm (mining) that provides security and resilience for bitcoin has increased in power exponentially, and now exceeds the combined processing power of the world's top supercomputers. Bitcoin's total market value has at times exceeded $20 billion US dollars, depending on the bitcoin-to-dollar exchange rate. The largest transaction processed so far by the network was $150 million US dollars, transmitted instantly and processed without any fees. +The bitcoin network started in 2009, based on a reference implementation published by Nakamoto and since revised by many other programmers. The implementation of the Proof-of-Work algorithm (mining) that provides security and resilience for bitcoin has increased in power exponentially, and now exceeds the combined processing power of the world's top supercomputers. Bitcoin's total market value has at times exceeded $135 billion US dollars, depending on the bitcoin-to-dollar exchange rate. The largest transaction processed so far by the network was $150 million US dollars, transmitted instantly and processed without any fees. Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind bitcoin is still unknown. ((("open source licenses")))However, neither Satoshi Nakamoto nor anyone else exerts individual control over the bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics. From 1267d98b883f0c0e83674053805b28e9b629ead8 Mon Sep 17 00:00:00 2001 From: Matthew Sedaghatfar Date: Thu, 23 Nov 2017 13:05:27 -0500 Subject: [PATCH 15/36] Update ch02.asciidoc grammar changes --- ch02.asciidoc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index f2411d2f..0d94e9df 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -73,11 +73,11 @@ A description for the payment: "Purchase at Bob's Cafe" Alice uses her smartphone to scan the barcode on display. Her smartphone shows a payment of +0.0150 BTC+ to +Bob's Cafe+ and she selects Send to authorize the payment. Within a few seconds (about the same amount of time as a credit card authorization), Bob sees the transaction on the register, completing the transaction. -In the following sections we will examine this transaction in more detail. We'll see how Alice's wallet constructed it, how it was propagated across the network, how it was verified, and finally, how Bob can spend that amount in subsequent transactions. +In the following sections, we will examine this transaction in more detail. We'll see how Alice's wallet constructed it, how it was propagated across the network, how it was verified, and finally, how Bob can spend that amount in subsequent transactions. [NOTE] ==== -((("fractional values")))((("milli-bitcoin")))((("satoshis")))The bitcoin network can transact in fractional values, e.g., from millibitcoin (1/1000th of a bitcoin) down to 1/100,000,000th of a bitcoin, which is known as a satoshi. Throughout this book we’ll use the term “bitcoin” to refer to any quantity of bitcoin currency, from the smallest unit (1 satoshi) to the total number (21,000,000) of all bitcoin that will ever be mined. +((("fractional values")))((("milli-bitcoin")))((("satoshis")))The bitcoin network can transact in fractional values, e.g., from millibitcoin (1/1000th of a bitcoin) down to 1/100,000,000th of a bitcoin, which is known as a satoshi. Throughout this book, we’ll use the term “bitcoin” to refer to any quantity of bitcoin currency, from the smallest unit (1 satoshi) to the total number (21,000,000) of all bitcoin that will ever be mined. ==== You can examine Alice's transaction to Bob's Cafe on the blockchain using a block explorer site (<>): @@ -92,7 +92,7 @@ https://blockexplorer.com/tx/0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a === Bitcoin Transactions -((("transactions", "defined")))In simple terms, a transaction tells the network that the owner of some bitcoin value has authorized the transfer of that value to another owner. The new owner can now spend the bitcoin by creating another transaction that authorizes transfer to another owner, and so on, in a chain of ownership. +((("transactions", "defined")))In simple terms, a transaction tells the network that the owner of some bitcoin value has authorized the transfer of that value to another owner. The new owner can now spend the bitcoin by creating another transaction that authorizes the transfer to another owner, and so on, in a chain of ownership. ==== Transaction Inputs and Outputs @@ -114,7 +114,7 @@ image::images/mbc2_0204.png["Transaction chain"] ==== Making Change -((("change, making")))((("change addresses")))((("addresses", "change addresses")))Many bitcoin transactions will include outputs that reference both an address of the new owner and an address of the current owner, called the _change_ address. This is because transaction inputs, like currency notes, cannot be divided. If you purchase a $5 US dollar item in a store but use a $20 US dollar bill to pay for the item, you expect to receive $15 US dollars in change. The same concept applies with bitcoin transaction inputs. If you purchased an item that costs 5 bitcoin but only had a 20 bitcoin input to use, you would send one output of 5 bitcoin to the store owner and one output of 15 bitcoin back to yourself as change (less any applicable transaction fee). Importantly, the change address does not have to be the same address as that of the input and for privacy reasons is often a new address from the owner's wallet. +((("change, making")))((("change addresses")))((("addresses", "change addresses")))Many bitcoin transactions will include outputs that reference both an address of the new owner and an address of the current owner, called the _change_ address. This is because transaction inputs, like currency notes, cannot be divided. If you purchase a $5 US dollar item in a store but use a $20 US dollar bill to pay for the item, you expect to receive $15 US dollars in change. The same concept applies to bitcoin transaction inputs. If you purchased an item that costs 5 bitcoin but only had a 20 bitcoin input to use, you would send one output of 5 bitcoin to the store owner and one output of 15 bitcoin back to yourself as change (less any applicable transaction fee). Importantly, the change address does not have to be the same address as that of the input and for privacy reasons is often a new address from the owner's wallet. Different wallets may use different strategies when aggregating inputs to make a payment requested by the user. They might aggregate many small inputs, or use one that is equal to or larger than the desired payment. Unless the wallet can aggregate inputs in such a way to exactly match the desired payment plus transaction fees, the wallet will need to generate some change. This is very similar to how people handle cash. If you always use the largest bill in your pocket, you will end up with a pocket full of loose change. If you only use the loose change, you'll always have only big bills. People subconsciously find a balance between these two extremes, and bitcoin wallet developers strive to program this balance. @@ -146,7 +146,7 @@ image::images/mbc2_0207.png["Distributing Transaction"] ==== Getting the Right Inputs -((("outputs and inputs", "locating and tracking inputs")))Alice's wallet application will first have to find inputs that can pay for the amount she wants to send to Bob. Most wallets keep track of all the available outputs belonging to addresses in the wallet. Therefore, Alice's wallet would contain a copy of the transaction output from Joe's transaction, which was created in exchange for cash (see <>). A bitcoin wallet application that runs as a full-node client actually contains a copy of every unspent output from every transaction in the blockchain. This allows a wallet to construct transaction inputs as well as quickly verify incoming transactions as having correct inputs. However, because a full-node client takes up a lot of disk space, most user wallets run "lightweight" clients that track only the user's own unspent outputs. +((("outputs and inputs", "locating and tracking inputs")))Alice's wallet application will first have to find inputs that can pay the amount she wants to send to Bob. Most wallets keep track of all the available outputs belonging to addresses in the wallet. Therefore, Alice's wallet would contain a copy of the transaction output from Joe's transaction, which was created in exchange for cash (see <>). A bitcoin wallet application that runs as a full-node client actually contains a copy of every unspent output from every transaction in the blockchain. This allows a wallet to construct transaction inputs as well as quickly verify incoming transactions as having correct inputs. However, because a full-node client takes up a lot of disk space, most user wallets run "lightweight" clients that track only the user's own unspent outputs. If the wallet application does not maintain a copy of unspent transaction outputs, it can query the bitcoin network to retrieve this information using a variety of APIs available by different providers or by asking a full-node using an application programming interface (API) call. <> shows a API request, constructed as an HTTP GET command to a specific URL. This URL will return all the unspent transaction outputs for an address, giving any application the information it needs to construct transaction inputs for spending. We use the simple command-line HTTP client _cURL_ to retrieve the response. @@ -285,4 +285,4 @@ As Bob spends the payments received from Alice and other customers, he extends t .Alice's transaction as part of a transaction chain from Joe to Gopesh image::images/mbc2_0210.png["Alice's transaction as part of a transaction chain"] -In this chapter, we saw how transactions build a chain that moves value from owner to owner. We also tracked Alice's transaction, from the moment it was created in her wallet, through the bitcoin network and to the miners who recorded it on the blockchain. In the rest of this book we will examine the specific technologies behind wallets, addresses, signatures, transactions, the network, and finally mining.((("", startref="BCover02")))((("", startref="DCSover02"))) ((("", startref="UCcoffee02"))) +In this chapter, we saw how transactions build a chain that moves value from owner to owner. We also tracked Alice's transaction, from the moment it was created in her wallet, through the bitcoin network and to the miners who recorded it on the blockchain. In the rest of this book, we will examine the specific technologies behind wallets, addresses, signatures, transactions, the network, and finally mining.((("", startref="BCover02")))((("", startref="DCSover02"))) ((("", startref="UCcoffee02"))) From a0b9d80b839ebc4c8d691541c80fe907d0939c0c Mon Sep 17 00:00:00 2001 From: Reuben Thomas Date: Sun, 26 Nov 2017 11:24:01 +0000 Subject: [PATCH 16/36] Make range of private key precise --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index db0fe5d5..1f3f04e4 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -60,7 +60,7 @@ The bitcoin private key is just a number. You can pick your private keys randoml The first and most important step in generating keys is to find a secure source of entropy, or randomness. Creating a bitcoin key is essentially the same as "Pick a number between 1 and 2^256^." The exact method you use to pick that number does not matter as long as it is not predictable or repeatable. Bitcoin software uses the underlying operating system's random number generators to produce 256 bits of entropy (randomness). Usually, the OS random number generator is initialized by a human source of randomness, which is why you may be asked to wiggle your mouse around for a few seconds. -More precisely, the private key can be any number between +1+ and +n - 1+, where n is a constant (n = 1.158 * 10^77^, slightly less than 2^256^) defined as the order of the elliptic curve used in bitcoin (see <>). To create such a key, we randomly pick a 256-bit number and check that it is less than +n - 1+. In programming terms, this is usually achieved by feeding a larger string of random bits, collected from a cryptographically secure source of randomness, into the SHA256 hash algorithm, which will conveniently produce a 256-bit number. If the result is less than +n - 1+, we have a suitable private key. Otherwise, we simply try again with another random number. +More precisely, the private key can be any number between +0+ and +n - 1+ inclusive, where n is a constant (n = 1.158 * 10^77^, slightly less than 2^256^) defined as the order of the elliptic curve used in bitcoin (see <>). To create such a key, we randomly pick a 256-bit number and check that it is less than +n+. In programming terms, this is usually achieved by feeding a larger string of random bits, collected from a cryptographically secure source of randomness, into the SHA256 hash algorithm, which will conveniently produce a 256-bit number. If the result is less than +n+, we have a suitable private key. Otherwise, we simply try again with another random number. [WARNING] ==== From b8f1dbd4a6c83a5a5a10437d1fbb6d843eefbd8c Mon Sep 17 00:00:00 2001 From: Sameer Zahid Date: Wed, 29 Nov 2017 23:11:58 +0400 Subject: [PATCH 17/36] Clearer description of the decendants in HD wallet key path table --- ch05.asciidoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ch05.asciidoc b/ch05.asciidoc index cff94a3a..291ac1d7 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -65,7 +65,7 @@ image::images/mbc2_0503.png["HD wallet"] HD wallets offer two major advantages over random (nondeterministic) keys. First, the tree structure can be used to express additional organizational meaning, such as when a specific branch of subkeys is used to receive incoming payments and a different branch is used to receive change from outgoing payments. Branches of keys can also be used in corporate settings, allocating different branches to departments, subsidiaries, specific functions, or accounting categories. -The second advantage of HD wallets is that users can create a sequence of public keys without having access to the corresponding private keys. This allows HD wallets to be used on an insecure server or in a receive-only capacity, issuing a different public key for each transaction. The public keys need to be preloaded or derived in advance, yet the server doesn't have the private keys that can spend the funds. +The second advantage of HD wallets is that users can create a sequence of public keys without having access to the corresponding private keys. This allows HD wallets to be used on an insecure server or in a receive-only capacity, issuing a different public key for each transaction. The public keys need to be preloaded or derived in advance, yet the server doesn't have the private keys that can spend the funds. ==== Seeds and Mnemonic Codes (BIP-39) @@ -452,10 +452,10 @@ The "ancestry" of a key is read from right to left, until you reach the master k |======= |HD path | Key described | m/0 | The first (0) child private key from the master private key (m) -| m/0/0 | The first grandchild private key of the first child (m/0) -| m/0'/0 | The first normal grandchild of the first _hardened_ child (m/0') -| m/1/0 | The first grandchild private key of the second child (m/1) -| M/23/17/0/0 | The first great-great-grandchild public key of the first great-grandchild of the 18th grandchild of the 24th child +| m/0/0 | The first grandchild private key from the first child (m/0) +| m/0'/0 | The first normal grandchild from the first _hardened_ child (m/0') +| m/1/0 | The first grandchild private key from the second child (m/1) +| M/23/17/0/0 | The first great-great-grandchild public key from the first great-grandchild from the 18th grandchild from the 24th child |======= ===== Navigating the HD wallet tree structure From 22e17ffd3cb183b0d0361e7175c2ce2fc73950f0 Mon Sep 17 00:00:00 2001 From: Manjeet Singh Bhatia Date: Sat, 9 Dec 2017 22:05:50 -0800 Subject: [PATCH 18/36] Update hash_example.py As input and hash are inbuilt functions, so I'd suggest using other names for variables. here is output from python interpreter. >>> hash >>> input --- code/hash_example.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/code/hash_example.py b/code/hash_example.py index 12012ac7..96b52395 100644 --- a/code/hash_example.py +++ b/code/hash_example.py @@ -9,10 +9,10 @@ text = "I am Satoshi Nakamoto" for nonce in xrange(20): # add the nonce to the end of the text - input = text + str(nonce) + input_data = text + str(nonce) # calculate the SHA-256 hash of the input (text+nonce) - hash = hashlib.sha256(input).hexdigest() + hash_data = hashlib.sha256(input_data).hexdigest() # show the input and hash result - print input, '=>', hash \ No newline at end of file + print input_data, '=>', hash_data From fc84c40e8b295e08685f256291a915c931eb6e19 Mon Sep 17 00:00:00 2001 From: Cihat Imamoglu Date: Sun, 10 Dec 2017 14:44:04 +0000 Subject: [PATCH 19/36] Update ec-math.py * Add a missing word "number" * Convert `& 1` into `% 2 == 0` for clarity --- code/ec-math.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/code/ec-math.py b/code/ec-math.py index 0ba9ed70..4afc7c1c 100644 --- a/code/ec-math.py +++ b/code/ec-math.py @@ -21,13 +21,13 @@ generator = generator_secp256k1 def random_secret(): convert_to_int = lambda array: int("".join(array).encode("hex"), 16) - # Collect 256 bits of random data from the OS's cryptographically secure random generator + # Collect 256 bits of random data from the OS's cryptographically secure random number generator byte_array = os.urandom(32) return convert_to_int(byte_array) def get_point_pubkey(point): - if point.y() & 1: + if (point.y() % 2) == 1: key = '03' + '%064x' % point.x() else: key = '02' + '%064x' % point.x() From bba5d3de25541ed593eef6c40c5678e44e1f8eda Mon Sep 17 00:00:00 2001 From: Matt McGivney Date: Wed, 2 Aug 2017 09:54:22 -0600 Subject: [PATCH 20/36] Fix minor grammatical issue Hopefully an easy one! --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 5da2d776..71be8fda 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -7,7 +7,7 @@ ((("digital keys", see="keys and addresses")))((("keys and addresses", "overview of", id="KAover04")))((("digital signatures", "purpose of")))Ownership of bitcoin is established through _digital keys_, _bitcoin addresses_, and _digital signatures_. The digital keys are not actually stored in the network, but are instead created and stored by users in a file, or simple database, called a _wallet_. The digital keys in a user's wallet are completely independent of the bitcoin protocol and can be generated and managed by the user's wallet software without reference to the blockchain or access to the internet. Keys enable many of the interesting properties of bitcoin, including decentralized trust and control, ownership attestation, and the cryptographic-proof security model. -Most bitcoin transactions requires a valid digital signature to be included in the blockchain, which can only be generated with a secret key; therefore, anyone with a copy of that key has control of the bitcoin. ((("witnesses")))The digital signature used to spend funds is also referred to as a _witness_, a term used in cryptography. The witness data in a bitcoin transaction testifies to the true ownership of the funds being spent. +Most bitcoin transactions require a valid digital signature to be included in the blockchain, which can only be generated with a secret key; therefore, anyone with a copy of that key has control of the bitcoin. ((("witnesses")))The digital signature used to spend funds is also referred to as a _witness_, a term used in cryptography. The witness data in a bitcoin transaction testifies to the true ownership of the funds being spent. ((("public and private keys", "key pairs")))((("public and private keys", see="also keys and addresses")))Keys come in pairs consisting of a private (secret) key and a public key. Think of the public key as similar to a bank account number and the private key as similar to the secret PIN, or signature on a check, that provides control over the account. These digital keys are very rarely seen by the users of bitcoin. For the most part, they are stored inside the wallet file and managed by the bitcoin wallet software. From 22a80a3789cf68ac3c99c6488cc2f0cb38c8ce73 Mon Sep 17 00:00:00 2001 From: Johannes Keyser Date: Mon, 25 Dec 2017 23:45:40 +0100 Subject: [PATCH 21/36] Two typo fixes in Ch 12. --- ch12.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index 3c609a9f..a9a653f4 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -263,7 +263,7 @@ The funding transaction consumes one or more inputs from Emma's wallet, sourcing Once the funding transaction is confirmed, Emma can start streaming video. Emma's software creates and signs a commitment transaction that changes the channel balance to credit 0.01 millibit to Fabian's address and refund 35.99 millibits back to Emma. The transaction signed by Emma consumes the 36 millibits output created by the funding transaction and creates two outputs: one for her refund, the other for Fabian's payment. The transaction is only partially signed—it requires two signatures (2-of-2), but only has Emma's signature. When Fabian's server receives this transaction, it adds the second signature (for the 2-of-2 input) and returns it to Emma together with 1 second worth of video. Now both parties have a fully signed commitment transaction that either can redeem, representing the correct up-to-date balance of the channel. Neither party broadcasts this transaction to the network. -In the next round, Emma's software creates and signs another commitment transaction (commitment #2) that consumes the _same_ 2-of-2 output from the funding transaction. The second commitment transaction allocates one output of 0.2 millibits to Fabian's address and one output of 35.98 millibits back to Emma's address. This new transaction is payment for two cumulative seconds of video. Fabian's software signs and returns the second commitment transaction, together with the another second of video. +In the next round, Emma's software creates and signs another commitment transaction (commitment #2) that consumes the _same_ 2-of-2 output from the funding transaction. The second commitment transaction allocates one output of 0.02 millibits to Fabian's address and one output of 35.98 millibits back to Emma's address. This new transaction is payment for two cumulative seconds of video. Fabian's software signs and returns the second commitment transaction, together with another second of video. In this way, Emma's software continues to send commitment transactions to Fabian's server in exchange for streaming video. The balance of the channel gradually accumulates in favor of Fabian, as Emma consumes more seconds of video. Let's say Emma watches 600 seconds (10 minutes) of video, creating and signing 600 commitment transactions. The last commitment transaction (#600) will have two outputs, splitting the balance of the channel, 6 millibits to Fabian and 30 millibits to Emma. From 080f12cdd3fd6a1e6135366c149523c8845a2166 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Philipp=20Gill=C3=A9?= Date: Sun, 31 Dec 2017 17:54:40 +0100 Subject: [PATCH 22/36] Add detail to a benefit of P2SH The bullet point previously sounded as if the long script was only stored in the UTXO set when not using P2SH, and stored on the blockchain when using P2SH. This might lead to people thinking it might lead to a smaller blockchain when the script is stored in the UTXO set *instead* of on the blockchain. But without P2SH the long script was stored both in the UTXO set *and* on the blockchain. With P2SH it's only stored on the blockchain, which is a clear advantage over not using P2SH. --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index 0ae6a2ab..9ef863c5 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -172,7 +172,7 @@ P2SH addresses hide all of the complexity, so that the person making a payment d * Complex scripts are replaced by shorter fingerprints in the transaction output, making the transaction smaller. * Scripts can be coded as an address, so the sender and the sender's wallet don't need complex engineering to implement P2SH. * P2SH shifts the burden of constructing the script to the recipient, not the sender. -* P2SH shifts the burden in data storage for the long script from the output (which is in the UTXO set) to the input (stored on the blockchain). +* P2SH shifts the burden in data storage for the long script from the output (which additionally to being stored on the blockchain is in the UTXO set) to the input (only stored on the blockchain). * P2SH shifts the burden in data storage for the long script from the present time (payment) to a future time (when it is spent). * P2SH shifts the transaction fee cost of a long script from the sender to the recipient, who has to include the long redeem script to spend it. From bacbdd90aa087e62baeb6f4c380a22daf7f4dc1a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Philipp=20Gill=C3=A9?= Date: Sun, 31 Dec 2017 18:49:18 +0100 Subject: [PATCH 23/36] Fix typo It should be "a specification" instead of "a specifications". --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index 0ae6a2ab..f485d465 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -251,7 +251,7 @@ It is important to understand the limitations of transaction +nLocktime+. The on ==== Check Lock Time Verify (CLTV) -((("Check Lock Time Verify (CLTV)", id="cltv07")))((("timelocks", "Check Lock Time Verify (CLTV)")))((("scripting", "timelocks", "Check Lock Time Verify (CLTV)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY (BIP-65)")))In December 2015, a new form of timelock was introduced to bitcoin as a soft fork upgrade. Based on a specifications in BIP-65, a new script operator called _CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language. +CLTV+ is a per-output timelock, rather than a per-transaction timelock as is the case with +nLocktime+. This allows for much greater flexibility in the way timelocks are applied. +((("Check Lock Time Verify (CLTV)", id="cltv07")))((("timelocks", "Check Lock Time Verify (CLTV)")))((("scripting", "timelocks", "Check Lock Time Verify (CLTV)")))((("bitcoin improvement proposals", "CHECKLOCKTIMEVERIFY (BIP-65)")))In December 2015, a new form of timelock was introduced to bitcoin as a soft fork upgrade. Based on a specification in BIP-65, a new script operator called _CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language. +CLTV+ is a per-output timelock, rather than a per-transaction timelock as is the case with +nLocktime+. This allows for much greater flexibility in the way timelocks are applied. In simple terms, by adding the +CLTV+ opcode in the redeem script of an output it restricts the output, so that it can only be spent after the specified time has elapsed. From c5cb729126a6b23a50465118f468a91de65f40f3 Mon Sep 17 00:00:00 2001 From: Thomas Kerin Date: Fri, 12 Jan 2018 20:55:15 +0100 Subject: [PATCH 24/36] Add bitwasp bitcoin php library --- ch03.asciidoc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ch03.asciidoc b/ch03.asciidoc index fd94f688..8ebedc52 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -774,6 +774,9 @@ https://github.com/bitcoinjs/bitcoinjs-lib[BitcoinJS] :: A pure JavaScript Bitco https://bitcoinj.github.io[bitcoinj]:: A Java full-node client library https://bitsofproof.com[Bits of Proof (BOP)]:: A Java enterprise-class implementation of bitcoin +==== PHP +https://github.com/bit-wasp/bitcoin-php[bitwasp/bitcoin]:: A PHP bitcoin library, and related projects + ==== Python https://github.com/petertodd/python-bitcoinlib[python-bitcoinlib]:: A Python bitcoin library, consensus library, and node by Peter Todd https://github.com/richardkiss/pycoin[pycoin]:: A Python bitcoin library by Richard Kiss From 164a54752d8ca0a155dc01363783e0c80f0cfa30 Mon Sep 17 00:00:00 2001 From: dkrm Date: Mon, 15 Jan 2018 13:27:34 +0100 Subject: [PATCH 25/36] fix minor typo --- glossary.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glossary.asciidoc b/glossary.asciidoc index e5d9a628..5982f8c3 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -174,7 +174,7 @@ Paper wallet:: In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes. Payment channels:: - A Micropayment Channel or Payment Channel is class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the Bitcoin block chain. 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 a class of techniques designed to allow users to make multiple Bitcoin transactions without committing all of the transactions to the Bitcoin block chain. 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. From 1aa56ce982d4b55ba2beb6c8fb0e541d9039d52d Mon Sep 17 00:00:00 2001 From: Will Binns Date: Wed, 24 Jan 2018 10:51:53 -0600 Subject: [PATCH 26/36] ch12: Fix mistake in HTLC contract definition Closes #476 --- ch12.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index 3c609a9f..bfeed9e0 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -426,13 +426,13 @@ IF ELSE # Refund after timeout. CHECKLOCKTIMEVERIFY DROP - CHECKSIG + CHECKSIG ENDIF ---- Anyone who knows the secret +R+, which when hashed equals to +H+, can redeem this output by exercising the first clause of the +IF+ flow. -If the secret is not revealed and the HTLC claimed, after a certain number of blocks the payee can claim a refund using the second clause in the +IF+ flow. +If the secret is not revealed and the HTLC claimed, after a certain number of blocks the payer can claim a refund using the second clause in the +IF+ flow. This is a basic implementation of an HTLC. This type of HTLC can be redeemed by _anyone_ who has the secret +R+. An HTLC can take many different forms with slight variations to the script. For example, adding a +CHECKSIG+ operator and a public key in the first clause restricts redemption of the hash to a named recipient, who must also know the secret +R+.((("", startref="BCApayment12"))) From c2bfbc59155b90423875f323f6c933ae4efa73e4 Mon Sep 17 00:00:00 2001 From: Will Binns Date: Wed, 24 Jan 2018 10:53:20 -0600 Subject: [PATCH 27/36] preface: Add contributor - Magomed Aliev --- preface.asciidoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/preface.asciidoc b/preface.asciidoc index ef0cf472..fd99f011 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -206,6 +206,7 @@ Following is a list of notable GitHub contributors, including their GitHub ID in * Holger Schinzel (schinzelh) * Ioannis Cherouvim (cherouvim) * Ish Ot Jr. (ishotjr) +* ivangreene * James Addison (jayaddison) * Jameson Lopp (jlopp) * Jason Bisterfeldt (jbisterfeldt) @@ -218,6 +219,7 @@ Following is a list of notable GitHub contributors, including their GitHub ID in * Jonathan Cross (jonathancross) * Jorgeminator * Kai Bakker (kaibakker) +* Magomed Aliev (30mb1) * Mai-Hsuan Chia (mhchia) * marcofalke * Marzig (marzig76) From 044d480a44a36553ed964e0db6c7f0669a413c0b Mon Sep 17 00:00:00 2001 From: Will Binns Date: Wed, 24 Jan 2018 10:56:44 -0600 Subject: [PATCH 28/36] preface: Add contributor - Darius Kramer --- preface.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/preface.asciidoc b/preface.asciidoc index fd99f011..70b46a56 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -183,6 +183,7 @@ Following is a list of notable GitHub contributors, including their GitHub ID in * Cragin Godley (cgodley) * Craig Dodd (cdodd) * dallyshalla +* Darius Kramer (dkrmr) * Diego Viola (diegoviola) * Dirk Jäckel (biafra23) * Dimitris Tsapakidis (dimitris-t) From f3662a20023fdddab3d62aa29a6ad49057ac8507 Mon Sep 17 00:00:00 2001 From: Will Binns Date: Wed, 24 Jan 2018 11:04:18 -0600 Subject: [PATCH 29/36] preface: Add contributor - Thomas Kerin --- preface.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/preface.asciidoc b/preface.asciidoc index 70b46a56..df2ba40e 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -242,6 +242,7 @@ Following is a list of notable GitHub contributors, including their GitHub ID in * Stephan Oeste (Emzy) * takaya-imai * Thiago Arrais (thiagoarrais) +* Thomas Kerin (afk11) * venzen * Will Binns (wbnns) * wintercooled From b7ac01e477f8b138913ae348d836bb3c947eb514 Mon Sep 17 00:00:00 2001 From: Will Binns Date: Wed, 24 Jan 2018 11:13:01 -0600 Subject: [PATCH 30/36] =?UTF-8?q?preface:=20Add=20contributor=20-=20Philip?= =?UTF-8?q?p=20Gill=C3=A9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- preface.asciidoc | 1 + 1 file changed, 1 insertion(+) diff --git a/preface.asciidoc b/preface.asciidoc index df2ba40e..70fb898d 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -232,6 +232,7 @@ Following is a list of notable GitHub contributors, including their GitHub ID in * Minh T. Nguyen (enderminh) * Nagaraj Hubli (nagarajhubli) * Nekomata (nekomata-3) +* Philipp Gille (philippgille) * Robert Furse (Rfurse) * Richard Kiss (richardkiss) * Ruben Alexander (hizzvizz) From 2d01be5381f81342036f780ed5c3357ade457980 Mon Sep 17 00:00:00 2001 From: Will Binns Date: Wed, 24 Jan 2018 12:00:27 -0600 Subject: [PATCH 31/36] preface: Update copyright to 2018 --- preface.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/preface.asciidoc b/preface.asciidoc index 70fb898d..85d5f2ef 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -63,7 +63,7 @@ All the code snippets use real values and calculations where possible, so that y This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. -((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos (O’Reilly). Copyright 2017 Andreas M. Antonopoulos, 978-1-491-95438-6.” +((("attribution")))We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos (O’Reilly). Copyright 2018 Andreas M. Antonopoulos, 978-1-491-95438-6.” ((("open source licenses")))Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply. From 5460eb7a8d7d674facdae1a6d541933c7fda737c Mon Sep 17 00:00:00 2001 From: ZhaoChunsheng <9263377+ChunshengZhao@users.noreply.github.com> Date: Sat, 27 Jan 2018 21:56:25 +0800 Subject: [PATCH 32/36] Update key-to-address-ecc-example.py The code is very possible to miss a leading '0'. E.g: Private Key (hex) is: 57c003d31cca32f79a22e70334fff37875617e89c04d2746b5efc22067ccb8fd Before: Compressed Public Key (hex) is: 03 8f0de2360796ae0fe17f1a2b0be30af6fb45eccc4a1c7afb5ebea21d041b6e0 After: Compressed Public Key (hex) is: 03 08f0de2360796ae0fe17f1a2b0be30af6fb45eccc4a1c7afb5ebea21d041b6e0 The bug is in the pybitcointools, but it is not updated, we can only repair it ourselves. --- code/key-to-address-ecc-example.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/code/key-to-address-ecc-example.py b/code/key-to-address-ecc-example.py index 2a206535..72f958a1 100644 --- a/code/key-to-address-ecc-example.py +++ b/code/key-to-address-ecc-example.py @@ -35,7 +35,7 @@ print("Public Key (hex) is:", hex_encoded_public_key) # Compress public key, adjust prefix depending on whether y is even or odd (public_key_x, public_key_y) = public_key compressed_prefix = '02' if (public_key_y % 2) == 0 else '03' -hex_compressed_public_key = compressed_prefix + bitcoin.encode(public_key_x, 16) +hex_compressed_public_key = compressed_prefix + (bitcoin.encode(public_key_x, 16).zfill(64)) print("Compressed Public Key (hex) is:", hex_compressed_public_key) # Generate bitcoin address from public key From 72f8b77dc20f721d2c35d2ae476f83c398acc0f1 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Sat, 27 Jan 2018 08:29:15 -0600 Subject: [PATCH 33/36] Added info on PDF, license & reading this book --- README.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/README.md b/README.md index 7ba66c6a..f98c5f7e 100644 --- a/README.md +++ b/README.md @@ -8,6 +8,16 @@ This repository contains the complete [first edition](https://github.com/bitcoin 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). 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 forms can be found on his website https://antonopoulos.com/ +# Reading this book (Where is the PDF?) + +To read this book, see 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. Convenience costs money (see below). + +The 2nd edition of "Mastering Bitcoin" is available under a CC-BY-NC-ND license, not a CC-BY-SA license. + +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 and 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 PDF and translations will be allowed. Until then, making PDF copies violates the license and hurts 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 agree to even 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): Programming the Open Blockchain" is now available in paperback and e-book formats by many book sellers, worldwide: From 9f67e5694ad800c9bc044cf9fa0f6ea979d90551 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Fri, 2 Feb 2018 14:15:55 -0600 Subject: [PATCH 34/36] Undo "centrally trusted" I think the original wording conveys the meaning I intended better. It is not that the authority is trusted centrally. It is a central authority that is trusted. --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index b98dc781..29a95e3e 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -54,7 +54,7 @@ Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibil .A Solution to a Distributed Computing Problem **** -((("Byzantine Generals' Problem")))Satoshi Nakamoto's invention is also a practical and novel solution to a problem in distributed computing, known as the "Byzantine Generals' Problem." Briefly, the problem consists of trying to agree on a course of action or the state of a system by exchanging information over an unreliable and potentially compromised network. ((("central trusted authority")))Satoshi Nakamoto's solution, which uses the concept of Proof-of-Work to achieve consensus _without a centrally trusted authority_, represents a breakthrough in distributed computing and has wide applicability beyond currency. It can be used to achieve consensus on decentralized networks to prove the fairness of elections, lotteries, asset registries, digital notarization, and more. +((("Byzantine Generals' Problem")))Satoshi Nakamoto's invention is also a practical and novel solution to a problem in distributed computing, known as the "Byzantine Generals' Problem." Briefly, the problem consists of trying to agree on a course of action or the state of a system by exchanging information over an unreliable and potentially compromised network. ((("central trusted authority")))Satoshi Nakamoto's solution, which uses the concept of Proof-of-Work to achieve consensus _without a central trusted authority_, represents a breakthrough in distributed computing and has wide applicability beyond currency. It can be used to achieve consensus on decentralized networks to prove the fairness of elections, lotteries, asset registries, digital notarization, and more. **** From 0bbc3cae6d14c0e450c0e39d86a41229ad11f245 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Fri, 2 Feb 2018 14:18:32 -0600 Subject: [PATCH 35/36] Update to reflect high fees Testing several wallets by moving money is not cheap anymore. Instead, test several wallets by moving the keys or seeds between them. --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index 29a95e3e..ab3ecf46 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -92,7 +92,7 @@ Each of these stories is based on the real people and real industries currently ==== Choosing a Bitcoin Wallet -((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. It is therefore impossible to recommend a specific brand or wallet. However, we can categorize bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. Better yet, moving money between bitcoin wallets is easy, cheap, and fast, so it is worth trying out several different wallets until you find one that fits your needs. +((("security", "wallet selection")))Bitcoin wallets are one of the most actively developed applications in the bitcoin ecosystem. There is intense competition, and while a new wallet is probably being developed right now, several wallets from last year are no longer actively maintained. Many wallets focus on specific platforms or specific uses and some are more suitable for beginners while others are filled with features for advanced users. Choosing a wallet is highly subjective and depends on the use and user expertise. It is therefore impossible to recommend a specific brand or wallet. However, we can categorize bitcoin wallets according to their platform and function and provide some clarity about all the different types of wallets that exist. Better yet, moving keys or seeds between bitcoin wallets is relatively easy, so it is worth trying out several different wallets until you find one that fits your needs. [role="pagebreak-before"] Bitcoin wallets can be categorized as follows, according to the platform: From 061443e0674a36b3aeb9f431f4520962bc7bf1df Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Fri, 2 Feb 2018 14:20:20 -0600 Subject: [PATCH 36/36] Updated "largest value ever Tx" --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index 6d09d867..5bd8b511 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -47,7 +47,7 @@ When cryptography started becoming more broadly available and understood in the ((("Nakamoto, Satoshi")))((("distributed computing")))((("bitcoin", "history of")))Bitcoin was invented in 2008 with the publication of a paper titled "Bitcoin: A Peer-to-Peer Electronic Cash System,"footnote:["Bitcoin: A Peer-to-Peer Electronic Cash System," Satoshi Nakamoto (https://bitcoin.org/bitcoin.pdf).] written under the alias of Satoshi Nakamoto (see <>). Nakamoto combined several prior inventions such as b-money and HashCash to create a completely decentralized electronic cash system that does not rely on a central authority for currency issuance or settlement and validation of transactions. ((("Proof-of-Work algorithm")))((("decentralized systems", "consensus in")))((("mining and consensus", "Proof-of-Work algorithm")))The key innovation was to use a distributed computation system (called a "Proof-of-Work" algorithm) to conduct a global "election" every 10 minutes, allowing the decentralized network to arrive at _consensus_ about the state of transactions. ((("double-spend problem")))((("spending bitcoin", "double-spend problem")))This elegantly solves the issue of double-spend where a single currency unit can be spent twice. Previously, the double-spend problem was a weakness of digital currency and was addressed by clearing all transactions through a central clearinghouse. -The bitcoin network started in 2009, based on a reference implementation published by Nakamoto and since revised by many other programmers. The implementation of the Proof-of-Work algorithm (mining) that provides security and resilience for bitcoin has increased in power exponentially, and now exceeds the combined processing power of the world's top supercomputers. Bitcoin's total market value has at times exceeded $135 billion US dollars, depending on the bitcoin-to-dollar exchange rate. The largest transaction processed so far by the network was $150 million US dollars, transmitted instantly and processed without any fees. +The bitcoin network started in 2009, based on a reference implementation published by Nakamoto and since revised by many other programmers. The implementation of the Proof-of-Work algorithm (mining) that provides security and resilience for bitcoin has increased in power exponentially, and now exceeds the combined processing power of the world's top supercomputers. Bitcoin's total market value has at times exceeded $135 billion US dollars, depending on the bitcoin-to-dollar exchange rate. The largest transaction processed so far by the network was $400 million US dollars, transmitted instantly and processed for a fee of $1. Satoshi Nakamoto withdrew from the public in April 2011, leaving the responsibility of developing the code and network to a thriving group of volunteers. The identity of the person or people behind bitcoin is still unknown. ((("open source licenses")))However, neither Satoshi Nakamoto nor anyone else exerts individual control over the bitcoin system, which operates based on fully transparent mathematical principles, open source code, and consensus among participants. The invention itself is groundbreaking and has already spawned new science in the fields of distributed computing, economics, and econometrics.