diff --git a/appa_whitepaper.adoc b/appa_whitepaper.adoc index 1a957f8e..6f71ed29 100644 --- a/appa_whitepaper.adoc +++ b/appa_whitepaper.adoc @@ -37,7 +37,7 @@ The ((("timestamp servers")))solution we propose begins with a timestamp server. image::images/mbc3_aain02.png["timestamp server"] ==== Proof-of-Work -To ((("Proof-of-Work algorithm", "in Bitcoin whitepaper", secondary-sortas="Bitcoin whitepaper")))implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it. +To ((("proof-of-work algorithm", "in Bitcoin whitepaper", secondary-sortas="Bitcoin whitepaper")))implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it. image::images/mbc3_aain03.png["pow"] diff --git a/appb_errata.adoc b/appb_errata.adoc index d262ac87..373affe6 100644 --- a/appb_errata.adoc +++ b/appb_errata.adoc @@ -107,7 +107,7 @@ chain-like; it’s more accurately described as a directed acyclic ((("transacti === Proof of Work ____ -"we((("Proof-of-Work algorithm", "errata in Bitcoin whitepaper", id="proof-errata"))) implement the proof-of-work by incrementing a nonce in the block +"...we((("proof-of-work algorithm", "errata in Bitcoin whitepaper", id="proof-errata"))) implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block’s hash the required zero bits." ____ @@ -135,7 +135,7 @@ transaction as payment, and honest nodes will never accept a block containing them." ____ -"proof-of-work difficulty is determined by a moving average targeting an +"...proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour." ____ @@ -148,13 +148,13 @@ Further, the average implemented in Bitcoin targets an average number of blocks per two weeks (not per hour as might be implied by the text). Other implemented rules may further slow adjustments, such as a rule that the adjustment cannot increase block production speed by more than -300% per period, nor slow it by more ((("Proof-of-Work algorithm", "errata in Bitcoin whitepaper", startref="proof-errata")))than 75%. +300% per period, nor slow it by more ((("proof-of-work algorithm", "errata in Bitcoin whitepaper", startref="proof-errata")))than 75%. === Reclaiming Disk Space ____ "Once the ((("disk space, reclaiming")))((("reclaiming disk space")))((("blocks", "reclaiming disk space")))latest transaction in a coin is buried under enough blocks, the -spent transactions before it can be discarded to save disk space" +spent transactions before it can be discarded to save disk space." ____ * *Possible post-publication discovery:* Although the merkle tree diff --git a/appc_bips.adoc b/appc_bips.adoc index 54ebed2f..c3120d2f 100644 --- a/appc_bips.adoc +++ b/appc_bips.adoc @@ -18,7 +18,7 @@ significantly changed. BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin Core", id="bips-implement")))((("Bitcoin Core", "BIPs implemented by", id="bitcoin-core-bips")))implemented by Bitcoin Core: -- BIP9: The changes allowing multiple soft-forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575). +- BIP9: The changes allowing multiple soft forks to be deployed in parallel have been implemented since v0.12.1 (PR #7575). - BIP11: Multisig outputs are standard since v0.6.0 (PR #669). - BIP13: The address format for P2SH addresses has been implemented since v0.6.0 (PR #669). - BIP14: The subversion string is being used as User Agent since v0.6.0 (PR #669). @@ -37,7 +37,7 @@ BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin - BIP44: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP44. (PR #16528) - BIP49: The experimental descriptor wallets introduced in v0.21.0 by default use the Hierarchical Deterministic Wallet derivation proposed by BIP49. (PR #16528) - BIP61: The 'reject' protocol message (and the protocol version bump to 70002) was added in v0.9.0 (PR #3185). Starting v0.17.0, whether to send reject messages can be configured with the -enablebip61 option, and support is deprecated (disabled by default) as of v0.18.0. Support was removed in v0.20.0 (PR #15437). -- BIP65: The CHECKLOCKTIMEVERIFY softfork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only CLTV was added in PR #6124. +- BIP65: The CHECKLOCKTIMEVERIFY soft fork was merged in v0.12.0 (PR #6351), and backported to v0.11.2 and v0.10.4. Mempool-only CLTV was added in PR #6124. - BIP66: The strict DER rules and associated version 3 blocks have been implemented since v0.10.0 (PR #5713). - BIP68: Sequence locks have been implemented as of v0.12.1 (PR #7184), and have been buried since v0.19.0 (PR #16060). - BIP70 71 72: Payment Protocol support has been available in Bitcoin Core GUI since v0.9.0 (PR #5216). Support can be optionally disabled at build time since v0.18.0 (PR 14451), and it is disabled by default at build time since v0.19.0 (PR #15584). It has been removed as of v0.20.0 (PR 17165). @@ -54,7 +54,7 @@ BIPs that are ((("Bitcoin Improvement Proposals (BIPs)", "implemented by Bitcoin - BIP143: Transaction Signature Verification for Version 0 Witness Program as of v0.13.0 (PR 8149), defined for mainnet as of v0.13.1 (PR 8937), and buried since v0.19.0 (PR #16060). - BIP144: Segregated Witness as of 0.13.0 (PR 8149). - BIP145: getblocktemplate updates for Segregated Witness as of v0.13.0 (PR 8149). -- BIP147: NULLDUMMY softfork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060). +- BIP147: NULLDUMMY soft fork as of v0.13.1 (PR 8636 and PR 8937), buried since v0.19.0 (PR #16060). - BIP152: Compact block transfer and related optimizations are used as of v0.13.0 (PR 8068). - BIP155: The 'addrv2' and 'sendaddrv2' messages which enable relay of Tor V3 addresses (and other networks) are supported as of v0.21.0 (PR 19954). - BIP157 158: Compact Block Filters for Light Clients can be indexed as of v0.19.0 (PR #14121) and served to peers on the P2P network as of v0.21.0 (PR #16442). diff --git a/author_bio.html b/author_bio.html index d29adb57..acddf95a 100644 --- a/author_bio.html +++ b/author_bio.html @@ -1,13 +1,13 @@

About the Authors

-

Andreas M. Antonopoulos is a noted technologist and serial entrepreneur who has become one of the most well-known and well-respected figures in bitcoin. As an engaging public speaker, teacher, and writer, Andreas makes complex subjects accessible and easy to understand. As an advisor, he helps startups recognize, evaluate, and navigate security and business risks.

+

Andreas M. Antonopoulos is a noted technologist and serial entrepreneur who has become one of the most well-known and well-respected figures in Bitcoin. As an engaging public speaker, teacher, and writer, Andreas makes complex subjects accessible and easy to understand. As an advisor, he helps startups recognize, evaluate, and navigate security and business risks.

Andreas grew up with the internet, starting his first company, an early BBS and proto-ISP, as a teenager in his home in Greece. He earned degrees in computer science, data communications, and distributed systems from University College London (UCL)—recently ranked among the world’s top 10 universities. After moving to the United States, Andreas cofounded and managed a successful technology research company, and in that role advised dozens of Fortune 500 company executives on networking, security, data centers, and cloud computing. More than 200 of his articles on security, cloud computing, and data centers have been published in print and syndicated worldwide. He holds two patents in networking and security.

In 1990, Andreas started teaching various IT topics in private, professional, and academic environments. He honed his speaking skills in front of audiences ranging in size from five executives in a boardroom to thousands of people in large conferences. With more than 400 speaking engagements under his belt, he is considered a world-class and charismatic public speaker and teacher. In 2014, he was appointed as a teaching fellow with the University of Nicosia, the first university in the world to offer a masters degree in digital currency. In this role, he helped develop the curriculum and cotaught the Introduction to Digital Currencies course, offered as a massive open online course (MOOC) through the university.

-

As a bitcoin entrepreneur, Andreas has founded a number of bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.

+

As a bitcoin entrepreneur, Andreas has founded a number of Bitcoin businesses and launched several community open source projects. He serves as an advisor to several bitcoin and cryptocurrency companies. He is a widely published author of articles and blog posts on bitcoin, a permanent host on the popular Let’s Talk Bitcoin podcast, and a frequent speaker at technology and security conferences worldwide.

David A. Harding is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter (2018–23), 21.co Bitcoin Computer tutorials (2015–17), and Bitcoin.org developer documentation (2014–15). He is also a Brink.dev grant committee member (2022–23) and former board member (2020–22).

diff --git a/ch01_intro.adoc b/ch01_intro.adoc index 05b66f45..34526736 100644 --- a/ch01_intro.adoc +++ b/ch01_intro.adoc @@ -116,7 +116,7 @@ through a central clearinghouse. The Bitcoin network started in 2009, based on a reference implementation published by Nakamoto and since revised by many other programmers. The -number and power of machines running the((("Proof-of-Work algorithm", seealso="mining"))) Proof-of-Work algorithm +number and power of machines running the((("proof-of-work algorithm", seealso="mining"))) proof-of-work algorithm (mining) that provides security and resilience for Bitcoin have increased exponentially, and their combined computational power now exceeds the combined number of computing operations of the diff --git a/ch02_overview.adoc b/ch02_overview.adoc index bf24698f..c84f2836 100644 --- a/ch02_overview.adoc +++ b/ch02_overview.adoc @@ -67,7 +67,7 @@ Alice, ((("transactions", "spending bitcoins", id="transaction-spend")))((("bitc acquired her first bitcoins. In <>, Alice met with her friend Joe to exchange some cash for bitcoins. Since then, Alice has bought additional bitcoins. Now Alice will make -her first spending transaction: buying access to a premium podcast episode from Bob's online store. +her first spending transaction, buying access to a premium podcast episode from Bob's online store. Bob's web store recently started accepting bitcoin payments by adding a Bitcoin option to its website. The prices at Bob's store are listed in @@ -501,7 +501,7 @@ valid block something that requires an incredible amount of work to create but only a trivial amount of work to verify. The simple verification process is able to probabalistically prove the work was done, so the data necessary to generate that proof--in this case, the -block--is called ((("Proof-of-Work algorithm")))proof of work (PoW). +block--is called ((("proof-of-work algorithm")))proof of work (PoW). Transactions are added to the new block, prioritized by the highest fee rate transactions first and a few other criteria. Each miner starts the diff --git a/ch03_bitcoin-core.adoc b/ch03_bitcoin-core.adoc index 2676ffc7..23e7a760 100644 --- a/ch03_bitcoin-core.adoc +++ b/ch03_bitcoin-core.adoc @@ -70,7 +70,7 @@ If you're a developer, you will want to set up a development environment with all the tools, libraries, and support software for writing Bitcoin applications. In this highly technical chapter, we'll walk through that -process step-by-step. If the material becomes too dense (and you're not +process step by step. If the material becomes too dense (and you're not actually setting up a development environment) feel free to skip to the next chapter, which is less technical. @@ -928,7 +928,7 @@ f6cd83c3ca "difficulty": 157416.4018436489, "chainwork": "[...]00000000000000000000000000000000000000541788211ac227bc", "nTx": 13, - "previousblockhash": "[...]0b60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095", + "previousblockhash": "[...]60bc96a44724fd72daf9b92cf8ad00510b5224c6253ac40095", "nextblockhash": "[...]00129f5f02be247070bf7334d3753e4ddee502780c2acaecec6d66", "strippedsize": 4179, "size": 4179, diff --git a/ch04_keys.adoc b/ch04_keys.adoc index 9c8aca4c..bf41ae69 100644 --- a/ch04_keys.adoc +++ b/ch04_keys.adoc @@ -328,7 +328,7 @@ resulting public key, a point on the curve. Because the generator point is always the same for all Bitcoin users, a private key _k_ multiplied with _G_ will always result in the same public key _K_. The relationship between _k_ and _K_ is fixed but can only be calculated in one -direction, from _k_ to _K_. That's why a Bitcoin public key can be +direction, from _k_ to _K_. That's why a Bitcoin public key (_K_) can be shared with anyone and does not reveal the user's private key (_k_). [TIP] @@ -1327,7 +1327,7 @@ program (2 bytes) with a null value. Now that we know the version number and the witness program, we can convert each of them into a bech32 address. Let's use the bech32m reference -library for Python to quickly generate those addresses and then take a +library for Python to quickly generate those addresses, and then take a deeper look at what's happening: ---- @@ -1385,7 +1385,7 @@ decode(hrp, addr) >>> _[0], bytes(_[1]).hex() (0, '2b626ed108ad00a944bb2922a309844611d25468') >>> _ = decode("bc", - "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7") + "bc1p9nh05ha8wrljf7ru236awm4t2x0d5ctkkywmu9sclnm4t0av2vgs4k3au7") >>> _[0], bytes(_[1]).hex() (1, '2ceefa5fa770ff24f87c5475d76eab519eda6176b11dbe1618fcf755bfac5311') ---- @@ -1528,9 +1528,9 @@ 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" +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 +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 diff --git a/ch05_wallets.adoc b/ch05_wallets.adoc index 5e8cc653..998edc84 100644 --- a/ch05_wallets.adoc +++ b/ch05_wallets.adoc @@ -125,8 +125,8 @@ subtraction, and multiplication operations used in regular arithmetic. In other words, it's possible to add or subtract from a public key, or to multiply it. Consider the operation we used in <> for -generating a public key (K) from a private key (k) using the generator -point (G): +generating a public key (_K_) from a private key (_k_) using the generator +point (_G_): ---- K = k * G @@ -150,8 +150,8 @@ true) if the two sides aren't equivalent. An interesting consequence of this is that adding `123` to the public key can be done using entirely public information. For example, Alice -generates public key K and gives it to Bob. Bob doesn't know the -private key, but he does know the global constant G, so he can add any +generates public key _K_ and gives it to Bob. Bob doesn't know the +private key, but he does know the global constant _G_, so he can add any value to the public key to produce a derived public child key. If he then tells Alice the value he added to the public key, she can add the same value to the private key, producing a derived private child key @@ -966,7 +966,7 @@ greater the entropy, the harder it will be for them to figure out part of the code they didn't see. For example, if an attacker sees half of a 128-bit code (64 bits), it's plausible that they'll be able to brute force the remaining 64 bits. If they see half of a 256-bit code (128 -bits), it's not plausible they can brute force the other half. We +bits), it's not plausible that they can brute force the other half. We don't recommend relying on this defense--either keep your recovery codes very safe or use a method like SLIP39 that lets you distribute your recovery code across multiple locations without relying on the safety of @@ -1474,7 +1474,7 @@ The first-level "purpose" is always set to +44'+. The second-level "coin_type" specifies the type of cryptocurrency coin, allowing for multicurrency HD wallets where each currency has its own subtree under the second level. Bitcoin is -m/44'/0' and Bitcoin Testnet is m/44++'++/1++'++. +m/44'/0++'++ and Bitcoin Testnet is m/44++'++/1++'++. The third level of the tree is "account," which allows users to subdivide their wallets into separate logical subaccounts for diff --git a/ch06_transactions.adoc b/ch06_transactions.adoc index 5bfa05f4..e47ce269 100644 --- a/ch06_transactions.adoc +++ b/ch06_transactions.adoc @@ -488,8 +488,8 @@ transaction with a different version an unlimited number of times. Each replacement would consume the bandwidth of all the relaying full nodes on the network. For example, as of this writing, there are about 50,000 relaying full nodes; an attacker creating 1,000 replacement transactions -per minute at 200 bytes each would use about 20 kilobytes of their -personal bandwidth but about 10 gigabytes of full node network bandwidth +per minute at 200 bytes each would use about 20 KB of their +personal bandwidth but about 10 GB of full node network bandwidth every minute. Except for the cost of their 20 KB/minute bandwidth and the occasional fee when a transaction got confirmed, the attacker wouldn't need to pay any costs for the enormous burden they placed on full node @@ -601,7 +601,7 @@ The example transaction has two outputs. The first((("transactions", "outputs", "amount field", id="transaction-output-amount")))((("outputs", "amount field", id="output-transaction-amount")))((("amount field (transaction outputs)", id="amount-field"))) field of a specific output is its _amount_, also called "value" in Bitcoin Core. This is an 8-byte signed integer indicating -the number of _satoshis_ to transfer. A satoshi is the smallest unit of +the number of satoshis to transfer. A satoshi is the smallest unit of bitcoin that can be represented in an onchain Bitcoin transaction. There are 100 million satoshis in a bitcoin. @@ -629,8 +629,7 @@ at a typical fee rate on the network today, an output might add more value to a transaction than it costs to spend--but tomorrow, fee rates might rise and make the output uneconomical. -The need for full nodes to keep track of all unspent transaction outputs -(UTXOs), as described in <>, means that every UTXO makes it +The need for full nodes to keep track of all UTXOs, as described in <>, means that every UTXO makes it slightly harder to run a full node. For UTXOs containing significant value, there's an incentive to eventually spend them, so they aren't a problem. But there's no incentive for the person controlling an @@ -655,7 +654,7 @@ check whether the policy has changed since publication of this book. [TIP] ==== Since Bitcoin's inception, every full node has needed to keep a copy of -every unspent transaction output (UTXO), but that might not always be +every UTXO, but that might not always be the case. Several developers have been working on((("Utreexo"))) Utreexo, a project that allows full nodes to store a commitment to the set of UTXOs rather than the data itself. A minimal commitment might be only a kilobyte or @@ -983,14 +982,15 @@ be received to witness programs and spent with the witness structure. The terms ++++ - + - - - + + + + - + @@ -1165,12 +1165,13 @@ creation of uneconomical outputs as described in ++++
Terms used for authorization and authentication data in different parts of Bitcoin
-

Authorization

Authentication

+

Authorization

Authentication

Whitepaper

Whitepaper

Public key

Signature
- + - - - - + + + + + diff --git a/ch07_authorization-authentication.adoc b/ch07_authorization-authentication.adoc index 074170ed..589b20d9 100644 --- a/ch07_authorization-authentication.adoc +++ b/ch07_authorization-authentication.adoc @@ -625,7 +625,7 @@ For example, Mohammed's complex script, hashed and base58check-encoded as a P2SH address, becomes +39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw+. Now, Mohammed can give this "address" to his customers, and they can use -almost any Bitcoin wallet to make a simple payment like any other +almost any Bitcoin wallet to make a simple payment, like any other Bitcoin address. The 3 prefix gives them a hint that this is a special type of address, one corresponding to a script instead of a public key, but otherwise it works in exactly the same way as a payment to any other Bitcoin @@ -910,7 +910,7 @@ the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode. Relative timelocks are implemented according to the specifications in https://oreil.ly/ZuANb[BIP68, -relative lock-time using consensus-enforced sequence numbers] and +relative Lock-Time Using Consensus-Enforced Sequence Numbers] and https://oreil.ly/dLA2r[BIP112, +OP_CHECKSEQUENCEVERIFY+]. @@ -1257,9 +1257,9 @@ Try running the script on paper to see how it behaves on the stack. Let’s look at ((("scripts", "segregated witness", id="script-segwit")))((("segregated witness (segwit)", "scripts and", id="segwit-script")))some of our example transactions and see how they would change with segregated witness. We’ll first look at how a -pay to public key hash (P2PKH) payment can be accomplished as the +pay to public key hash P2PKH payment can be accomplished as the segregated witness program. Then, we’ll look at the segregated witness -equivalent for pay to script hash (P2SH) scripts. Finally, we’ll look at +equivalent for P2SH scripts. Finally, we’ll look at how both of the preceding segregated witness programs can be embedded inside a P2SH script. @@ -1352,10 +1352,10 @@ to the receiver in the manner that the receiver indicated. ==== [[p2wsh]] -===== Pay to witness script hash +===== Pay to witness script hash (P2WSH) The ((("scripts", "segregated witness", "P2WSH", id="script-segwit-p2wsh")))((("segregated witness (segwit)", "scripts and", "P2WSH", id="segwit-script-p2wsh")))((("P2WSH (pay to witness script hash)", id="p2wsh-ch7")))((("output scripts", "P2WSH (pay to witness script hash)", id="output-script-p2wsh")))second type of -segwit v0 witness program corresponds to a pay to script hash (P2SH) script. We +segwit v0 witness program corresponds to a P2SH script. We saw this type of script in <>. In that example, P2SH was used by Mohammed's company to express a multisignature script. Payments to Mohammed's company were encoded with a script like this: diff --git a/ch08_signatures.adoc b/ch08_signatures.adoc index 1131f273..e08485c8 100644 --- a/ch08_signatures.adoc +++ b/ch08_signatures.adoc @@ -344,7 +344,7 @@ curve called the Generator (+G+) (see <>). Alice uses EC multiplication to multiply +G+ by her private key +x+, in which case +x+ is called a _scalar_ because it scales up +G+. The result is +xG+, which we call Alice's _public key_. Alice gives her public key to Bob. -Even though Bob also knows +G+, the Discrete Logarithm Problem prevents Bob from being able to divide +xG+ by +G+ to derive Alice's +Even though Bob also knows +G+, the DLP prevents Bob from being able to divide +xG+ by +G+ to derive Alice's private key. At some later time, Bob wants Alice to identify herself by proving @@ -959,7 +959,7 @@ recommends a default signing algorithm. BIP340 and RFC6979 can generate _k_ entirely deterministically, meaning the same transaction data will always produce the same _k_. Many wallets do this because it makes it easy to write tests to verify their safety-critical -signing code is producing _k_ values correctly. RFC6979 also allows +signing code is producing _k_ values correctly. BIP340 and RFC6979 both also allow including additional data in the calculation. If that data is entropy, then a different _k_ will be produced even if the exact same transaction data is signed. This can increase protection against sidechannel and diff --git a/ch09_fees.adoc b/ch09_fees.adoc index 80e62b48..b36306de 100644 --- a/ch09_fees.adoc +++ b/ch09_fees.adoc @@ -125,8 +125,8 @@ fee rates. ==== Be careful ((("absurd fees")))((("excessive fees")))((("transaction fees", "overpaying")))((("overpaying transaction fees")))accepting input for fee rates. If a user copies and pastes a fee rate printed in one denominator into a field using a different -enumerator, they could overpay fees by 1,000 times. If they instead -switch the enumerator, they could theoretically overpay by 100,000,000 +denominator, they could overpay fees by 1,000 times. If they instead +switch the denominator, they could theoretically overpay by 100,000,000 times. Wallets should make it hard for the user to pay an excessive fee rate and may want to prompt the user to confirm any fee rate that was not generated by the wallet itself using a trusted data source. diff --git a/ch10_network.adoc b/ch10_network.adoc index b4ded298..b890670d 100644 --- a/ch10_network.adoc +++ b/ch10_network.adoc @@ -312,7 +312,7 @@ Once one or more connections are established, the new node will send an neighbors will, in turn, forward the +addr+ message to their neighbors, ensuring that the newly connected node becomes well known and better connected. Additionally, the newly connected node can send +getaddr+ to -the neighbors, asking them to return a list of IP addresses of other +its neighbors, asking them to return a list of IP addresses of other peers. That way, a node can find peers to connect to and advertise its existence on the network for other nodes to find it. <> shows the address discovery protocol. @@ -741,7 +741,7 @@ incoming transaction. The full node checks several parts of the transaction against the bloom filter, looking for a match including: * The transaction ID -* The data components from the locking scripts of each of the transaction outputs (every key and hash in the script) +* The data components from the scripts of each of the transaction outputs (every key and hash in the script) * Each of the transaction inputs * Each of the input signature data components (or witness scripts) diff --git a/ch11_blockchain.adoc b/ch11_blockchain.adoc index 1da43f46..f146903c 100644 --- a/ch11_blockchain.adoc +++ b/ch11_blockchain.adoc @@ -545,7 +545,7 @@ and block and between the block and blockchain, proves that the transaction is recorded in the blockchain. All in all, the lightweight client 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 2 megabytes ((("blockchain", "merkle trees", startref="blockchain-merkle")))((("merkle trees", startref="merkle-tree-explain")))currently). +than a full block (about 2 MB ((("blockchain", "merkle trees", startref="blockchain-merkle")))((("merkle trees", startref="merkle-tree-explain")))currently). === Bitcoin's Test Blockchains @@ -640,9 +640,9 @@ used to test segregated witness features. ===== Problems with testnet Testnet doesn't just use the same data structures as Bitcoin, it also -uses almost exactly the same proof-of-work (PoW) security mechanism as +uses almost exactly the same PoW security mechanism as Bitcoin. The notable differences for testnet are that its minimum -difficulty is half that of Bitcoin and it's allowed to include a +difficulty is half that of Bitcoin and that it's allowed to include a block at the minimum difficulty if that block's timestamp is more than 20 minutes after the previous block. @@ -693,7 +693,7 @@ start your own signet and connect your software to it. Bitcoin Core supports((("Bitcoin Core", "signet")))((("default signet")))((("custom signets"))) a default signet, which we believe to be the most widely used signet at the time of writing. It is currently operated by two contributors to that project. If you start Bitcoin Core with the -+-signet+ parameter and no other signet-related parameters, this is the ++signet+ parameter and no other signet-related parameters, this is the signet you will be using. As of this writing, the default signet has about 150,000 blocks and is @@ -769,7 +769,6 @@ too. Let's try the +getblockchaininfo+ command to inspect the regtest blockchain: ---- -git comm $ bitcoin-cli -regtest getblockchaininfo { "chain": "regtest", diff --git a/ch12_mining.adoc b/ch12_mining.adoc index 3e0e5e89..0ea4982d 100644 --- a/ch12_mining.adoc +++ b/ch12_mining.adoc @@ -58,7 +58,7 @@ the block. To earn this reward, miners compete to satisfy a challenge based on a cryptographic hash algorithm. The solution to the problem, called the proof of work, is included in the new block and acts as proof that the miner expended significant -computing effort. The competition to solve the Proof-of-Work algorithm +computing effort. The competition to solve the proof-of-work algorithm to earn the reward and the right to record transactions on the blockchain is the basis for Bitcoin's security model. @@ -665,7 +665,7 @@ The witness root hash is added to an output of the coinbase transaction. This step may be skipped if none of the transactions in the block are required to contain a witness structure. Each transaction (including the coinbase transaction) is then listed using its transaction -identifier (_txid_) and used to build a second merkle tree, the root of +identifier (txid) and used to build a second merkle tree, the root of which becomes the merkle root, to which the block header commits. Jing's mining node will then add a 4-byte timestamp, encoded as a Unix @@ -712,7 +712,7 @@ until the desired hash result appears by chance. ==== Proof-of-Work Algorithm -A hash((("bitcoins", "mining", "Proof-of-Work algorithm", id="bitcoin-mining-proof")))((("mining", "Proof-of-Work algorithm", id="mining-proof")))((("hash functions", "Proof-of-Work algorithm", id="hash-proof")))((("Proof-of-Work algorithm", id="proof-mining"))) algorithm takes an +A hash((("bitcoins", "mining", "proof-of-work algorithm", id="bitcoin-mining-proof")))((("mining", "proof-of-work algorithm", id="mining-proof")))((("hash functions", "proof-of-work algorithm", id="hash-proof")))((("proof-of-work algorithm", id="proof-mining"))) algorithm takes an arbitrary-length data input and produces a fixed-length deterministic result, called a _digest_. The digest is a digital commitment to the input. For any specific input, the resulting digest will always be the @@ -779,12 +779,12 @@ 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 more dice throws to win -the lower the target gets. Eventually, when the target is 2 (the minimum +the lower the target gets. Eventually, when the target is 3 (the minimum possible), only one throw out of every 36, or about 3% 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 +dice game is 3, 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 @@ -833,7 +833,7 @@ _target_. If the hash is not less than the target, the miner will modify the nonce (usually just incrementing it by one) and try again. At the current difficulty in the Bitcoin network, miners have to try a huge number of times before finding a nonce that results in a low -enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoin-mining-proof")))((("mining", "Proof-of-Work algorithm", startref="mining-proof")))((("hash functions", "Proof-of-Work algorithm", startref="hash-proof")))((("Proof-of-Work algorithm", startref="proof-mining"))) header hash. +enough block((("bitcoins", "mining", "proof-of-work algorithm", startref="bitcoin-mining-proof")))((("mining", "proof-of-work algorithm", startref="mining-proof")))((("hash functions", "proof-of-work algorithm", startref="hash-proof")))((("proof-of-work algorithm", startref="proof-mining"))) header hash. [[target_bits]] ==== Target Representation @@ -841,7 +841,7 @@ enough block((("bitcoins", "mining", "Proof-of-Work algorithm", startref="bitcoi //TODO:use visual representation like I did on bitcoin.org -Block headers ((("bitcoins", "mining", "target representation", id="bitcoin-mining-target")))((("mining", "target representation", id="mining-target")))((("targets", "representation of", id="target-represent")))((("Proof-of-Work algorithm", "target representation", id="proof-target")))contain the target in a notation called "target +Block headers ((("bitcoins", "mining", "target representation", id="bitcoin-mining-target")))((("mining", "target representation", id="mining-target")))((("targets", "representation of", id="target-represent")))((("proof-of-work algorithm", "target representation", id="proof-target")))contain the target in a notation called "target bits" or just "bits," which in block 277,316 has the value of +0x1903a30c+. This notation expresses the proof-of-work target as a coefficient/exponent format, with the first two hexadecimal digits for @@ -890,12 +890,12 @@ header hash less than the target. In binary that number must have more than 60 leading bits set to zero. With this level of difficulty, a single miner processing 1 trillion hashes per second (1 terahash per second or 1 TH/sec) would only find a solution once every -8,496 blocks or once every 59 days, ((("bitcoins", "mining", "target representation", startref="bitcoin-mining-target")))((("mining", "target representation", startref="mining-target")))((("targets", "representation of", startref="target-represent")))((("Proof-of-Work algorithm", "target representation", startref="proof-target")))on average. +8,496 blocks or once every 59 days, ((("bitcoins", "mining", "target representation", startref="bitcoin-mining-target")))((("mining", "target representation", startref="mining-target")))((("targets", "representation of", startref="target-represent")))((("proof-of-work algorithm", "target representation", startref="proof-target")))on average. [[target]] ==== Retargeting to Adjust Difficulty -As we saw, ((("bitcoins", "mining", "adjusting difficulty", id="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", id="mining-difficulty")))((("targets", "adjusting difficulty", id="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", id="proof-difficulty")))((("difficulty", "adjusting", id="difficulty-adjust")))the target determines the difficulty and +As we saw, ((("bitcoins", "mining", "adjusting difficulty", id="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", id="mining-difficulty")))((("targets", "adjusting difficulty", id="target-difficulty")))((("proof-of-work algorithm", "adjusting difficulty", id="proof-difficulty")))((("difficulty", "adjusting", id="difficulty-adjust")))the target determines the difficulty and therefore affects how long it takes to find a solution to the proof-of-work algorithm. This leads to the obvious questions: Why is the difficulty adjustable, who adjusts it, and how? @@ -998,7 +998,7 @@ possible with the current generation of silicon fabrication, converting electricity into hashing computation at the highest rate possible. The primary influence on the mining market is the price of one kilowatt-hour of electricity in bitcoin because that determines the profitability of -mining and therefore the incentives to enter or exit the ((("bitcoins", "mining", "adjusting difficulty", startref="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", startref="mining-difficulty")))((("targets", "adjusting difficulty", startref="target-difficulty")))((("Proof-of-Work algorithm", "adjusting difficulty", startref="proof-difficulty")))((("difficulty", "adjusting", startref="difficulty-adjust")))mining +mining and therefore the incentives to enter or exit the ((("bitcoins", "mining", "adjusting difficulty", startref="bitcoin-mining-difficulty")))((("mining", "adjusting difficulty", startref="mining-difficulty")))((("targets", "adjusting difficulty", startref="target-difficulty")))((("proof-of-work algorithm", "adjusting difficulty", startref="proof-difficulty")))((("difficulty", "adjusting", startref="difficulty-adjust")))mining market. [[mtp]] @@ -1420,7 +1420,7 @@ Managed pools ((("P2Pool (peer-to-peer mining pool)", id="p2pool")))using Stratu the pool operator, who might direct the pool effort to double-spend transactions or invalidate blocks (see <>). Furthermore, centralized pool servers represent a -single-point-of-failure. If the pool server is down or is slowed by a +single point of failure. If the pool server is down or is slowed by a denial-of-service attack, the pool miners cannot mine. In 2011, to resolve these issues of centralization, a new pool mining method was proposed and implemented: P2Pool, a peer-to-peer mining pool without a diff --git a/ch13_security.adoc b/ch13_security.adoc index b8b10ad8..4d01ba9a 100644 --- a/ch13_security.adoc +++ b/ch13_security.adoc @@ -262,7 +262,7 @@ 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 +independently and held by several company executives to ensure that 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. diff --git a/ch14_applications.adoc b/ch14_applications.adoc index 74703926..056b7d5c 100644 --- a/ch14_applications.adoc +++ b/ch14_applications.adoc @@ -17,7 +17,7 @@ When ((("Bitcoin", "as application platform", "primitives, list of", secondary-s long term, the Bitcoin system offers certain guarantees, which can be used as building blocks to create applications. These include: -No Double-Spend:: The most fundamental guarantee of Bitcoin's +No double-spend:: The most fundamental guarantee of Bitcoin's decentralized consensus algorithm ensures that no UTXO can be spent twice in the same valid chain of blocks. @@ -35,7 +35,7 @@ This means that anyone can create a valid transaction with sufficient fees and trust they will be able to transmit that transaction and have it included in the blockchain at any time. -Secure Timestamping:: The consensus rules reject any block whose +Secure timestamping:: The consensus rules reject any block whose timestamp is too far in the future and attempt to prevent blocks with timestamps too far in the past. This ensures that timestamps on blocks can be trusted to a certain degree. The timestamp on a block implies an @@ -64,20 +64,20 @@ a transaction signed by another +SIGHASH+ type cannot be modified without invalidating the signature, thus invalidating the transaction itself. -Transaction Atomicity:: Bitcoin transactions are atomic. They are either +Transaction atomicity:: Bitcoin transactions are atomic. They are either valid and confirmed (mined) or not. Partial transactions cannot be mined, and there is no interim state for a transaction. At any point in time a transaction is either mined or not. -Discrete (Indivisible) Units of Value:: Transaction outputs are discrete +Discrete (indivisible) units of value:: Transaction outputs are discrete and indivisible units of value. They can either be spent or unspent, in full. They cannot be divided or partially spent. -Quorum of Control:: Multisignature constraints in scripts impose a +Quorum of control:: Multisignature constraints in scripts impose a quorum of authorization, predefined in the multisignature scheme. The requirement is enforced by the consensus rules. -Timelock/Aging:: Any script clause containing a relative or absolute +Timelock/aging:: Any script clause containing a relative or absolute timelock can only be executed after its age exceeds the time specified. Replication:: The decentralized storage of the blockchain ensures that @@ -85,7 +85,7 @@ when a transaction is mined, after sufficient confirmations, it is replicated across the network and becomes durable and resilient to power loss, data loss, etc. -Forgery Protection:: A transaction can only spend existing, validated +Forgery protection:: A transaction can only spend existing, validated outputs. It is not possible to create or counterfeit value. Consistency:: In the absence of miner partitions, blocks that are @@ -94,11 +94,11 @@ with exponentially decreasing likelihood, based on the depth at which they are recorded. Once deeply recorded, the computation and energy required to change makes change practically infeasible. -Recording External State:: A transaction can commit to a data value, via +Recording external state:: A transaction can commit to a data value, via +OP_RETURN+ or pay to contract, representing a state transition in an external state machine. -Predictable Issuance:: Less than 21 million bitcoin will be issued at a +Predictable issuance:: Less than 21 million bitcoin will be issued at a predictable rate. The list of building blocks is not complete, and more are added with each diff --git a/preface.asciidoc b/preface.asciidoc index 8acf575d..0f9a9fb9 100644 --- a/preface.asciidoc +++ b/preface.asciidoc @@ -140,7 +140,7 @@ link:$$https://linkedin.com/company/aantonop$$[]. Many thanks to all of Andreas's patrons who support his work through monthly donations. You can follow his Patreon page here: link:$$https://patreon.com/aantonop$$[]. -Information about _Mastering Bitcoin_ as well as Andreas's Open Edition and translations is available on: +Information about _Mastering Bitcoin_, as well as Andreas's Open Edition and translations, is available on link:$$https://bitcoinbook.info$$[]. You can contact David A. Harding on his personal site: diff --git a/theme/epub/epub.css b/theme/epub/epub.css index 5859f1ca..ebda9599 100644 --- a/theme/epub/epub.css +++ b/theme/epub/epub.css @@ -1 +1,7 @@ -/* Add your custom CSS styles for the EPUB here */ \ No newline at end of file +td.fakeheader { + font-family: "MyriadPro-SemiboldCond" !important; + font-weight: 600 !important; + color: White !important; + background-color: Black !important; + border: 0pt solid cmyk(0%,0%,0%,100%); + } \ No newline at end of file diff --git a/theme/pdf/pdf.css b/theme/pdf/pdf.css index e2bb8eda..bef2328f 100644 --- a/theme/pdf/pdf.css +++ b/theme/pdf/pdf.css @@ -18,6 +18,15 @@ pre[data-type="programlisting"] { font-style: normal; } +td.fakeheader { + font-family: "MyriadPro-SemiboldCond" !important; + font-weight: 600 !important; + color: White !important; + background-color: Black !important; + border: 0pt solid cmyk(0%,0%,0%,100%); +} + + /*hack to align sidebars to top of page*/ .less_space {margin-top: 0 !important;}
Weight factors for all fields in a Bitcoin transaction

Field

Factor

Weight in Alice’s Tx

Field

Factor

Weight in Alice’s Tx

Version

4