From dd17f8a4227cc28bc33b1d1785f7ddd5565ab918 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Wed, 25 Nov 2020 21:18:39 +0100 Subject: [PATCH 01/60] ch10: 'support'->'provide(s) support for'; add 'string'; add 'finally,' --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 48c46673..8aad793e 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -338,7 +338,7 @@ The first byte, +03+, instructs the script execution engine to push the next thr The next few hexadecimal digits (+0385840206+) are used to encode an extra _nonce_ (see <>), or random value, used to find a suitable Proof-of-Work solution. -((("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. +((("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 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. <> uses the libbitcoin library introduced in <> to extract the coinbase data from the genesis block, displaying Satoshi's message. Note that the libbitcoin library contains a static copy of the genesis block, so the example code can retrieve the genesis block directly from the library. From 21597f5cf9bc46aea569ed327756feab53a79a39 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 15 Jan 2021 17:23:43 +0100 Subject: [PATCH 02/60] ch01: add space after comma and before i.e. --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index e36e61cd..16d38595 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -10,7 +10,7 @@ Users can transfer bitcoin over the network to do just about anything that can b Unlike traditional currencies, bitcoin is entirely virtual. There are no physical coins or even digital coins per se. The coins are implied in transactions that transfer value from sender to recipient. Users of bitcoin own keys that allow them to prove ownership of bitcoin in the bitcoin network. With these keys, they can sign transactions to unlock the value and spend it by transferring it to a new owner. Keys are often stored in a digital wallet on each user’s computer or smartphone. Possession of the key that can sign a transaction is the only prerequisite to spending bitcoin, putting the control entirely in the hands of each user. -Bitcoin is a distributed, peer-to-peer system. As such, there is no "central" server or point of control. Bitcoins,i.e. units of bitcoin, are created through a process called "mining," which involves competing to find solutions to a mathematical problem while processing bitcoin transactions. Any participant in the bitcoin network (i.e., anyone using a device running the full bitcoin protocol stack) may operate as a miner, using their computer's processing power to verify and record transactions. Every 10 minutes, on average, a bitcoin miner can validate the transactions of the past 10 minutes and is rewarded with brand new bitcoin. Essentially, bitcoin mining decentralizes the currency-issuance and clearing functions of a central bank and replaces the need for any central bank. +Bitcoin is a distributed, peer-to-peer system. As such, there is no "central" server or point of control. Bitcoins, i.e. units of bitcoin, are created through a process called "mining," which involves competing to find solutions to a mathematical problem while processing bitcoin transactions. Any participant in the bitcoin network (i.e., anyone using a device running the full bitcoin protocol stack) may operate as a miner, using their computer's processing power to verify and record transactions. Every 10 minutes, on average, a bitcoin miner can validate the transactions of the past 10 minutes and is rewarded with brand new bitcoin. Essentially, bitcoin mining decentralizes the currency-issuance and clearing functions of a central bank and replaces the need for any central bank. The bitcoin protocol includes built-in algorithms that regulate the mining function across the network. The difficulty of the processing task that miners must perform is adjusted dynamically so that, on average, someone succeeds every 10 minutes regardless of how many miners (and how much processing) are competing at any moment. The protocol also halves the rate at which new bitcoin is created every 4 years, and limits the total number of bitcoin that will be created to a fixed total just below 21 million coins. The result is that the number of bitcoin in circulation closely follows an easily predictable curve that approaches 21 million by the year 2140. Due to bitcoin's diminishing rate of issuance, over the long term, the bitcoin currency is deflationary. Furthermore, bitcoin cannot be inflated by "printing" new money above and beyond the expected issuance rate. From f467afe0282953a990353c0ff554df25db952563 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Mon, 18 Jan 2021 20:43:05 +0100 Subject: [PATCH 03/60] ch08: delete extra space --- ch08.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch08.asciidoc b/ch08.asciidoc index b5e4f7bd..29453037 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -22,7 +22,7 @@ All nodes include the routing function to participate in the network and might i ((("full-node clients")))Some nodes, called full nodes, also maintain a complete and up-to-date copy of the blockchain. Full nodes can autonomously and authoritatively verify any transaction without external reference. ((("simple-payment-verification (SPV)")))Some nodes maintain only a subset of the blockchain and verify transactions using a method called _simplified payment verification_, or SPV. ((("lightweight clients")))These nodes are known as SPV nodes or lightweight nodes. In the full-node example in the figure, the full-node blockchain database function is indicated by a circle called "Full Blockchain" or the letter "B." In <>, SPV nodes are drawn without the "B" circle, showing that they do not have a full copy of the blockchain. -((("bitcoin nodes", "mining nodes")))((("mining and consensus", "mining nodes")))((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work algorithm")))Mining nodes compete to create new blocks by running specialized hardware to solve the Proof-of-Work algorithm. Some mining nodes are also full nodes, maintaining a full copy of the blockchain, while others are lightweight nodes participating in pool mining and depending on a pool server to maintain a full node. The mining function is shown in the full node as a circle called "Miner" or the letter "M." +((("bitcoin nodes", "mining nodes")))((("mining and consensus", "mining nodes")))((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work algorithm")))Mining nodes compete to create new blocks by running specialized hardware to solve the Proof-of-Work algorithm. Some mining nodes are also full nodes, maintaining a full copy of the blockchain, while others are lightweight nodes participating in pool mining and depending on a pool server to maintain a full node. The mining function is shown in the full node as a circle called "Miner" or the letter "M." User wallets might be part of a full node, as is usually the case with desktop bitcoin clients. Increasingly, many user wallets, especially those running on resource-constrained devices such as smartphones, are SPV nodes. The wallet function is shown in <> as a circle called "Wallet" or the letter "W." From 57f0d77d40d037eb31787831d271b396958e1588 Mon Sep 17 00:00:00 2001 From: marco zandonadi <77648377+myrddin0@users.noreply.github.com> Date: Mon, 18 Jan 2021 19:40:45 -0800 Subject: [PATCH 04/60] Update ch03.asciidoc Indefinite article "a" should precede a noun starting with a consonant --- ch03.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch03.asciidoc b/ch03.asciidoc index 5d06183b..f66fd4c3 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -25,7 +25,7 @@ image::images/mbc2_0301.png["Bitcoin Core Architecture"] [[compiling_core]] === Compiling Bitcoin Core from the Source Code -((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as a archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g., +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. +((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as an archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g., +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. [TIP] ==== From 555be41b2bab0ad88f45e1a0ea984df76b21a3d6 Mon Sep 17 00:00:00 2001 From: Ning Shang Date: Mon, 18 Jan 2021 19:59:41 -0800 Subject: [PATCH 05/60] ch07: 2-of-5 instead of 2-of-3 for Mohammed's example The example is a 2-of-5 multisig, according to the Pay-to-Script-Hash example description earlier, and the P2SH example a few lines below. --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index ebbc82f6..f029e293 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -761,7 +761,7 @@ The ((("use cases", "import/export", id="mohamappd")))second type of witness pro HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL ---- -This P2SH script references the hash of a _redeem script_ that defines a 2-of-3 multisignature requirement to spend funds. To spend this output, Mohammed's company would present the redeem script (whose hash matches the script hash in the P2SH output) and the signatures necessary to satisfy that redeem script, all inside the transaction input: +This P2SH script references the hash of a _redeem script_ that defines a 2-of-5 multisignature requirement to spend funds. To spend this output, Mohammed's company would present the redeem script (whose hash matches the script hash in the P2SH output) and the signatures necessary to satisfy that redeem script, all inside the transaction input: .Decoded transaction showing a P2SH output being spent ---- From 06f1a947e919533d396573534c95c0a6f2ef2165 Mon Sep 17 00:00:00 2001 From: Ning Shang Date: Mon, 18 Jan 2021 20:21:33 -0800 Subject: [PATCH 06/60] chp04: xref <> seems better for note on std:random_device Because 'std::random_device' appears in xref vanity_miner_code as opposed to xref vanity_miner_run, it feels more appropriate to use the former in this note. --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..7ed2c800 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -713,7 +713,7 @@ include::code/vanity-miner.cpp[] [NOTE] ==== -<> uses +std::random_device+. Depending on the implementation it may reflect a CSRNG provided by the underlying operating system. In the case of a Unix-like operating system such as Linux, it draws from +/dev/urandom+. The random number generator used here is for demonstration purposes, and it is _not_ appropriate for generating production-quality bitcoin keys as it is not implemented with sufficient security. +<> uses +std::random_device+. Depending on the implementation it may reflect a CSRNG provided by the underlying operating system. In the case of a Unix-like operating system such as Linux, it draws from +/dev/urandom+. The random number generator used here is for demonstration purposes, and it is _not_ appropriate for generating production-quality bitcoin keys as it is not implemented with sufficient security. ==== The example code must be compiled using a pass:[C++] compiler and linked against the libbitcoin library (which must be first installed on that system). To run the example, run the ++vanity-miner++ executable with no parameters (see <>) and it will attempt to find a vanity address starting with "1kid." From c942d694b695084e00719a62c7bf9d75ac159fe9 Mon Sep 17 00:00:00 2001 From: Ning Shang Date: Mon, 18 Jan 2021 20:34:10 -0800 Subject: [PATCH 07/60] ch07: Typo fixes Fix minor typos related to 'equal to' and 'less/greater than'. --- ch07.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index f029e293..d7a76c4f 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -310,9 +310,9 @@ To lock it to a time, say 3 months from now, the transaction would be a P2SH tra where ++ is a block height or time value estimated 3 months from the time the transaction is mined: current block height {plus} 12,960 (blocks) or current Unix epoch time {plus} 7,760,000 (seconds). For now, don't worry about the +DROP+ opcode that follows +CHECKLOCKTIMEVERIFY+; it will be explained shortly. -When Bob tries to spend this UTXO, he constructs a transaction that references the UTXO as an input. He uses his signature and public key in the unlocking script of that input and sets the transaction +nLocktime+ to be equal or greater to the timelock in the +CHECKLOCKTIMEVERIFY+ Alice set. Bob then broadcasts the transaction on the bitcoin network. +When Bob tries to spend this UTXO, he constructs a transaction that references the UTXO as an input. He uses his signature and public key in the unlocking script of that input and sets the transaction +nLocktime+ to be equal to or greater than the timelock in the +CHECKLOCKTIMEVERIFY+ Alice set. Bob then broadcasts the transaction on the bitcoin network. -Bob's transaction is evaluated as follows. If the +CHECKLOCKTIMEVERIFY+ parameter Alice set is less than or equal the spending transaction's +nLocktime+, script execution continues (acts as if a “no operation” or NOP opcode was executed). Otherwise, script execution halts and the transaction is deemed invalid. +Bob's transaction is evaluated as follows. If the +CHECKLOCKTIMEVERIFY+ parameter Alice set is less than or equal to the spending transaction's +nLocktime+, script execution continues (acts as if a “no operation” or NOP opcode was executed). Otherwise, script execution halts and the transaction is deemed invalid. More precisely, +CHECKLOCKTIMEVERIFY+ fails and halts execution, marking the transaction invalid if (source: BIP-65): From 7284634837f155347ca1aaeed9485bc9800f3193 Mon Sep 17 00:00:00 2001 From: Ning Shang Date: Mon, 18 Jan 2021 20:51:12 -0800 Subject: [PATCH 08/60] Nit: exponentially -> significantly In the dice rolling example, because there are only two dice, the phrase 'exponentially more' could cause confusion. It feels better to be a bit handwavy here and just say 'significantly more'. --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 33fa6954..4b927db9 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -492,7 +492,7 @@ The number used as a variable in such a scenario is called a _nonce_. The nonce To make a challenge out of this algorithm, let's set a target: find a phrase that produces a hexadecimal hash that starts with a zero. Fortunately, this isn't difficult! <> shows that the phrase "I am Satoshi Nakamoto13" produces the hash +0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5+, which fits our criteria. It took 13 attempts to find it. In terms of probabilities, if the output of the hash function is evenly distributed we would expect to find a result with a 0 as the hexadecimal prefix once every 16 hashes (one out of 16 hexadecimal digits 0 through F). In numerical terms, that means finding a hash value that is less than +0x1000000000000000000000000000000000000000000000000000000000000000+. We call this threshold the _target_ and the goal is to find a hash that is numerically less than the target. If we decrease the target, the task of finding a hash that is less than the target becomes more and more difficult. -To give a simple analogy, imagine a game where players throw a pair of dice repeatedly, trying to throw less than a specified target. In the first round, the target is 12. Unless you throw double-six, you win. In the next round the target is 11. Players must throw 10 or less to win, again an easy task. Let's say a few rounds later the target is down to 5. Now, more than half the dice throws will exceed the target and therefore be invalid. It takes exponentially more dice throws to win, the lower the target gets. Eventually, when the target is 2 (the minimum possible), only one throw out of every 36, or 2% of them, will produce a winning result. +To give a simple analogy, imagine a game where players throw a pair of dice repeatedly, trying to throw less than a specified target. In the first round, the target is 12. Unless you throw double-six, you win. In the next round the target is 11. Players must throw 10 or less to win, again an easy task. Let's say a few rounds later the target is down to 5. Now, more than half the dice throws will exceed the target and therefore be invalid. It takes significantly more dice throws to win, the lower the target gets. Eventually, when the target is 2 (the minimum possible), only one throw out of every 36, or 2% of them, will produce a winning result. From the perspective of an observer who knows that the target of the dice game is 2, if someone has succeeded in casting a winning throw it can be assumed that they attempted, on average, 36 throws. In other words, one can estimate the amount of work it takes to succeed from the difficulty imposed by the target. When the algorithm is based on a deterministic function such as SHA256, the input itself constitutes _proof_ that a certain amount of _work_ was done to produce a result below the target. Hence, _Proof-of-Work_. From 65dd6b8be0305b01c784c965abbe478463b74e6d Mon Sep 17 00:00:00 2001 From: jerzybrzoska <51721153+jerzybrzoska@users.noreply.github.com> Date: Tue, 19 Jan 2021 13:05:10 +0100 Subject: [PATCH 09/60] ch.02: Let us not be too assuming about the gender of "each miner" It is too assuming to suppose that the gender of "each miner" is masculine. Hence I propose to use [singular they](https://en.wikipedia.org/wiki/Singular_they). More on singular they [here](https://www.grammarly.com/blog/use-the-singular-they/). 'He' was substituted with 'they' only when it refers to "each miner", i.e. miners in general, and not when it refers to Jing. In the latter case I have left he unchanged. --- ch02.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index d70afc43..d4079ec5 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -254,7 +254,7 @@ Jing started mining in 2010 using a very fast desktop computer to find a suitabl ((("blocks", "mining transactions in")))New transactions are constantly flowing into the network from user wallets and other applications. As these are seen by the bitcoin network nodes, they get added to a temporary pool of unverified transactions maintained by each node. As miners construct a new block, they add unverified transactions from this pool to the new block and then attempt to prove the validity of that new block, with the mining algorithm (Proof-of-Work). The process of mining is explained in detail in <>. -Transactions are added to the new block, prioritized by the highest-fee transactions first and a few other criteria. Each miner starts the process of mining a new block of transactions as soon as he receives the previous block from the network, knowing he has lost that previous round of competition. He immediately creates a new block, fills it with transactions and the fingerprint of the previous block, and starts calculating the Proof-of-Work for the new block. Each miner includes a special transaction in his block, one that pays his own bitcoin address the block reward (currently 6.25 newly created bitcoin) plus the sum of transaction fees from all the transactions included in the block. If he finds a solution that makes that block valid, he "wins" this reward because his successful block is added to the global blockchain and the reward transaction he included becomes spendable. ((("mining pools", "operation of")))Jing, who participates in a mining pool, has set up his software to create new blocks that assign the reward to a pool address. From there, a share of the reward is distributed to Jing and other miners in proportion to the amount of work they contributed in the last round. +Transactions are added to the new block, prioritized by the highest-fee transactions first and a few other criteria. Each miner starts the process of mining a new block of transactions as soon as they receive the previous block from the network, knowing they have lost that previous round of competition. They immediately create a new block, fill it with transactions and the fingerprint of the previous block, and start calculating the Proof-of-Work for the new block. Each miner includes a special transaction in their block, one that pays their own bitcoin address the block reward (currently 6.25 newly created bitcoin) plus the sum of transaction fees from all the transactions included in the block. If they find a solution that makes that block valid, they "win" this reward because their successful block is added to the global blockchain and the reward transaction they included becomes spendable. ((("mining pools", "operation of")))Jing, who participates in a mining pool, has set up his software to create new blocks that assign the reward to a pool address. From there, a share of the reward is distributed to Jing and other miners in proportion to the amount of work they contributed in the last round. ((("candidate blocks")))((("blocks", "candidate blocks")))Alice's transaction was picked up by the network and included in the pool of unverified transactions. Once validated by the mining software it was included in a new block, called a _candidate block_, generated by Jing's mining pool. All the miners participating in that mining pool immediately start computing Proof-of-Work for the candidate block. Approximately five minutes after the transaction was first transmitted by Alice's wallet, one of Jing's ASIC miners found a solution for the candidate block and announced it to the network. Once other miners validated the winning block they started the race to generate the next block. From 2da27d33c0e0c692503a62d13c59f2e8df59eb43 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Wed, 20 Jan 2021 20:57:14 +0100 Subject: [PATCH 10/60] ch08: outputs -> output --- ch08.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch08.asciidoc b/ch08.asciidoc index b5e4f7bd..ad7636f3 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -270,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 outputs 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 output 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 <>) for each matching transaction. The peer will then also send +tx+ messages containing the transactions matched by the filter. From 442f6f74e98ec66d3b1db309aa737ea891e62748 Mon Sep 17 00:00:00 2001 From: Sandro Conforto Date: Wed, 20 Jan 2021 21:35:52 +0100 Subject: [PATCH 11/60] ch06: Typo fixes Fix a minor punctuation typo --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index bbc7922e..75d8dce8 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -369,7 +369,7 @@ In this section, we will demonstrate the basic components of the bitcoin transac [TIP] ==== -((("programmable money")))Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. This is how bitcoin gets the power of "programmable money." +((("programmable money")))Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language. This language allows for a nearly infinite variety of conditions to be expressed. This is how bitcoin gets the power of "programmable money". ==== From ab67789c984838d9e2eebe79ec4f49a5ea728cf4 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Thu, 21 Jan 2021 08:55:00 +0100 Subject: [PATCH 12/60] ch08: delete extra space before "These two BIPs" --- ch08.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch08.asciidoc b/ch08.asciidoc index b5e4f7bd..f418bb88 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -311,7 +311,7 @@ You can find more instructions on running Bitcoin Core as a Tor hidden service i ==== Peer-to-Peer Authentication and Encryption -((("Peer-to-Peer authentication and encryption")))((("bitcoin improvement proposals", "Peer Authentication (BIP-150)")))((("bitcoin improvement proposals", "Peer-to-Peer Communication Encryption (BIP-151)")))Two Bitcoin Improvement Proposals, BIP-150 and BIP-151, add support for P2P authentication and encryption in the bitcoin P2P network. These two BIPs define optional services that may be offered by compatible bitcoin nodes. BIP-151 enables negotiated encryption for all communications between two nodes that support BIP-151. BIP-150 offers optional peer authentication that allows nodes to authenticate each other's identity using ECDSA and private keys. BIP-150 requires that prior to authentication the two nodes have established encrypted communications as per BIP-151. +((("Peer-to-Peer authentication and encryption")))((("bitcoin improvement proposals", "Peer Authentication (BIP-150)")))((("bitcoin improvement proposals", "Peer-to-Peer Communication Encryption (BIP-151)")))Two Bitcoin Improvement Proposals, BIP-150 and BIP-151, add support for P2P authentication and encryption in the bitcoin P2P network. These two BIPs define optional services that may be offered by compatible bitcoin nodes. BIP-151 enables negotiated encryption for all communications between two nodes that support BIP-151. BIP-150 offers optional peer authentication that allows nodes to authenticate each other's identity using ECDSA and private keys. BIP-150 requires that prior to authentication the two nodes have established encrypted communications as per BIP-151. As of January 2017, BIP-150 and BIP-151 are not implemented in Bitcoin Core. However, the two proposals have been implemented by at least one alternative bitcoin client named bcoin. From d06e7c54bf9a45a09dad2d95552ade0aa786ff5a Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Thu, 21 Jan 2021 09:21:47 +0100 Subject: [PATCH 13/60] glossary: BIP32 -> BIP-32 --- glossary.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/glossary.asciidoc b/glossary.asciidoc index 03764ccf..df0b815d 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -84,10 +84,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 (BIP32), which allows creating child keys from parent keys in a hierarchy. + The Hierarchical Deterministic (HD) key creation and transfer protocol (BIP-32), which allows creating child keys from parent keys in a hierarchy. HD wallet:: - Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP32). + Wallets using the Hierarchical Deterministic (HD Protocol) key creation and transfer protocol (BIP-32). HD wallet seed:: HD wallet seed or root seed is a potentially-short value used as a seed to generate the master private key and master chain code for an HD wallet. From eef7d4308be93537b0227d57c466e5b9577f92d8 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 22 Jan 2021 00:21:48 +0100 Subject: [PATCH 14/60] ch04: sentence is about vanity pool, not pool in general --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..fc9ad8f5 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -698,7 +698,7 @@ Let's look at the pattern "1Kids" as a number and see how frequently we might fi As you can see, Eugenia won't be creating the vanity address "1KidsCharity" anytime soon, even if she had access to several thousand computers. Each additional character increases the difficulty by a factor of 58. Patterns with more than seven characters are usually found by specialized hardware, such as custom-built desktops with multiple GPUs. These are often repurposed bitcoin mining "rigs" that are no longer profitable for bitcoin mining but can be used to find vanity addresses. Vanity searches on GPU systems are many orders of magnitude faster than on a general-purpose CPU. -Another way to find a vanity address is to outsource the work to a pool of vanity miners, such as the pool at http://vanitypool.appspot.com[Vanity Pool]. A pool is a service that allows those with GPU hardware to earn bitcoin searching for vanity addresses for others. For a small payment (0.01 bitcoin or approximately $5 at the time of this writing), Eugenia can outsource the search for a seven-character pattern vanity address and get results in a few hours instead of having to run a CPU search for months. +Another way to find a vanity address is to outsource the work to a pool of vanity miners, such as the pool at http://vanitypool.appspot.com[Vanity Pool]. A pool of this type is a service that allows those with GPU hardware to earn bitcoin searching for vanity addresses for others. For a small payment (0.01 bitcoin or approximately $5 at the time of this writing), Eugenia can outsource the search for a seven-character pattern vanity address and get results in a few hours instead of having to run a CPU search for months. Generating a vanity address is a brute-force exercise: try a random key, check the resulting address to see if it matches the desired pattern, repeat until successful. <> shows an example of a "vanity miner," a program designed to find vanity addresses, written in C++. The example uses the libbitcoin library, which we introduced in <>. From 39d0111fe21fcccb0dcd2ea2da29d212db271543 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 22 Jan 2021 14:19:29 +0100 Subject: [PATCH 15/60] glossary: start a new sentence in"P2SH address" --- glossary.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glossary.asciidoc b/glossary.asciidoc index 03764ccf..efdf3b38 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -159,7 +159,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, 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. + P2SH addresses are Base58Check encodings of the 20-byte hash of a script. They use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". P2SH addresses hide all of the complexity, so that the person making a payment does not see the script. P2WPKH:: The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified. From 71666cbb54043ed8bb1149461387a276ba780b13 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 23 Jan 2021 03:59:50 +0100 Subject: [PATCH 16/60] =?UTF-8?q?ch10:=20replace=20-=20by=20=E2=80=93=20in?= =?UTF-8?q?=20Total=20Fees=20equation?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 33fa6954..0f8f3f8a 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -247,7 +247,7 @@ Unlike regular transactions, the coinbase transaction does not consume (spend) U ((("coinbase transactions", "rewards and fees")))((("fees", "transaction fees")))((("mining and consensus", "rewards and fees")))To construct the coinbase transaction, Jing's node first calculates the total amount of transaction fees by adding all the inputs and outputs of the 418 transactions that were added to the block. The fees are calculated as: ---- -Total Fees = Sum(Inputs) - Sum(Outputs) +Total Fees = Sum(Inputs) – Sum(Outputs) ---- In block 277,316, the total transaction fees are 0.09094928 bitcoin. From bbc3572fdc606a0a051be8431e8cd915b06cf924 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 23 Jan 2021 18:51:10 +0100 Subject: [PATCH 17/60] ch04: add . to end sentence --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..17aff698 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -471,7 +471,7 @@ To resolve this issue, when private keys are exported from a wallet, the WIF tha [[comp_priv]] ===== Compressed private keys -((("public and private keys", "compressed private keys")))Ironically, the term "compressed private key" is a misnomer, because when a private key is exported as WIF-compressed it is actually one byte _longer_ than an "uncompressed" private key. That is because the private key has an added one-byte suffix (shown as 01 in hex in <>), which signifies that the private key is from a newer wallet and should only be used to produce compressed public keys. Private keys are not themselves compressed and cannot be compressed. The term "compressed private key" really means "private key from which only compressed public keys should be derived," whereas "uncompressed private key" really means "private key from which only uncompressed public keys should be derived." You should only refer to the export format as "WIF-compressed" or "WIF" and not refer to the private key itself as "compressed" to avoid further confusion +((("public and private keys", "compressed private keys")))Ironically, the term "compressed private key" is a misnomer, because when a private key is exported as WIF-compressed it is actually one byte _longer_ than an "uncompressed" private key. That is because the private key has an added one-byte suffix (shown as 01 in hex in <>), which signifies that the private key is from a newer wallet and should only be used to produce compressed public keys. Private keys are not themselves compressed and cannot be compressed. The term "compressed private key" really means "private key from which only compressed public keys should be derived," whereas "uncompressed private key" really means "private key from which only uncompressed public keys should be derived." You should only refer to the export format as "WIF-compressed" or "WIF" and not refer to the private key itself as "compressed" to avoid further confusion. <> shows the same key, encoded in WIF and WIF-compressed formats. From 5ecbf39068b36c3d4253b6d62d4fd0f6ef98f740 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 24 Jan 2021 23:58:15 +0100 Subject: [PATCH 18/60] ch06: explaining that the change "gift" goes to the miner --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index bbc7922e..6295bd3b 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -344,7 +344,7 @@ For example, if you consume a 20-bitcoin UTXO to make a 1-bitcoin payment, you m [WARNING] ==== -((("warnings and cautions", "change outputs")))If you forget to add a change output in a manually constructed transaction, you will be paying the change as a transaction fee. "Keep the change!" might not be what you intended. +((("warnings and cautions", "change outputs")))If you forget to add a change output in a manually constructed transaction, you will be paying the change as a transaction fee. Saying "Keep the change!" to the miner might not be what you really intended. ==== ((("use cases", "buying coffee")))Let's see how this works in practice, by looking at Alice's coffee purchase again. Alice wants to spend 0.015 bitcoin to pay for coffee. To ensure this transaction is processed promptly, she will want to include a transaction fee, say 0.001. That will mean that the total cost of the transaction will be 0.016. Her wallet must therefore source a set of UTXO that adds up to 0.016 bitcoin or more and, if necessary, create change. Let's say her wallet has a 0.2-bitcoin UTXO available. It will therefore need to consume this UTXO, create one output to Bob's Cafe for 0.015, and a second output with 0.184 bitcoin in change back to her own wallet, leaving 0.001 bitcoin unallocated, as an implicit fee for the transaction. From 2feb6ac3c376dcefaba43da37a816fa4e1aee42c Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Tue, 26 Jan 2021 08:56:45 +0100 Subject: [PATCH 19/60] ch06: a -> this --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index bbc7922e..370f6907 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -311,7 +311,7 @@ Fee estimation algorithms calculate the appropriate fee, based on capacity and t ((("static fees")))((("fees", "static fees")))Static fees are no longer viable on the bitcoin network. Wallets that set static fees will produce a poor user experience as transactions will often get "stuck" and remain unconfirmed. Users who don't understand bitcoin transactions and fees are dismayed by "stuck" transactions because they think they've lost their money. ==== -The chart in <> shows the real-time estimate of fees in 10 satoshi/byte increments and the expected confirmation time (in minutes and number of blocks) for transactions with fees in each range. For each fee range (e.g., 61–70 satoshi/byte), two horizontal bars show the number of unconfirmed transactions (1405) and total number of transactions in the past 24 hours (102,975), with fees in that range. Based on the graph, the recommended high-priority fee at this time was 80 satoshi/byte, a fee likely to result in the transaction being mined in the very next block (zero block delay). For perspective, the median transaction size is 226 bytes, so the recommended fee for a transaction size would be 18,080 satoshis (0.00018080 BTC). +The chart in <> shows the real-time estimate of fees in 10 satoshi/byte increments and the expected confirmation time (in minutes and number of blocks) for transactions with fees in each range. For each fee range (e.g., 61–70 satoshi/byte), two horizontal bars show the number of unconfirmed transactions (1405) and total number of transactions in the past 24 hours (102,975), with fees in that range. Based on the graph, the recommended high-priority fee at this time was 80 satoshi/byte, a fee likely to result in the transaction being mined in the very next block (zero block delay). For perspective, the median transaction size is 226 bytes, so the recommended fee for this transaction size would be 18,080 satoshis (0.00018080 BTC). The fee estimation data can be retrieved via a simple HTTP REST API, at https://bitcoinfees.earn.com/api/v1/fees/recommended[https://bitcoinfees.earn.com/api/v1/fees/recommended]. For example, on the command line using the +curl+ command: From dc290d7b8793bd39c24f3842d37db4d31cabb8af Mon Sep 17 00:00:00 2001 From: jerzybrzoska <51721153+jerzybrzoska@users.noreply.github.com> Date: Sat, 30 Jan 2021 16:14:37 +0100 Subject: [PATCH 20/60] "verack message" instead of "verack" The reader was not introduced to the term verack earlier - 'verack' appears only once in this chapter. Thus, "verack message" seems more readable. --- ch08.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch08.asciidoc b/ch08.asciidoc index b5e4f7bd..8474ebea 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -76,7 +76,7 @@ To connect to a known peer, nodes establish a TCP connection, usually to port 83 (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+. +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. 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). From d4fa3e590a9bb3248e65f32ab9470d54f62e69ae Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 31 Jan 2021 16:17:08 +0100 Subject: [PATCH 21/60] ch06: extracted -> extracts (parallelism) --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index bbc7922e..4edf5f1c 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -713,7 +713,7 @@ Let's look again at how Alice's transaction was presented on a popular block exp .Alice's transaction to Bob's Cafe image::images/mbc2_0208.png["Alice Coffee Transaction"] -On the left side of the transaction, the blockchain explorer shows Alice's bitcoin address as the "sender." In fact, this information is not in the transaction itself. When the blockchain explorer references the transaction it also references the previous transaction associated with the input and extracted the first output from that older transaction. Within that output is a locking script that locks the UTXO to Alice's public key hash (a P2PKH script). The blockchain explorer extracted the public key hash and encoded it using Base58Check encoding to produce and display the bitcoin address that represents that public key. +On the left side of the transaction, the blockchain explorer shows Alice's bitcoin address as the "sender." In fact, this information is not in the transaction itself. When the blockchain explorer references the transaction it also references the previous transaction associated with the input and extracts the first output from that older transaction. Within that output is a locking script that locks the UTXO to Alice's public key hash (a P2PKH script). The blockchain explorer extracted the public key hash and encoded it using Base58Check encoding to produce and display the bitcoin address that represents that public key. Similarly, on the right side, the blockchain explorer shows the two outputs; the first to Bob's bitcoin address and the second to Alice's bitcoin address (as change). Once again, to create these bitcoin addresses, the blockchain explorer extracted the locking script from each output, recognized it as a P2PKH script, and extracted the public-key-hash from within. Finally, the blockchain explorer reencoded that public key hash with Base58Check to produce and display the bitcoin addresses. From 5a999ae452c2e61a3b462d958d426660999e19b5 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 31 Jan 2021 16:27:36 +0100 Subject: [PATCH 22/60] ch06: that -> each --- ch06.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch06.asciidoc b/ch06.asciidoc index bbc7922e..2e5b846e 100644 --- a/ch06.asciidoc +++ b/ch06.asciidoc @@ -715,7 +715,7 @@ image::images/mbc2_0208.png["Alice Coffee Transaction"] On the left side of the transaction, the blockchain explorer shows Alice's bitcoin address as the "sender." In fact, this information is not in the transaction itself. When the blockchain explorer references the transaction it also references the previous transaction associated with the input and extracted the first output from that older transaction. Within that output is a locking script that locks the UTXO to Alice's public key hash (a P2PKH script). The blockchain explorer extracted the public key hash and encoded it using Base58Check encoding to produce and display the bitcoin address that represents that public key. -Similarly, on the right side, the blockchain explorer shows the two outputs; the first to Bob's bitcoin address and the second to Alice's bitcoin address (as change). Once again, to create these bitcoin addresses, the blockchain explorer extracted the locking script from each output, recognized it as a P2PKH script, and extracted the public-key-hash from within. Finally, the blockchain explorer reencoded that public key hash with Base58Check to produce and display the bitcoin addresses. +Similarly, on the right side, the blockchain explorer shows the two outputs; the first to Bob's bitcoin address and the second to Alice's bitcoin address (as change). Once again, to create these bitcoin addresses, the blockchain explorer extracted the locking script from each output, recognized it as a P2PKH script, and extracted the public-key-hash from within. Finally, the blockchain explorer reencoded each public key hash with Base58Check to produce and display the bitcoin addresses. If you were to click on Bob's bitcoin address, the blockchain explorer would show you the view in <>. From eb57ec48a07a40c3433ae6c5a0097e445cc7104c Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 31 Jan 2021 18:22:49 +0100 Subject: [PATCH 23/60] ch12: transaction -> transactions --- ch12.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index 54a9730a..a37affce 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -146,7 +146,7 @@ image::images/mbc2_1203.png["Emma's payment channel with Fabian, showing the com Both of these problems can be solved with timelocks—let's look at how we could use transaction-level timelocks (+nLocktime+). -Emma cannot risk funding a 2-of-2 multisig unless she has a guaranteed refund. To solve this problem, Emma constructs the funding and refund transaction at the same time. She signs the funding transaction but doesn't transmit it to anyone. Emma transmits only the refund transaction to Fabian and obtains his signature. +Emma cannot risk funding a 2-of-2 multisig unless she has a guaranteed refund. To solve this problem, Emma constructs the funding and refund transactions at the same time. She signs the funding transaction but doesn't transmit it to anyone. Emma transmits only the refund transaction to Fabian and obtains his signature. The refund transaction acts as the first commitment transaction and its timelock establishes the upper bound for the channel's life. In this case, Emma could set the +nLocktime+ to 30 days or 4320 blocks into the future. All subsequent commitment transactions must have a shorter timelock, so that they can be redeemed before the refund transaction. From e0af335152a351cc2bb85453c3efe2eb79e19258 Mon Sep 17 00:00:00 2001 From: jerzybrzoska <51721153+jerzybrzoska@users.noreply.github.com> Date: Fri, 5 Feb 2021 10:52:45 +0100 Subject: [PATCH 24/60] ch08.asciidoc: Implementation status of BIP-150 and BIP-151 ( In fact, [BIP-151](https://github.com/bitcoin/bips) was withdrawn. --- ch08.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch08.asciidoc b/ch08.asciidoc index b5e4f7bd..bf3d7f39 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -313,7 +313,7 @@ You can find more instructions on running Bitcoin Core as a Tor hidden service i ((("Peer-to-Peer authentication and encryption")))((("bitcoin improvement proposals", "Peer Authentication (BIP-150)")))((("bitcoin improvement proposals", "Peer-to-Peer Communication Encryption (BIP-151)")))Two Bitcoin Improvement Proposals, BIP-150 and BIP-151, add support for P2P authentication and encryption in the bitcoin P2P network. These two BIPs define optional services that may be offered by compatible bitcoin nodes. BIP-151 enables negotiated encryption for all communications between two nodes that support BIP-151. BIP-150 offers optional peer authentication that allows nodes to authenticate each other's identity using ECDSA and private keys. BIP-150 requires that prior to authentication the two nodes have established encrypted communications as per BIP-151. -As of January 2017, BIP-150 and BIP-151 are not implemented in Bitcoin Core. However, the two proposals have been implemented by at least one alternative bitcoin client named bcoin. +As of February 2021, BIP-150 and BIP-151 are not implemented in Bitcoin Core. However, the two proposals have been implemented by at least one alternative bitcoin client named bcoin. BIP-150 and BIP-151 allow users to run SPV clients that connect to a trusted full node, using encryption and authentication to protect the privacy of the SPV client. From 4971598b5a2356c0bf2fc782ea4c8813872ea85a Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Mon, 8 Feb 2021 01:47:23 +0100 Subject: [PATCH 25/60] glossary: add passphrase entry --- glossary.asciidoc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/glossary.asciidoc b/glossary.asciidoc index 03764ccf..8235db70 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -170,6 +170,9 @@ P2WSH:: paper wallet:: In the most specific sense, a paper wallet is a document containing all of the data necessary to generate any number of Bitcoin private keys, forming a wallet of keys. However, people often use the term to mean any way of storing bitcoin offline as a physical document. This second definition also includes paper keys and redeemable codes. +passphrase:: + A passphrase is an optional string created by the user that serves as an additional security factor protecting the seed, even when the seed is compromised by a thief. It can also be used as a form of plausible deniability, where a chosen passphrase leads to a wallet with a small amount of funds used to distract an attacker from the “real” wallet that contains the majority of funds. + payment channels:: A micropayment channel or payment channel is class of techniques designed to allow users to make multiple bitcoin transactions without committing all of the transactions to the bitcoin blockchain. In a typical payment channel, only two transactions are added to the block chain but an unlimited or nearly unlimited number of payments can be made between the participants. From 5b03ecb3df6bc501de7fb05b1692d341295af28e Mon Sep 17 00:00:00 2001 From: Matthijs Roelink Date: Mon, 8 Feb 2021 15:12:06 +0100 Subject: [PATCH 26/60] Chapter 4: put period outside of quote marks. --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..c7314438 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -245,7 +245,7 @@ image::images/mbc2_0404.png["ecc_illustrated"] === Bitcoin Addresses -((("keys and addresses", "bitcoin addresses", id="KAaddress04")))A bitcoin address is a string of digits and characters that can be shared with anyone who wants to send you money. Addresses produced from public keys consist of a string of numbers and letters, beginning with the digit "1." Here's an example of a bitcoin address: +((("keys and addresses", "bitcoin addresses", id="KAaddress04")))A bitcoin address is a string of digits and characters that can be shared with anyone who wants to send you money. Addresses produced from public keys consist of a string of numbers and letters, beginning with the digit "1". Here's an example of a bitcoin address: ---- 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy From 984005648ad957b722229f63d710d8476b6b71ed Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 20:10:13 -0500 Subject: [PATCH 27/60] Fixing typo --- ch03.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch03.asciidoc b/ch03.asciidoc index 5d06183b..f66fd4c3 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -25,7 +25,7 @@ image::images/mbc2_0301.png["Bitcoin Core Architecture"] [[compiling_core]] === Compiling Bitcoin Core from the Source Code -((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as a archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g., +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. +((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as an archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g., +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. [TIP] ==== From f8bd256311fd91bb43303e7f617153cd67c3b94b Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 20:13:33 -0500 Subject: [PATCH 28/60] Rewording phrase to be consistent with earlier phrasing --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..f637f80b 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -486,7 +486,7 @@ To resolve this issue, when private keys are exported from a wallet, the WIF tha | WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ |======= -Notice that the hex-compressed private key format has one extra byte at the end (01 in hex). While the Base58 encoding version prefix is the same (0x80) for both WIF and WIF-compressed formats, the addition of one byte on the end of the number causes the first character of the Base58 encoding to change from a 5 to either a _K_ or _L_. Think of this as the Base58 equivalent of the decimal encoding difference between the number 100 and the number 99. While 100 is one digit longer than 99, it also has a prefix of 1 instead of a prefix of 9. As the length changes, it affects the prefix. In Base58, the prefix 5 changes to a _K_ or _L_ as the length of the number increases by one byte. +Notice that the hex-compressed private key format has one extra byte at the end (01 in hex). While the Base58Check version prefix is the same (0x80) for both WIF and WIF-compressed formats, the addition of one byte on the end of the number causes the first character of the Base58 encoding to change from a 5 to either a _K_ or _L_. Think of this as the Base58 equivalent of the decimal encoding difference between the number 100 and the number 99. While 100 is one digit longer than 99, it also has a prefix of 1 instead of a prefix of 9. As the length changes, it affects the prefix. In Base58, the prefix 5 changes to a _K_ or _L_ as the length of the number increases by one byte. Remember, these formats are _not_ used interchangeably. In a newer wallet that implements compressed public keys, the private keys will only ever be exported as WIF-compressed (with a _K_ or _L_ prefix). If the wallet is an older implementation and does not use compressed public keys, the private keys will only ever be exported as WIF (with a 5 prefix). The goal here is to signal to the wallet importing these private keys whether it must search the blockchain for compressed or uncompressed public keys and addresses. From e60b823854f8a77790d2a2654b841b3423bc405e Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 21:00:20 -0500 Subject: [PATCH 29/60] Fixing off-by-one dice target, and adding more precision to the outcome. The minimum target cannot be 2, because you can't throw a pair of dice and get a value less than 2. --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 33fa6954..4133a8bc 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -492,7 +492,7 @@ The number used as a variable in such a scenario is called a _nonce_. The nonce To make a challenge out of this algorithm, let's set a target: find a phrase that produces a hexadecimal hash that starts with a zero. Fortunately, this isn't difficult! <> shows that the phrase "I am Satoshi Nakamoto13" produces the hash +0ebc56d59a34f5082aaef3d66b37a661696c2b618e62432727216ba9531041a5+, which fits our criteria. It took 13 attempts to find it. In terms of probabilities, if the output of the hash function is evenly distributed we would expect to find a result with a 0 as the hexadecimal prefix once every 16 hashes (one out of 16 hexadecimal digits 0 through F). In numerical terms, that means finding a hash value that is less than +0x1000000000000000000000000000000000000000000000000000000000000000+. We call this threshold the _target_ and the goal is to find a hash that is numerically less than the target. If we decrease the target, the task of finding a hash that is less than the target becomes more and more difficult. -To give a simple analogy, imagine a game where players throw a pair of dice repeatedly, trying to throw less than a specified target. In the first round, the target is 12. Unless you throw double-six, you win. In the next round the target is 11. Players must throw 10 or less to win, again an easy task. Let's say a few rounds later the target is down to 5. Now, more than half the dice throws will exceed the target and therefore be invalid. It takes exponentially more dice throws to win, the lower the target gets. Eventually, when the target is 2 (the minimum possible), only one throw out of every 36, or 2% of them, will produce a winning result. +To give a simple analogy, imagine a game where players throw a pair of dice repeatedly, trying to throw less than a specified target. In the first round, the target is 12. Unless you throw double-six, you win. In the next round the target is 11. Players must throw 10 or less to win, again an easy task. Let's say a few rounds later the target is down to 5. Now, more than half the dice throws will exceed the target and therefore be invalid. It takes exponentially more dice throws to win, the lower the target gets. Eventually, when the target is 3 (the minimum possible), only one throw out of every 36, or 2.7% of them, will produce a winning result. From the perspective of an observer who knows that the target of the dice game is 2, if someone has succeeded in casting a winning throw it can be assumed that they attempted, on average, 36 throws. In other words, one can estimate the amount of work it takes to succeed from the difficulty imposed by the target. When the algorithm is based on a deterministic function such as SHA256, the input itself constitutes _proof_ that a certain amount of _work_ was done to produce a result below the target. Hence, _Proof-of-Work_. From 879243bf95159bdb6bc8f804e02409be672d03b7 Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 21:03:36 -0500 Subject: [PATCH 30/60] Changing phrase to a more conventional one. --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 33fa6954..9a34a270 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -296,7 +296,7 @@ If Jing's mining node writes the coinbase transaction, what stops Jing from "rew ((("coinbase transactions", "structure of")))With these calculations, Jing's node then constructs the coinbase transaction to pay himself 25.09094928 bitcoin. -As you can see in <>, the coinbase transaction has a special format. Instead of a transaction input specifying a previous UTXO to spend, it has a "coinbase" input. We examined transaction inputs in <>. Let's compare a regular transaction input with a coinbase transaction input. <> shows the structure of a regular transaction's input, while <> shows the structure of the coinbase transaction's input. +As you can see in <>, the coinbase transaction has a special format. Instead of a transaction input specifying a previous UTXO to spend, it has a "coinbase" input. We examined transaction inputs in <>. Let's compare a regular transaction input with a coinbase transaction input. <> shows the structure of a regular transaction input, while <> shows the structure of the coinbase transaction's input. [[table_8-1]] .The structure of a "normal" transaction input From 9fa9fd891ed0133baf42f915214a30f7526a5163 Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 21:08:19 -0500 Subject: [PATCH 31/60] Changing phrase to a more conventional one. --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 33fa6954..a3728289 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -116,7 +116,7 @@ Each node verifies every transaction against a long checklist of criteria: * The unlocking script (+scriptSig+) can only push numbers on the stack, and the locking script (+scriptPubkey+) must match +IsStandard+ forms (this rejects "nonstandard" transactions). * A matching transaction in the pool, or in a block in the main branch, must exist. * For each input, if the referenced output exists in any other transaction in the pool, the transaction must be rejected. -* For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool. +* For each input, look in the main branch and the transaction pool to find the referenced transaction output. If the transaction output is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool. * For each input, if the referenced output transaction is a coinbase output, it must have at least +COINBASE_MATURITY+ (100) confirmations. * For each input, the referenced output must exist and cannot already be spent. * Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0). From 71d99e62a2875464eff479d9f284d8450ff286cd Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 21:10:37 -0500 Subject: [PATCH 32/60] Adding missing bitcoin amounts --- ch12.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch12.asciidoc b/ch12.asciidoc index 54a9730a..98a80aa9 100644 --- a/ch12.asciidoc +++ b/ch12.asciidoc @@ -197,7 +197,7 @@ Input: 2-of-2 funding output, signed by Irene Output 0 <5 bitcoin>: CHECKSIG -Output 1: +Output 1 <5 bitcoin>: <1000 blocks> CHECKSEQUENCEVERIFY DROP @@ -212,7 +212,7 @@ Input: 2-of-2 funding output, signed by Hitesh Output 0 <5 bitcoin>: CHECKSIG -Output 1: +Output 1 <5 bitcoin>: <1000 blocks> CHECKSEQUENCEVERIFY DROP From 4ee95ea2a95c82c3969646d43807a2c34ad2fbef Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 20:14:38 -0500 Subject: [PATCH 33/60] Adding missing preposition. --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..19d1349f 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -657,7 +657,7 @@ We will explore how to create transactions that spend funds from P2SH (and multi ((("keys and addresses", "advanced forms", "vanity addresses")))((("vanity addresses", id="vanity04")))((("addresses", "vanity addresses", id="Avanity04")))Vanity addresses are valid bitcoin addresses that contain human-readable messages. For example, +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains the letters forming the word "Love" as the first four Base-58 letters. Vanity addresses require generating and testing billions of candidate private keys, until a bitcoin address with the desired pattern is found. Although there are some optimizations in the vanity generation algorithm, the process essentially involves picking a private key at random, deriving the public key, deriving the bitcoin address, and checking to see if it matches the desired vanity pattern, repeating billions of times until a match is found. -Once a vanity address matching the desired pattern is found, the private key from which it was derived can be used by the owner to spend bitcoin in exactly the same way as any other address. Vanity addresses are no less or more secure than any other address. They depend on the same Elliptic Curve Cryptography (ECC) and SHA as any other address. You can no more easily find the private key of an address starting with a vanity pattern than you can any other address. +Once a vanity address matching the desired pattern is found, the private key from which it was derived can be used by the owner to spend bitcoin in exactly the same way as any other address. Vanity addresses are no less or more secure than any other address. They depend on the same Elliptic Curve Cryptography (ECC) and SHA as any other address. You can no more easily find the private key of an address starting with a vanity pattern than you can of any other address. In <>, we introduced Eugenia, a children's charity director operating in the Philippines. Let's say that Eugenia is organizing a bitcoin fundraising drive and wants to use a vanity bitcoin address to publicize the fundraising. Eugenia will create a vanity address that starts with "1Kids" to promote the children's charity fundraiser. Let's see how this vanity address will be created and what it means for the security of Eugenia's charity.((("use cases", "charitable donations", startref="eugeniafour"))) From c66298c3c55c27e8847732d74c024dc35c119ca6 Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 20:43:01 -0500 Subject: [PATCH 34/60] Added missing word. --- ch07.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch07.asciidoc b/ch07.asciidoc index d7a76c4f..74b3d70f 100644 --- a/ch07.asciidoc +++ b/ch07.asciidoc @@ -359,7 +359,7 @@ The original meaning of +nSequence+ was never properly implemented and the value ===== nSequence as a consensus-enforced relative timelock -Since the activation of BIP-68, new consensus rules apply for any transaction containing an input whose +nSequence+ value is less than 2^31^ (bit 1<<31 is not set). Programmatically, that means that if the most significant (bit 1<<31) is not set, it is a flag that means "relative locktime." Otherwise (bit 1<<31 set), the +nSequence+ value is reserved for other uses such as enabling +CHECKLOCKTIMEVERIFY+, +nLocktime+, Opt-In-Replace-By-Fee, and other future developments. +Since the activation of BIP-68, new consensus rules apply for any transaction containing an input whose +nSequence+ value is less than 2^31^ (bit 1<<31 is not set). Programmatically, that means that if the most significant bit (bit 1<<31) is not set, it is a flag that means "relative locktime." Otherwise (bit 1<<31 set), the +nSequence+ value is reserved for other uses such as enabling +CHECKLOCKTIMEVERIFY+, +nLocktime+, Opt-In-Replace-By-Fee, and other future developments. Transaction inputs with +nSequence+ values less than 2^31^ are interpreted as having a relative timelock. Such a transaction is only valid once the input has aged by the relative timelock amount. For example, a transaction with one input with an +nSequence+ relative timelock of 30 blocks is only valid when at least 30 blocks have elapsed from the time the UTXO referenced in the input was mined. Since +nSequence+ is a per-input field, a transaction may contain any number of timelocked inputs, all of which must have sufficiently aged for the transaction to be valid. A transaction can include both timelocked inputs (+nSequence+ < 2^31^) and inputs without a relative timelock (+nSequence+ >= 2^31^). From cdcfeb16e88270260b732ac947d62b68ec3ce353 Mon Sep 17 00:00:00 2001 From: Felix Filozov Date: Wed, 10 Feb 2021 20:48:24 -0500 Subject: [PATCH 35/60] Fixing typo. --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index 33fa6954..bc236217 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -1035,7 +1035,7 @@ Technical debt:: Because soft forks are more technically complex than a hard for Validation relaxation:: Unmodified clients see transactions as valid, without evaluating the modified consensus rules. In effect, the unmodified clients are not validating using the full range of consensus rules, as they are blind to the new rules. This applies to NOP-based upgrades, as well as other soft fork upgrades. -Irreversible upgrades:: Because soft forks create transactions with additional consensus constraints, they become irreversible upgrades in practice. If a soft fork upgrade were to be reversed after beings activated, any transactions created under the new rules could result in a loss of funds under the old rules. For example, if a CLTV transaction is evaluated under the old rules, there is no timelock constraint and it can be spent at any time. Therefore, critics contend that a failed soft fork that had to be reversed because of a bug would almost certainly lead to loss of funds.((("", startref="Crule10"))) +Irreversible upgrades:: Because soft forks create transactions with additional consensus constraints, they become irreversible upgrades in practice. If a soft fork upgrade were to be reversed after being activated, any transactions created under the new rules could result in a loss of funds under the old rules. For example, if a CLTV transaction is evaluated under the old rules, there is no timelock constraint and it can be spent at any time. Therefore, critics contend that a failed soft fork that had to be reversed because of a bug would almost certainly lead to loss of funds.((("", startref="Crule10"))) [[softforksignaling]] === Soft Fork Signaling with Block Version From a65b9fbcd6189317173afcceb94a066e967d44c4 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 15:39:11 +0100 Subject: [PATCH 36/60] ch04: fix multisig explanation --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..f22924ce 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -649,7 +649,7 @@ P2SH is not necessarily the same as a multisignature standard transaction. A P2S ===== Multisignature addresses and P2SH -Currently, the most common implementation of the P2SH function is the multi-signature address script. As the name implies, the underlying script requires more than one signature to prove ownership and therefore spend funds. The bitcoin multi-signature feature is designed to require M signatures (also known as the “threshold”) from a total of N keys, known as an M-of-N multisig, where M is equal to or less than N. For example, Bob the coffee shop owner from <> could use a multisignature address requiring 1-of-2 signatures from a key belonging to him and a key belonging to his spouse, ensuring either of them could sign to spend a transaction output locked to this address. This would be similar to a “joint account” as implemented in traditional banking where either spouse can spend with a single signature. Or Gopesh,((("use cases", "offshore contract services"))) the web designer paid by Bob to create a website, might have a 2-of-3 multisignature address for his business that ensures that no funds can be spent unless at least two of the business partners sign a transaction. +Currently, the most common implementation of the P2SH function is the multi-signature address script. As the name implies, the underlying script requires a minimum number of signatures to prove ownership and therefore spend funds. The bitcoin multi-signature feature is designed to require M signatures (also known as the “threshold”) from a total of N keys, known as an M-of-N multisig, where M is equal to or less than N. For example, Bob the coffee shop owner from <> could use a multisignature address requiring 1-of-2 signatures from a key belonging to him and a key belonging to his spouse, ensuring either of them could sign to spend a transaction output locked to this address. This would be similar to a “joint account” as implemented in traditional banking where either spouse can spend with a single signature. Or Gopesh,((("use cases", "offshore contract services"))) the web designer paid by Bob to create a website, might have a 2-of-3 multisignature address for his business that ensures that no funds can be spent unless at least two of the business partners sign a transaction. We will explore how to create transactions that spend funds from P2SH (and multi-signature) addresses in <>. From 0261f4c0864672ed15716472eae0bdbe74cbca12 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 22:33:41 +0100 Subject: [PATCH 37/60] ch02: simple -> simplified (SPV) --- ch02.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index d4079ec5..6c5062de 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -275,7 +275,7 @@ image::images/mbc2_0209.png["Alice's transaction included in a block"] === Spending the Transaction -((("spending bitcoin", "simple-payment-verification (SPV)")))((("simple-payment-verification (SPV)")))Now that Alice's transaction has been embedded in the blockchain as part of a block, it is part of the distributed ledger of bitcoin and visible to all bitcoin applications. Each bitcoin client can independently verify the transaction as valid and spendable. Full-node clients can track the source of the funds from the moment the bitcoin were first generated in a block, incrementally from transaction to transaction, until they reach Bob's address. Lightweight clients can do what is called a simplified payment verification (see <>) by confirming that the transaction is in the blockchain and has several blocks mined after it, thus providing assurance that the miners accepted it as valid. +((("spending bitcoin", "simplified-payment-verification (SPV)")))((("simplified-payment-verification (SPV)")))Now that Alice's transaction has been embedded in the blockchain as part of a block, it is part of the distributed ledger of bitcoin and visible to all bitcoin applications. Each bitcoin client can independently verify the transaction as valid and spendable. Full-node clients can track the source of the funds from the moment the bitcoin were first generated in a block, incrementally from transaction to transaction, until they reach Bob's address. Lightweight clients can do what is called a simplified payment verification (see <>) by confirming that the transaction is in the blockchain and has several blocks mined after it, thus providing assurance that the miners accepted it as valid. Bob can now spend the output from this and other transactions. For example, Bob can pay a contractor or supplier by transferring value from Alice's coffee cup payment to these new owners. Most likely, Bob's bitcoin software will aggregate many small payments into a larger payment, perhaps concentrating all the day's bitcoin revenue into a single transaction. This would aggregate the various payments into a single output (and a single address). For a diagram of an aggregating transaction, see <>. From c939ce53cb4b6b0abe8f2cdce1bd83fdb9a40939 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 22:35:29 +0100 Subject: [PATCH 38/60] ch01: simple -> simplified (SPV) --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index e36e61cd..6e401a7d 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -111,7 +111,7 @@ Another way to categorize bitcoin wallets is by their degree of autonomy and how Full-node client:: ((("full-node clients")))A full client, or "full node," is a client that stores the entire history of bitcoin transactions (every transaction by every user, ever), manages users' wallets, and can initiate transactions directly on the bitcoin network. A full node handles all aspects of the protocol and can independently validate the entire blockchain and any transaction. A full-node client consumes substantial computer resources (e.g., more than 125 GB of disk, 2 GB of RAM) but offers complete autonomy and independent transaction verification. -Lightweight client:: ((("lightweight clients")))((("simple-payment-verification (SPV)")))A lightweight client, also known as a simple-payment-verification (SPV) client, connects to bitcoin full nodes (mentioned previously) for access to the bitcoin transaction information, but stores the user wallet locally and independently creates, validates, and transmits transactions. Lightweight clients interact directly with the bitcoin network, without an intermediary. +Lightweight client:: ((("lightweight clients")))((("simplified-payment-verification (SPV)")))A lightweight client, also known as a simplified-payment-verification (SPV) client, connects to bitcoin full nodes (mentioned previously) for access to the bitcoin transaction information, but stores the user wallet locally and independently creates, validates, and transmits transactions. Lightweight clients interact directly with the bitcoin network, without an intermediary. Third-party API client:: ((("third-party API clients")))A third-party API client is one that interacts with bitcoin through a third-party system of application programming interfaces (APIs), rather than by connecting to the bitcoin network directly. The wallet may be stored by the user or by third-party servers, but all transactions go through a third party. From 6e2568bdff7990fdbf8ae23c9f5e5822f0abf6c7 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 22:36:47 +0100 Subject: [PATCH 39/60] ch08: simple -> simplified (SPV) --- ch08.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch08.asciidoc b/ch08.asciidoc index b5e4f7bd..d38a0740 100644 --- a/ch08.asciidoc +++ b/ch08.asciidoc @@ -20,7 +20,7 @@ image::images/mbc2_0801.png["FullNodeReferenceClient_Small"] All nodes include the routing function to participate in the network and might include other functionality. All nodes validate and propagate transactions and blocks, and discover and maintain connections to peers. In the full-node example in <>, the routing function is indicated by a circle named "Network Routing Node" or with the letter "N." -((("full-node clients")))Some nodes, called full nodes, also maintain a complete and up-to-date copy of the blockchain. Full nodes can autonomously and authoritatively verify any transaction without external reference. ((("simple-payment-verification (SPV)")))Some nodes maintain only a subset of the blockchain and verify transactions using a method called _simplified payment verification_, or SPV. ((("lightweight clients")))These nodes are known as SPV nodes or lightweight nodes. In the full-node example in the figure, the full-node blockchain database function is indicated by a circle called "Full Blockchain" or the letter "B." In <>, SPV nodes are drawn without the "B" circle, showing that they do not have a full copy of the blockchain. +((("full-node clients")))Some nodes, called full nodes, also maintain a complete and up-to-date copy of the blockchain. Full nodes can autonomously and authoritatively verify any transaction without external reference. ((("simplified-payment-verification (SPV)")))Some nodes maintain only a subset of the blockchain and verify transactions using a method called _simplified payment verification_, or SPV. ((("lightweight clients")))These nodes are known as SPV nodes or lightweight nodes. In the full-node example in the figure, the full-node blockchain database function is indicated by a circle called "Full Blockchain" or the letter "B." In <>, SPV nodes are drawn without the "B" circle, showing that they do not have a full copy of the blockchain. ((("bitcoin nodes", "mining nodes")))((("mining and consensus", "mining nodes")))((("Proof-of-Work algorithm")))((("mining and consensus", "Proof-of-Work algorithm")))Mining nodes compete to create new blocks by running specialized hardware to solve the Proof-of-Work algorithm. Some mining nodes are also full nodes, maintaining a full copy of the blockchain, while others are lightweight nodes participating in pool mining and depending on a pool server to maintain a full node. The mining function is shown in the full node as a circle called "Miner" or the letter "M." @@ -173,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")))((("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. +((("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. 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. From 407fd8180b0f964adab289ef3da99c4cd7be23b0 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 22:37:30 +0100 Subject: [PATCH 40/60] ch09: simple -> simplified (SPV) --- ch09.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch09.asciidoc b/ch09.asciidoc index bb88c2d9..de06da60 100644 --- a/ch09.asciidoc +++ b/ch09.asciidoc @@ -259,7 +259,7 @@ As you can see from the table, while the block size increases rapidly, from 4 KB === Merkle Trees and Simplified Payment Verification (SPV) -((("simple-payment-verification (SPV)")))((("bitcoin nodes", "SPV nodes")))Merkle trees are used extensively by SPV nodes. SPV nodes don't have all transactions and do not download full blocks, just block headers. In order to verify that a transaction is included in a block, without having to download all the transactions in the block, they use an authentication path, or merkle path. +((("simplified-payment-verification (SPV)")))((("bitcoin nodes", "SPV nodes")))Merkle trees are used extensively by SPV nodes. SPV nodes don't have all transactions and do not download full blocks, just block headers. In order to verify that a transaction is included in a block, without having to download all the transactions in the block, they use an authentication path, or merkle path. Consider, for example, an SPV node that is interested in incoming payments to an address contained in its wallet. The SPV node will establish a bloom filter (see <>) on its connections to peers to limit the transactions received to only those containing addresses of interest. When a peer sees a transaction that matches the bloom filter, it will send that block using a +merkleblock+ message. The +merkleblock+ message contains the block header as well as a merkle path that links the transaction of interest to the merkle root in the block. The SPV node can use this merkle path to connect the transaction to the block and verify that the transaction is included in the block. The SPV node also uses the block header to link the block to the rest of the blockchain. The combination of these two links, between the transaction and block, and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the SPV node will have received less than a kilobyte of data for the block header and merkle path, an amount of data that is more than a thousand times less than a full block (about 1 megabyte currently).((("", startref="BCTmerkle09")))((("", startref="merkle09"))) From 76fa766a094ba85b5537884ac8e10a86254fa6a9 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 13 Feb 2021 01:23:16 +0100 Subject: [PATCH 41/60] ch01: wallets -> wallet --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index e36e61cd..f362e189 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -200,7 +200,7 @@ image::images/mbc2_0102.png["airbitz mobile send screen"] Joe then carefully checks to make sure he has entered the correct amount, because he is about to transmit money and mistakes are irreversible. After double-checking the address and amount, he presses Send to transmit the transaction. Joe's mobile bitcoin wallet constructs a transaction that assigns 0.10 BTC to the address provided by Alice, sourcing the funds from Joe's wallet and signing the transaction with Joe's private keys. This tells the bitcoin network that Joe has authorized a transfer of value to Alice's new address. As the transaction is transmitted via the peer-to-peer protocol, it quickly propagates across the bitcoin network. In less than a second, most of the well-connected nodes in the network receive the transaction and see Alice's address for the first time. -Meanwhile, Alice's wallet is constantly "listening" to published transactions on the bitcoin network, looking for any that match the addresses in her wallets. A few seconds after Joe's wallet transmits the transaction, Alice's wallet will indicate that it is receiving 0.10 BTC. +Meanwhile, Alice's wallet is constantly "listening" to published transactions on the bitcoin network, looking for any that match the addresses contained in her wallet. A few seconds after Joe's wallet transmits the transaction, Alice's wallet will indicate that it is receiving 0.10 BTC. .Confirmations **** From 4956c6f6c989abb9e13b553aec411201a4cbf253 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 13 Feb 2021 02:05:39 +0100 Subject: [PATCH 42/60] ch01: Alice's address -> Alice's wallet --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index e36e61cd..b12f5878 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -204,7 +204,7 @@ Meanwhile, Alice's wallet is constantly "listening" to published transactions on .Confirmations **** -((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's address will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the bitcoin transaction ledger, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <>. +((("getting started", "confirmations")))((("confirmations", "bitcoin wallet quick start example")))((("confirmations", see="also mining and consensus; transactions")))((("clearing", seealso="confirmations")))At first, Alice's wallet will show the transaction from Joe as "Unconfirmed." This means that the transaction has been propagated to the network but has not yet been recorded in the bitcoin transaction ledger, known as the blockchain. To be confirmed, a transaction must be included in a block and added to the blockchain, which happens every 10 minutes, on average. In traditional financial terms this is known as _clearing_. For more details on propagation, validation, and clearing (confirmation) of bitcoin transactions, see <>. **** Alice is now the proud owner of 0.10 BTC that she can spend. In the next chapter we will look at her first purchase with bitcoin, and examine the underlying transaction and propagation technologies in more detail.((("", startref="BCbasic01")))((("use cases", "buying coffee", startref="aliceone"))) From b80ffe0bfe731ef7addaff410a11825ca3d02427 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 14 Feb 2021 18:27:46 +0100 Subject: [PATCH 43/60] ch02: explain that both outputs are in a single tx --- ch02.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index d4079ec5..a5e88ea5 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -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 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. +((("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, your wallet would create a single transaction that sends two outputs, 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. From 8c30f250b4836a0d6913b9305a729c0bd896439d Mon Sep 17 00:00:00 2001 From: Oge Nnadi Date: Mon, 15 Feb 2021 12:51:42 -0600 Subject: [PATCH 44/60] Fix typo --- ch03.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch03.asciidoc b/ch03.asciidoc index 5d06183b..f66fd4c3 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -25,7 +25,7 @@ image::images/mbc2_0301.png["Bitcoin Core Architecture"] [[compiling_core]] === Compiling Bitcoin Core from the Source Code -((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as a archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g., +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. +((("Bitcoin Core", "compiling from source code", id="BCsource03")))((("Bitcoin Core", "compiling from source code", "downloading")))((("code examples, obtaining and using")))Bitcoin Core's source code can be downloaded as an archive or by cloning the authoritative source repository from GitHub. ((("Bitcoin Core downloads")))On the https://bitcoincore.org/bin/[Bitcoin Core download page], select the most recent version and download the compressed archive of the source code, e.g., +bitcoin-0.15.0.2.tar.gz+. ((("GitHub bitcoin page")))Alternatively, use the git command line to create a local copy of the source code from the https://github.com/bitcoin/bitcoin[GitHub bitcoin page]. [TIP] ==== From 57dba437c555ac1779a729fcbed8746e0d1a387e Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Tue, 16 Feb 2021 16:41:01 +0100 Subject: [PATCH 45/60] ch11: fix multisig explanation --- ch11.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch11.asciidoc b/ch11.asciidoc index ea13f3d5..b4105344 100644 --- a/ch11.asciidoc +++ b/ch11.asciidoc @@ -65,7 +65,7 @@ Would you carry your entire net worth in cash in your wallet? Most people would ==== Multisig and Governance -((("multisig addresses")))((("addresses", "multisig addresses")))Whenever a company or individual stores large amounts of bitcoin, they should consider using a multisignature bitcoin address. Multisignature addresses secure funds by requiring more than one signature to make a payment. The signing keys should be stored in a number of different locations and under the control of different people. In a corporate environment, for example, the keys should be generated independently and held by several company executives, to ensure no single person can compromise the funds. Multisignature addresses can also offer redundancy, where a single person holds several keys that are stored in different locations. +((("multisig addresses")))((("addresses", "multisig addresses")))Whenever a company or individual stores large amounts of bitcoin, they should consider using a multisignature bitcoin address. Multisignature addresses secure funds by requiring a minimum number of signatures to make a payment. The signing keys should be stored in a number of different locations and under the control of different people. In a corporate environment, for example, the keys should be generated independently and held by several company executives, to ensure no single person can compromise the funds. Multisignature addresses can also offer redundancy, where a single person holds several keys that are stored in different locations. ==== Survivability From b640698e0fb59a688fbfe3fffc740a88964bd937 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 19 Feb 2021 01:58:46 +0100 Subject: [PATCH 46/60] ch04: paper wallet = private key + address --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index bc38e1dc..a4629bd9 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -770,7 +770,7 @@ So does a vanity address increase security? If Eugenia generates the vanity addr ((("keys and addresses", "advanced forms", "paper wallets")))((("paper wallets", id="paperw04")))((("wallets", "types of", "paper wallets", id="Wpaper04")))Paper wallets are bitcoin private keys printed on paper. Often the paper wallet also includes the corresponding bitcoin address for convenience, but this is not necessary because it can be derived from the private key. Paper wallets are a very effective way to create backups or offline bitcoin storage, also known as "cold storage." As a backup mechanism, a paper wallet can provide security against the loss of key due to a computer mishap such as a hard-drive failure, theft, or accidental deletion. As a "cold storage" mechanism, if the paper wallet keys are generated offline and never stored on a computer system, they are much more secure against hackers, keyloggers, and other online computer threats. -Paper wallets come in many shapes, sizes, and designs, but at a very basic level are just a key and an address printed on paper. <> shows the simplest form of a paper wallet. +Paper wallets come in many shapes, sizes, and designs, but at a very basic level are just a private key and an address printed on paper. <> shows the simplest form of a paper wallet. [[table_4-14]] .Simplest form of a paper wallet—a printout of the bitcoin address and private key From 388da74024f58e6b83c10e4c4cb3ec137ae02392 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 20 Feb 2021 02:15:30 +0100 Subject: [PATCH 47/60] ch05: keys -> addresses --- ch05.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch05.asciidoc b/ch05.asciidoc index f2e94eba..1b886b31 100644 --- a/ch05.asciidoc +++ b/ch05.asciidoc @@ -390,7 +390,7 @@ An extended public key can be used, therefore, to derive all of the _public_ key This shortcut can be used to create very secure public key–only deployments where a server or application has a copy of an extended public key and no private keys whatsoever. That kind of deployment can produce an infinite number of public keys and bitcoin addresses, but cannot spend any of the money sent to those addresses. Meanwhile, on another, more secure server, the extended private key can derive all the corresponding private keys to sign transactions and spend the money. -One common application of this solution is to install an extended public key on a web server that serves an ecommerce application. The web server can use the public key derivation function to create a new bitcoin address for every transaction (e.g., for a customer shopping cart). The web server will not have any private keys that would be vulnerable to theft. Without HD wallets, the only way to do this is to generate thousands of bitcoin addresses on a separate secure server and then preload them on the ecommerce server. That approach is cumbersome and requires constant maintenance to ensure that the ecommerce server doesn't "run out" of keys. +One common application of this solution is to install an extended public key on a web server that serves an ecommerce application. The web server can use the public key derivation function to create a new bitcoin address for every transaction (e.g., for a customer shopping cart). The web server will not have any private keys that would be vulnerable to theft. Without HD wallets, the only way to do this is to generate thousands of bitcoin addresses on a separate secure server and then preload them on the ecommerce server. That approach is cumbersome and requires constant maintenance to ensure that the ecommerce server doesn't "run out" of addresses. ((("cold storage")))((("storage", "cold storage")))((("hardware wallets")))Another common application of this solution is for cold-storage or hardware wallets. In that scenario, the extended private key can be stored on a paper wallet or hardware device (such as a Trezor hardware wallet), while the extended public key can be kept online. The user can create "receive" addresses at will, while the private keys are safely stored offline. To spend the funds, the user can use the extended private key on an offline signing bitcoin client or sign transactions on the hardware wallet device (e.g., Trezor). <> illustrates the mechanism for extending a parent public key to derive child public keys. From 0f9274673865c72e02bd7446018e07902753cc70 Mon Sep 17 00:00:00 2001 From: Will Binns Date: Sat, 20 Feb 2021 11:36:33 +0100 Subject: [PATCH 48/60] ch04: Remove bash symbol from comments --- ch04.asciidoc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index a4629bd9..c4775a08 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -603,11 +603,11 @@ include::code/ec-math.py[] .Installing the Python ECDSA library and running the ec_math.py script ==== ---- -$ # Install Python PIP package manager +# Install Python PIP package manager $ sudo apt-get install python-pip -$ # Install the Python ECDSA library +# Install the Python ECDSA library $ sudo pip install ecdsa -$ # Run the script +# Run the script $ python ec-math.py Secret: 38090835015954358862481132628887443905906204995912378278060168703580660294000 EC point: (70048853531867179489857750497606966272382583471322935454624595540007269312627, 105262206478686743191060800263479589329920209527285803935736021686045542353380) @@ -723,13 +723,13 @@ The example code must be compiled using a pass:[C++] compiler and linked against ==== [source,bash] ---- -$ # Compile the code with g++ +# Compile the code with g++ $ g++ -o vanity-miner vanity-miner.cpp $(pkg-config --cflags --libs libbitcoin) -$ # Run the example +# Run the example $ ./vanity-miner Found vanity address! 1KiDzkG4MxmovZryZRj8tK81oQRhbZ46YT Secret: 57cc268a05f83a23ac9d930bc8565bac4e277055f4794cbd1a39e5e71c038f3f -$ # Run it again for a different result +# Run it again for a different result $ ./vanity-miner Found vanity address! 1Kidxr3wsmMzzouwXibKfwTYs5Pau8TUFn Secret: 7f65bbbbe6d8caae74a0c6a0d2d7b5c6663d71b60337299a1a2cf34c04b2a623 From 7af5264b3faf8e9bddc97d63b58447a9bd325264 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Thu, 21 Jan 2021 22:05:57 +0100 Subject: [PATCH 49/60] ch10: adding "stale block", removing "orphan block" --- ch10.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index f75140e8..e176331a 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -812,7 +812,7 @@ Any mining node whose perspective resembles Node Y will start building a candida Forks are almost always resolved within one block. While part of the network's hashing power is dedicated to building on top of "triangle" as the parent, another part of the hashing power is focused on building on top of "upside-down triangle." Even if the hashing power is almost evenly split, it is likely that one set of miners will find a solution and propagate it before the other set of miners have found any solutions. Let's say, for example, that the miners building on top of "triangle" find a new block "rhombus" that extends the chain (e.g., star-triangle-rhombus). They immediately propagate this new block and the entire network sees it as a valid solution as shown in <>. -All nodes that had chosen "triangle" as the winner in the previous round will simply extend the chain one more block. The nodes that chose "upside-down triangle" as the winner, however, will now see two chains: star-triangle-rhombus and star-upside-down-triangle. The chain star-triangle-rhombus is now longer (more cumulative work) than the other chain. As a result, those nodes will set the chain star-triangle-rhombus as the main chain and change the star-upside-down-triangle chain to a secondary chain, as shown in <>. This is a chain reconvergence, because those nodes are forced to revise their view of the blockchain to incorporate the new evidence of a longer chain. Any miners working on extending the chain star-upside-down-triangle will now stop that work because their candidate block is an "orphan," as its parent "upside-down-triangle" is no longer on the longest chain. The transactions within "upside-down-triangle" that are not within "triangle" are re-inserted in the mempool for inclusion in the next block to become a part of the main chain. The entire network reconverges on a single blockchain star-triangle-rhombus, with "rhombus" as the last block in the chain. All miners immediately start working on candidate blocks that reference "rhombus" as their parent to extend the star-triangle-rhombus chain. +All nodes that had chosen "triangle" as the winner in the previous round will simply extend the chain one more block. The nodes that chose "upside-down triangle" as the winner, however, will now see two chains: star-triangle-rhombus and star-upside-down-triangle. The chain star-triangle-rhombus is now longer (more cumulative work) than the other chain. As a result, those nodes will set the chain star-triangle-rhombus as the main chain and change the star-upside-down-triangle chain to a secondary chain, as shown in <>. This is a chain reconvergence, because those nodes are forced to revise their view of the blockchain to incorporate the new evidence of a longer chain. Any miners working on extending the chain star-upside-down-triangle will now stop that work because their candidate block is now considered a stale block, as its parent "upside-down-triangle" is no longer on the longest chain. The transactions within "upside-down-triangle" that are not within "triangle" are re-inserted in the mempool for inclusion in the next block to become a part of the main chain. The entire network reconverges on a single blockchain star-triangle-rhombus, with "rhombus" as the last block in the chain. All miners immediately start working on candidate blocks that reference "rhombus" as their parent to extend the star-triangle-rhombus chain. [[fork4]] [role="smallereighty"] From 0e3b6afe1bba65b8a6a5818a244d13b930a27d87 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sun, 14 Feb 2021 19:11:59 +0100 Subject: [PATCH 50/60] ch02: aggr. tx: add tx batching, saving in fees and exchange withdrawal example --- ch02.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch02.asciidoc b/ch02.asciidoc index d5a2dc7c..761336d2 100644 --- a/ch02.asciidoc +++ b/ch02.asciidoc @@ -134,7 +134,7 @@ Another common form of transaction is one that aggregates several inputs into a .Transaction aggregating funds image::images/mbc2_0206.png["Aggregating Transaction"] -Finally, another transaction form that is seen often on the bitcoin ledger is a transaction that distributes one input to multiple outputs representing multiple recipients (see <>). This type of transaction is sometimes used by commercial entities to distribute funds, such as when processing payroll payments to multiple employees.((("", startref="Tover02"))) +Finally, another transaction form that is seen often on the bitcoin ledger is a batched transaction, which distributes one input to multiple outputs representing multiple recipients, a technique called "transaction batching" (see <>). Since this type of transaction is useful for saving in transaction fees, it is commonly used by commercial entities to distribute funds, such as when a company is processing payroll payments to multiple employees or when a bitcoin exchange is processing multiple customers' withdrawals in a single transaction.((("", startref="Tover02"))) [[transaction-distributing]] .Transaction distributing funds From 57eaed3c526d67a1aebc965da511399e62899458 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 19 Feb 2021 20:53:43 +0100 Subject: [PATCH 51/60] ch04: add "web, desktop, or mobile" wallet --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 9cabe599..37204eca 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -787,7 +787,7 @@ Paper wallets can be generated easily using a tool such as the client-side JavaS .An example of a simple paper wallet from bitaddress.org image::images/mbc2_0408.png[] -((("bitcoin improvement proposals", "Encrypted Private Keys (BIP-38)")))The disadvantage of a simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoin locked with those keys. A more sophisticated paper wallet storage system uses BIP-38 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase-protected wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. <> shows a paper wallet with an encrypted private key (BIP-38) created on the bitaddress.org site. +((("bitcoin improvement proposals", "Encrypted Private Keys (BIP-38)")))The disadvantage of a simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoin locked with those keys. A more sophisticated paper wallet storage system uses BIP-38 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase-protected web, desktop, or mobile wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. <> shows a paper wallet with an encrypted private key (BIP-38) created on the bitaddress.org site. [[paper_wallet_encrypted]] .An example of an encrypted paper wallet from bitaddress.org. The passphrase is "test." From 31363ce1c4c5c28a5654714ca3a006f82fc021f1 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 22:10:14 +0100 Subject: [PATCH 52/60] ch01: improvements to hardware wallet part --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index 2c70f416..bc6823d0 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -103,7 +103,7 @@ Mobile wallet:: A mobile wallet is the most common type of bitcoin wallet. Runni Web wallet:: Web wallets are accessed through a web browser and store the user's wallet on a server owned by a third party. This is similar to webmail in that it relies entirely on a third-party server. Some of these services operate using client-side code running in the user's browser, which keeps control of the bitcoin keys in the hands of the user. Most, however, present a compromise by taking control of the bitcoin keys from users in exchange for ease-of-use. It is inadvisable to store large amounts of bitcoin on third-party systems. -Hardware wallet:: Hardware wallets are devices that operate a secure self-contained bitcoin wallet on special-purpose hardware. They are operated via USB with a desktop web browser or via near-field-communication (NFC) on a mobile device. By handling all bitcoin-related operations on the specialized hardware, these wallets are considered very secure and suitable for storing large amounts of bitcoin. +Hardware wallet:: Hardware wallets are devices that operate a secure self-contained bitcoin wallet on special-purpose hardware. They usually connect to a desktop or mobile device via USB cable or near-field-communication (NFC), and are operated with a web browser or accompanying software. By handling all bitcoin-related operations on the specialized hardware, these wallets are considered very secure and suitable for storing large amounts of bitcoin. Paper wallet:: ((("cold storage", seealso="storage")))((("storage", "cold storage")))The keys controlling bitcoin can also be printed for long-term storage. These are known as paper wallets even though other materials (wood, metal, etc.) can be used. Paper wallets offer a low-tech but highly secure means of storing bitcoin long term. Offline storage is also often referred to as _cold storage_. From 5f08cfb2340abeba7d345b9b5db3e2eabd7aa391 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Fri, 12 Feb 2021 15:34:29 +0100 Subject: [PATCH 53/60] glossary: fixing multisig explanation --- glossary.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/glossary.asciidoc b/glossary.asciidoc index 03764ccf..e54e37b1 100644 --- a/glossary.asciidoc +++ b/glossary.asciidoc @@ -120,7 +120,7 @@ miner:: A network node that finds valid proof of work for new blocks, by repeated hashing. multisignature:: - Multisignature (multisig) refers to requiring more than one key to authorize a bitcoin transaction. + Multisignature (multisig) refers to requiring a minimum number (M) of keys (N) to authorize an M-of-N transaction. network:: A peer-to-peer network that propagates transactions and blocks to every bitcoin node on the network. From 2db8f435cc37f8ed0dd699e138e7c4631924f557 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 20 Feb 2021 17:08:19 +0100 Subject: [PATCH 54/60] ch09: Remove bash symbol from comments --- ch09.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch09.asciidoc b/ch09.asciidoc index de06da60..9c3e0d18 100644 --- a/ch09.asciidoc +++ b/ch09.asciidoc @@ -226,9 +226,9 @@ include::code/merkle.cpp[] ==== [source,bash] ---- -$ # Compile the merkle.cpp code +# Compile the merkle.cpp code $ g++ -o merkle merkle.cpp $(pkg-config --cflags --libs libbitcoin) -$ # Run the merkle executable +# Run the merkle executable $ ./merkle Current merkle hash list: 32650049a0418e4380db0af81788635d8b65424d397170b8499cdc28c4d27006 From 59dbb7dedf8549bd9b4c8a33b4341570484fd545 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 20 Feb 2021 17:08:56 +0100 Subject: [PATCH 55/60] ch10: Remove bash symbol from comments --- ch10.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index f75140e8..5b5a9763 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -358,9 +358,9 @@ We compile the code with the GNU C++ compiler and run the resulting executable, ==== [source,bash] ---- -$ # Compile the code +# Compile the code $ g++ -o satoshi-words satoshi-words.cpp $(pkg-config --cflags --libs libbitcoin) -$ # Run the executable +# Run the executable $ ./satoshi-words ^D��^A^DEThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks ---- From 4306ebdb6e72f70fcd5f5a195e6eaf033383d2d2 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 20 Feb 2021 17:30:11 +0100 Subject: [PATCH 56/60] ch04: Base-58 -> Base58 --- ch04.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index 9cabe599..dd266c13 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -655,7 +655,7 @@ We will explore how to create transactions that spend funds from P2SH (and multi ==== Vanity Addresses -((("keys and addresses", "advanced forms", "vanity addresses")))((("vanity addresses", id="vanity04")))((("addresses", "vanity addresses", id="Avanity04")))Vanity addresses are valid bitcoin addresses that contain human-readable messages. For example, +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains the letters forming the word "Love" as the first four Base-58 letters. Vanity addresses require generating and testing billions of candidate private keys, until a bitcoin address with the desired pattern is found. Although there are some optimizations in the vanity generation algorithm, the process essentially involves picking a private key at random, deriving the public key, deriving the bitcoin address, and checking to see if it matches the desired vanity pattern, repeating billions of times until a match is found. +((("keys and addresses", "advanced forms", "vanity addresses")))((("vanity addresses", id="vanity04")))((("addresses", "vanity addresses", id="Avanity04")))Vanity addresses are valid bitcoin addresses that contain human-readable messages. For example, +1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains the letters forming the word "Love" as the first four Base58 letters. Vanity addresses require generating and testing billions of candidate private keys, until a bitcoin address with the desired pattern is found. Although there are some optimizations in the vanity generation algorithm, the process essentially involves picking a private key at random, deriving the public key, deriving the bitcoin address, and checking to see if it matches the desired vanity pattern, repeating billions of times until a match is found. Once a vanity address matching the desired pattern is found, the private key from which it was derived can be used by the owner to spend bitcoin in exactly the same way as any other address. Vanity addresses are no less or more secure than any other address. They depend on the same Elliptic Curve Cryptography (ECC) and SHA as any other address. You can no more easily find the private key of an address starting with a vanity pattern than you can of any other address. From dbfed739519be893ec0b192b43d0dc211483adb6 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 20 Feb 2021 18:05:00 +0100 Subject: [PATCH 57/60] ch01: in her wallet -> it contains --- ch01.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ch01.asciidoc b/ch01.asciidoc index 2c70f416..29ddc4f2 100644 --- a/ch01.asciidoc +++ b/ch01.asciidoc @@ -200,7 +200,7 @@ image::images/mbc2_0102.png["airbitz mobile send screen"] Joe then carefully checks to make sure he has entered the correct amount, because he is about to transmit money and mistakes are irreversible. After double-checking the address and amount, he presses Send to transmit the transaction. Joe's mobile bitcoin wallet constructs a transaction that assigns 0.10 BTC to the address provided by Alice, sourcing the funds from Joe's wallet and signing the transaction with Joe's private keys. This tells the bitcoin network that Joe has authorized a transfer of value to Alice's new address. As the transaction is transmitted via the peer-to-peer protocol, it quickly propagates across the bitcoin network. In less than a second, most of the well-connected nodes in the network receive the transaction and see Alice's address for the first time. -Meanwhile, Alice's wallet is constantly "listening" to published transactions on the bitcoin network, looking for any that match the addresses contained in her wallet. A few seconds after Joe's wallet transmits the transaction, Alice's wallet will indicate that it is receiving 0.10 BTC. +Meanwhile, Alice's wallet is constantly "listening" to published transactions on the bitcoin network, looking for any that match the addresses it contains. A few seconds after Joe's wallet transmits the transaction, Alice's wallet will indicate that it is receiving 0.10 BTC. .Confirmations **** From ebf59432b9dc40777e36089a460e928ed9dfc9b2 Mon Sep 17 00:00:00 2001 From: rating89us <45968869+rating89us@users.noreply.github.com> Date: Sat, 20 Feb 2021 18:29:04 +0100 Subject: [PATCH 58/60] ch10: referenced output transaction -> parent transaction --- ch10.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ch10.asciidoc b/ch10.asciidoc index f75140e8..d6bdc326 100644 --- a/ch10.asciidoc +++ b/ch10.asciidoc @@ -116,10 +116,10 @@ Each node verifies every transaction against a long checklist of criteria: * The unlocking script (+scriptSig+) can only push numbers on the stack, and the locking script (+scriptPubkey+) must match +IsStandard+ forms (this rejects "nonstandard" transactions). * A matching transaction in the pool, or in a block in the main branch, must exist. * For each input, if the referenced output exists in any other transaction in the pool, the transaction must be rejected. -* For each input, look in the main branch and the transaction pool to find the referenced transaction output. If the transaction output is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool. -* For each input, if the referenced output transaction is a coinbase output, it must have at least +COINBASE_MATURITY+ (100) confirmations. +* For each input, look in the main branch and the transaction pool to find its parent transaction. If the parent transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions pool, if a matching transaction is not already in the pool. +* For each input, if its parent transaction is a coinbase transaction, it must have at least +COINBASE_MATURITY+ (100) confirmations. * For each input, the referenced output must exist and cannot already be spent. -* Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0). +* Using the parent transactions to get input values, check that each input value, as well as the sum, are in the allowed range of values (less than 21m coins, more than 0). * Reject if the sum of input values is less than sum of output values. * Reject if transaction fee would be too low (+minRelayTxFee+) to get into an empty block. * The unlocking scripts for each input must validate against the corresponding output locking scripts. From 70177894ec6ac27570d05f9e1d538f4e8841309f Mon Sep 17 00:00:00 2001 From: Will Binns Date: Sun, 21 Feb 2021 16:31:18 +0100 Subject: [PATCH 59/60] github_contrib: Add new contributors --- github_contrib.asciidoc | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/github_contrib.asciidoc b/github_contrib.asciidoc index b252c159..f7d808df 100644 --- a/github_contrib.asciidoc +++ b/github_contrib.asciidoc @@ -51,6 +51,7 @@ The following is a list of notable GitHub contributors: * Evlix * fabienhinault * Fan (whiteath) +* Felix Filozov (ffilozov) * Francis Ballares (fballares) * François Wirion (wirion) * Frank Höger (francyi) @@ -76,6 +77,7 @@ The following is a list of notable GitHub contributors: * Jordan Baczuk (JBaczuk) * Jeremy Bokobza (bokobza) * JerJohn15 +* jerzybrzoska * Jimmy DeSilva (jimmydesilva) * Jo Wo (jowo-io) * Joe Bauers (joebauers) @@ -99,6 +101,7 @@ The following is a list of notable GitHub contributors: * Martin Vseticka (MartyIX) * Marzig (marzig76) * Matt McGivney (mattmcgiv) +* Matthijs Roelink (Matthiti) * Maximilian Reichel (phramz) * Michalis Kargakis (kargakis) * Michael C. Ippolito (michaelcippolito) @@ -113,10 +116,13 @@ The following is a list of notable GitHub contributors: * nekonenene * Nhan Vu (jobnomade) * Nicholas Chen (nickycutesc) +* Ning Shang (syncom) +* Oge Nnadi (ogennadi) * Omar Boukli-Hacene (oboukli) * Parzival (Parz-val) * Philipp Gille (philippgille) * ratijas +* rating89us * Reproducibility Matters (TheCharlatan) * Reuben Thomas (rrthomas) * Robert Furse (Rfurse) @@ -125,6 +131,7 @@ The following is a list of notable GitHub contributors: * rszheng * Ruben Alexander (hizzvizz) * Sam Ritchie (sritchie) +* Sandro Conforto (sandroconforto) * Sanjay Sanathanan (sanjays95) * Sebastian Falbesoner (theStack) * Sergej Kotliar (ziggamon) From 07da92ac9563d3b8b3faf09b908d4463cbcb3540 Mon Sep 17 00:00:00 2001 From: "Andreas M. Antonopoulos" Date: Thu, 25 Feb 2021 09:23:46 -0600 Subject: [PATCH 60/60] Paper wallet warning and removal of bitcoinpaperwallet.com --- ch04.asciidoc | 35 ++++++++++------------------------- 1 file changed, 10 insertions(+), 25 deletions(-) diff --git a/ch04.asciidoc b/ch04.asciidoc index ca514eda..de5f0c11 100644 --- a/ch04.asciidoc +++ b/ch04.asciidoc @@ -768,9 +768,14 @@ So does a vanity address increase security? If Eugenia generates the vanity addr [[paper_wallets]] ==== Paper Wallets -((("keys and addresses", "advanced forms", "paper wallets")))((("paper wallets", id="paperw04")))((("wallets", "types of", "paper wallets", id="Wpaper04")))Paper wallets are bitcoin private keys printed on paper. Often the paper wallet also includes the corresponding bitcoin address for convenience, but this is not necessary because it can be derived from the private key. Paper wallets are a very effective way to create backups or offline bitcoin storage, also known as "cold storage." As a backup mechanism, a paper wallet can provide security against the loss of key due to a computer mishap such as a hard-drive failure, theft, or accidental deletion. As a "cold storage" mechanism, if the paper wallet keys are generated offline and never stored on a computer system, they are much more secure against hackers, keyloggers, and other online computer threats. +((("keys and addresses", "advanced forms", "paper wallets")))((("paper wallets", id="paperw04")))((("wallets", "types of", "paper wallets", id="Wpaper04")))Paper wallets are bitcoin private keys printed on paper. Often the paper wallet also includes the corresponding bitcoin address for convenience, but this is not necessary because it can be derived from the private key. -Paper wallets come in many shapes, sizes, and designs, but at a very basic level are just a private key and an address printed on paper. <> shows the simplest form of a paper wallet. +[WARNING] +==== +Paper wallets are an OBSOLETE technology and are dangerous for most users. There are many subtle pitfalls involved in generating them, not least of which the possibility that the generating code is compromised with a "back door". Hundreds of bitcoin have been stolen this way. Paper wallets are shown here for informational purposes only and should not be used for storing bitcoin. Use a BIP-39 mnemonic phrase to backup your keys. Use a hardware wallet to store keys and sign transactions. DO NOT USE PAPER WALLETS. +==== + +Paper wallets come in many shapes, sizes, and designs, but at a very basic level are just a key and an address printed on paper. <> shows the simplest form of a paper wallet. [[table_4-14]] .Simplest form of a paper wallet—a printout of the bitcoin address and private key @@ -780,34 +785,14 @@ Paper wallets come in many shapes, sizes, and designs, but at a very basic level |1424C2F4bC9JidNjjTUZCbUxv6Sa1Mt62x|5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn |======================= - -Paper wallets can be generated easily using a tool such as the client-side JavaScript generator at _bitaddress.org_. This page contains all the code necessary to generate keys and paper wallets, even while completely disconnected from the internet. To use it, save the HTML page on your local drive or on an external USB flash drive. Disconnect from the internet and open the file in a browser. Even better, boot your computer using a pristine operating system, such as a CD-ROM bootable Linux OS. Any keys generated with this tool while offline can be printed on a local printer over a USB cable (not wirelessly), thereby creating paper wallets whose keys exist only on the paper and have never been stored on any online system. Put these paper wallets in a fireproof safe and "send" bitcoin to their bitcoin address, to implement a simple yet highly effective "cold storage" solution. <> shows a paper wallet generated from the bitaddress.org site. +Paper wallets come in many designs and sizes, with many different features. <> shows a sample paper wallet. [[paper_wallet_simple]] -.An example of a simple paper wallet from bitaddress.org +.An example of a simple paper wallet image::images/mbc2_0408.png[] -((("bitcoin improvement proposals", "Encrypted Private Keys (BIP-38)")))The disadvantage of a simple paper wallet system is that the printed keys are vulnerable to theft. A thief who is able to gain access to the paper can either steal it or photograph the keys and take control of the bitcoin locked with those keys. A more sophisticated paper wallet storage system uses BIP-38 encrypted private keys. The keys printed on the paper wallet are protected by a passphrase that the owner has memorized. Without the passphrase, the encrypted keys are useless. Yet, they still are superior to a passphrase-protected web, desktop, or mobile wallet because the keys have never been online and must be physically retrieved from a safe or other physically secured storage. <> shows a paper wallet with an encrypted private key (BIP-38) created on the bitaddress.org site. - -[[paper_wallet_encrypted]] -.An example of an encrypted paper wallet from bitaddress.org. The passphrase is "test." -image::images/mbc2_0409.png[] - -[WARNING] -==== -Although you can deposit funds into a paper wallet several times, you should withdraw all funds only once, spending everything. This is because in the process of unlocking and spending funds some wallets might generate a change address if you spend less than the whole amount. If the computer you use to sign the transaction is then compromised, you risk exposing the private key, giving access to the funds in the change address. By spending the entire balance of a paper wallet only once, you reduce the risk of key compromise. If you need only a small amount, send any remaining funds to a new paper wallet in the same transaction. -==== - -Paper wallets come in many designs and sizes, with many different features. Some are intended to be given as gifts and have seasonal themes, such as Christmas and New Year's themes. Others are designed for storage in a bank vault or safe with the private key hidden in some way, either with opaque scratch-off stickers, or folded and sealed with tamper-proof adhesive foil. Figures pass:[#paper_wallet_bpw] through pass:[#paper_wallet_spw] show various examples of paper wallets with security and backup features. - -[[paper_wallet_bpw]] -.An example of a paper wallet from bitcoinpaperwallet.com with the private key on a folding flap -image::images/mbc2_0410.png[] - -[[paper_wallet_bpw_folded]] -.The bitcoinpaperwallet.com paper wallet with the private key concealed -image::images/mbc2_0411.png[] +Some are intended to be given as gifts and have seasonal themes, such as Christmas and New Year's themes. Others are designed for storage in a bank vault or safe with the private key hidden in some way, either with opaque scratch-off stickers, or folded and sealed with tamper-proof adhesive foil. Other designs feature additional copies of the key and address, in the form of detachable stubs similar to ticket stubs, allowing you to store multiple copies to protect against fire, flood, or other natural disasters.((("", startref="KAadvanced04")))((("", startref="Wpaper04")))((("", startref="paperw04"))) [[paper_wallet_spw]]