mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-21 15:48:09 +00:00
OTD initial edits
This commit is contained in:
Clare Laylock
parent
c283a09026
commit
4175b9cc9d
@ -3,11 +3,11 @@
|
||||
|
||||
<p><strong>Andreas M. Antonopoulos</strong> 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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
<p>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 two hundred 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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
<p>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 four hundred 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 master's 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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
<p>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 <em>Let’s Talk Bitcoin</em> podcast, and a frequent speaker at technology and security conferences worldwide.</p>
|
||||
|
||||
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the Bitcoin Optech weekly newsletter <span class='keep-together'>(2018–2023),</span> 21.co Bitcoin Computer tutorials (2015–2017), and Bitcoin.org developer documentation (2014–2015). He is also a Brink.dev grant committee member (2022–2023) and former board member (2020–2022).</p>
|
||||
<p><strong>David A. Harding</strong> is a technical writer focused on creating documentation for open source software. He is the coauthor of the <em>Bitcoin Optech</em> weekly newsletter <span class='keep-together'>(2018–2023),</span> <em>21.co Bitcoin Computer</em> tutorials (2015–2017), and Bitcoin.org developer documentation (2014–2015). He is also a Brink.dev grant committee member (2022–2023) and former board member (2020–2022).</p>
|
||||
</section>
|
||||
|
||||
@ -7,7 +7,7 @@ Bitcoin((("Bitcoin", "operational overview", id="bitcoin-operational-overview"))
|
||||
[TIP]
|
||||
====
|
||||
In this book, the ((("bitcoins", "defined")))unit of currency is called "bitcoin" with a small _b_,
|
||||
and the system is called "Bitcoin", with a capital _B_.
|
||||
and the system is called "Bitcoin," with a capital _B_.
|
||||
====
|
||||
|
||||
Users can transfer bitcoin over the network to do just about anything
|
||||
@ -100,7 +100,7 @@ Although these earlier digital currencies worked, they were centralized and, as
|
||||
Bitcoin was((("Bitcoin", "history of")))((("history", "of Bitcoin", secondary-sortas="Bitcoin")))((("Nakamoto, Satoshi"))) first described in 2008 with the publication of a
|
||||
paper titled "Bitcoin: A Peer-to-Peer Electronic Cash
|
||||
System,"footnote:[https://oreil.ly/KUaBM["Bitcoin: A Peer-to-Peer Electronic Cash System"],
|
||||
Satoshi Nakamoto.] written under the
|
||||
Satoshi Nakamoto (see <<appendix>>).] written under the
|
||||
alias of Satoshi Nakamoto (see <<satoshi_whitepaper>>). Nakamoto
|
||||
combined several prior inventions such as digital signatures and Hashcash to create
|
||||
a completely decentralized electronic cash system that does not rely on
|
||||
|
||||
@ -35,7 +35,7 @@ relationships and flows between them.
|
||||
</p>
|
||||
++++
|
||||
|
||||
Popular blockchain explorers include:
|
||||
Popular blockchain explorers include the following:
|
||||
|
||||
* https://blockstream.info[Blockstream Explorer]
|
||||
* https://mempool.space[Mempool.Space]
|
||||
@ -101,11 +101,6 @@ description to the user. You can scan the QR code with a bitcoin wallet
|
||||
application to see what Alice would see:
|
||||
|
||||
|
||||
[TIP]
|
||||
====
|
||||
Try to scan this with your wallet to see
|
||||
the address and amount but DO NOT SEND MONEY.
|
||||
====
|
||||
[[invoice-URI]]
|
||||
.The invoice QR code encodes the following URI, defined in BIP21:
|
||||
----
|
||||
@ -121,6 +116,12 @@ A label for the recipient address: "Bob's Store"
|
||||
A description for the payment: "Purchase at Bob's Store"
|
||||
----
|
||||
|
||||
[TIP]
|
||||
====
|
||||
Try to scan this with your wallet to see
|
||||
the address and amount but DO NOT SEND MONEY.
|
||||
====
|
||||
|
||||
Alice uses her smartphone to scan the barcode on display. Her smartphone
|
||||
shows a payment for the correct amount to +Bob's Store+ and she selects Send to
|
||||
authorize the payment. Within a few seconds (about the same amount of
|
||||
|
||||
@ -881,13 +881,13 @@ was simply that the input script needed to provide an appropriate
|
||||
signature. In <<addresses_for_p2pkh>>, an appropriate public key also needed to be
|
||||
provided.
|
||||
|
||||
In order for a spender (like Alice) to place the constraints Bob wants
|
||||
For a spender (like Alice) to place the constraints Bob wants
|
||||
in the output script she uses to pay him, Bob needs to communicate those
|
||||
constraints to her. This is similar to the problem of Bob needing to
|
||||
communicate his public key to her. Like that problem, where
|
||||
public keys can be fairly large, the constraints Bob uses can also be
|
||||
quite large--potentially thousands of bytes. That's not only thousands
|
||||
of bytes which need to be communicated to Alice, but thousands of bytes
|
||||
of bytes that need to be communicated to Alice, but thousands of bytes
|
||||
for which she needs to pay transaction fees every time she wants to spend money to Bob. However, the solution of using hash functions to create
|
||||
small commitments to large amounts of data also applies here.
|
||||
|
||||
@ -1078,7 +1078,7 @@ bech32 (pronounced with a soft "ch", as in "besh thirty-two"). The
|
||||
"bech" stands for BCH, the initials of the three individuals who
|
||||
discovered the cyclic code in 1959 and 1960 upon which bech32 is based.
|
||||
The "32" stands for the number of characters in the bech32 alphabet
|
||||
(similar to the 58 in base58check).
|
||||
(similar to the 58 in base58check):
|
||||
|
||||
- Bech32 uses only numbers and a single case of letters (preferably
|
||||
rendered in lowercase). Despite its alphabet being almost half the
|
||||
@ -1095,7 +1095,7 @@ The "32" stands for the number of characters in the bech32 alphabet
|
||||
errors, it can tell the user where those errors occurred, allowing them to
|
||||
quickly correct minor transcription mistakes. See <<bech32_typo_detection>>
|
||||
for an example of an address entered with errors.
|
||||
|
||||
+
|
||||
[[bech32_typo_detection]]
|
||||
.Bech32 typo detection
|
||||
====
|
||||
@ -1112,7 +1112,7 @@ https://oreil.ly/paWIx[bech32 address decoder demo].
|
||||
encoding mode that uses less space. Notice the difference in size and
|
||||
complexity of the two QR codes for the same address in
|
||||
<<bech32_qrcode_uc_lc>>.
|
||||
|
||||
+
|
||||
[[bech32_qrcode_uc_lc]]
|
||||
.The same bech32 address QR encoded in lowercase and uppercase.
|
||||
image::images/mbc3_0409.png["The same bech32 address QR encoded in lowercase and uppercase"]
|
||||
|
||||
@ -147,7 +147,7 @@ simply adding the same value to both sides of the equation:
|
||||
[latexmath]
|
||||
++++
|
||||
\begin{equation}
|
||||
K + (123 \times G) =\!\!\!= (k + 123) \times G
|
||||
K + (123 \times G) == (k + 123) \times G
|
||||
\end{equation}
|
||||
++++
|
||||
|
||||
|
||||
@ -202,7 +202,7 @@ for BIPs 37 and 144).
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
There are several different varieties of variable length integers used
|
||||
Several varieties of variable length integers are used
|
||||
in different programs, including in different Bitcoin programs. For
|
||||
example, Bitcoin Core serializes its UTXO database using a data type it
|
||||
calls +VarInts+, which is different from compactSize. Additionally, the
|
||||
|
||||
@ -132,6 +132,8 @@ validation.
|
||||
.Combining input and output scripts to evaluate a transaction script.
|
||||
image::images/mbc3_0701.png["input_and_output_scripts"]
|
||||
|
||||
|
||||
[role="less_space pagebreak-before"]
|
||||
===== The script execution stack
|
||||
|
||||
Bitcoin's ((("scripts", "stack", id="script-stack")))((("stack", id="stack")))scripting language is called a stack-based language because it
|
||||
@ -844,8 +846,7 @@ halts execution if one of the following occurs:
|
||||
|
||||
[[timelock_conflicts]]
|
||||
.Timelock Conflicts
|
||||
[WARNING]
|
||||
====
|
||||
****
|
||||
+OP_CLTV+ and ((("transactions", "timelocks", "conflicts")))((("timelocks", "conflicts")))((("lock time", "conflicts")))((("scripts", "timelocks", "conflicts")))lock time use the same format to describe timelocks, either
|
||||
a block height or the time elapsed in seconds since the Unix epoch.
|
||||
Critically, when used together, the format of lock time must match
|
||||
@ -863,7 +864,7 @@ used in any of the scripts of a transaction. If the script for one
|
||||
input uses the height variety and a different script for a different
|
||||
input uses the time variety, there is no way to construct a valid transaction
|
||||
that spends both inputs.
|
||||
====
|
||||
****
|
||||
|
||||
After execution, if +OP_CLTV+ is satisfied, the parameter that
|
||||
preceded it remains as the top item on the stack and may need to be
|
||||
@ -918,7 +919,7 @@ implemented according to the specifications in
|
||||
https://oreil.ly/ZuANb[BIP68,
|
||||
Relative Lock-Time Using Consensus-Enforced Sequence Numbers] and
|
||||
https://oreil.ly/dLA2r[BIP112,
|
||||
+OP_CHECKSEQUENCEVERIFY+].
|
||||
OP_CHECKSEQUENCEVERIFY].
|
||||
|
||||
BIP68 and BIP112 were activated in May 2016 as a soft fork upgrade to
|
||||
the consensus rules.
|
||||
|
||||
@ -696,7 +696,7 @@ bit array. If all the bits indexed by the hash functions are set to +1+,
|
||||
then the pattern is _probably_ recorded in the bloom filter. Because the
|
||||
bits may be set because of overlap from multiple patterns, the answer is
|
||||
not certain, but is rather probabilistic. In simple terms, a bloom
|
||||
filter positive match is a "Maybe, Yes."
|
||||
filter positive match is a "Maybe, yes."
|
||||
|
||||
<<bloom4>> is an example of testing the existence of pattern "X" in the
|
||||
simple bloom filter. The corresponding bits are set to +1+, so the
|
||||
@ -710,7 +710,7 @@ On the contrary, if a pattern is tested against the bloom filter and any
|
||||
one of the bits is set to +0+, this proves that the pattern was not
|
||||
recorded in the bloom filter. A negative result is not a probability, it
|
||||
is a certainty. In simple terms, a negative match on a bloom filter is a
|
||||
"Definitely Not!"
|
||||
"Definitely not!"
|
||||
|
||||
<<bloom5>> is an example of testing the existence of pattern "Y" in the
|
||||
simple bloom filter. One of the corresponding bits is set to +0+, so the
|
||||
|
||||
@ -439,7 +439,7 @@ An extended comment in Bitcoin Core's source code, reproduced here with slight r
|
||||
significant problem in the design of Bitcoin's duplication of odd
|
||||
elements in its merkle tree:
|
||||
|
||||
[quote,Bitcoin Core src/consensus/merkle.cpp]
|
||||
[quote,Bitcoin Core _src/consensus/merkle.cpp_]
|
||||
____
|
||||
WARNING! If you're reading this because you're learning about crypto
|
||||
and/or designing a new system that will use merkle trees, keep in mind
|
||||
@ -746,7 +746,7 @@ $ bitcoin-cli -signet getblockchaininfo
|
||||
}
|
||||
----
|
||||
|
||||
==== Regtest—The Local Blockchain
|
||||
==== Regtest: The Local Blockchain
|
||||
|
||||
Regtest, ((("blockchain", "test blockchains", "regtest", id="blockchain-test-regtest")))((("test blockchains", "regtest", id="test-block-regtest")))((("regtest", id="regtest")))which stands for
|
||||
"Regression Testing," is a Bitcoin Core feature that allows you to
|
||||
|
||||
@ -750,7 +750,7 @@ this case to vary the output of the SHA256 commitment to the phrase.
|
||||
|
||||
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, as shown in <<sha256_example_generator_output2>>:
|
||||
Fortunately, this isn't difficult, as shown in <<sha256_example_generator_output2>>.
|
||||
|
||||
[[sha256_example_generator_output2]]
|
||||
.Simple proof-of-work implementation
|
||||
|
||||
@ -190,7 +190,7 @@ spending transaction.
|
||||
This provides part of the basis for the modern transfer for colored
|
||||
coins. One or more colored coins are received to a UTXO. When that
|
||||
UTXO is spent, the spending transaction must describe how the colored
|
||||
coins are to be spent. That brings us to _pay to contract (P2C)_.
|
||||
coins are to be spent. That brings us to pay to contract (P2C).
|
||||
|
||||
[[p2c_for_colored_coins]]
|
||||
==== Pay to Contract (P2C)
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
A particular focus in the third edition has been modernizing the 2017
|
||||
second edition text and the remaining 2014 first edition text. In
|
||||
addition, many concepts that are relevant to contempory Bitcoin
|
||||
development in 2023 have been added.
|
||||
development in 2023 have been added:
|
||||
|
||||
<<ch04_keys_addresses>>::
|
||||
We rearranged the address info so that we work through everything in
|
||||
|
||||
@ -61,7 +61,7 @@ All the code snippets use real values and calculations where possible, so that y
|
||||
|
||||
This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
|
||||
|
||||
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_, 3rd ed., by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-098-15009-9.”
|
||||
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_, 3rd ed., by [.keep-together]#Andreas M.# Antonopoulos and David A. Harding (O’Reilly). Copyright 2024 David Harding, ISBN 978-1-098-15009-9.”
|
||||
|
||||
Some editions of this book are offered under an open source license, such as https://oreil.ly/RzUHE[CC-BY-NC], in which case the terms of that license apply.
|
||||
|
||||
|
||||
@ -8,3 +8,9 @@ td.fakeheader {
|
||||
|
||||
/*--Table lines--*/
|
||||
table td.right, th.right { border-right: 0.25pt solid cmyk(0%,0%,0%,100%); }
|
||||
|
||||
|
||||
/* roman (reverse emphasis) on varlist terms*/
|
||||
.plain {
|
||||
font-style: normal;
|
||||
}
|
||||
|
||||
@ -13,4 +13,8 @@
|
||||
<!-- Drop @width attributes from images if present -->
|
||||
<xsl:template match="h:img/@width"/>
|
||||
|
||||
<!-- Drop @alt attribute content from images if present -->
|
||||
<xsl:template match="h:img/@alt">
|
||||
<xsl:attribute name="alt"/>
|
||||
</xsl:template>
|
||||
</xsl:stylesheet>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user