mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-22 22:58:09 +00:00
ce check
This commit is contained in:
parent
cea75ff946
commit
a39fb72df2
@ -65,7 +65,7 @@ BIPs that are implemented by Bitcoin Core:
|
||||
- BIP325: Signet test network is supported as of v0.21.0 (PR 18267).
|
||||
- BIP339: Relay of transactions by wtxid is supported as of v0.21.0 (PR 18044).
|
||||
- BIP340 341 342: Validation rules for Taproot (including Schnorr signatures and Tapscript leaves) are implemented as of v0.21.0 (PR 19953), with mainnet activation as of v0.21.1 (PR 21377, PR 21686).
|
||||
- BIP350: Addresses for native v1+ segregated Witness outputs use Bech32m instead of Bech32 as of v22.0 (PR 20861).
|
||||
- BIP350: Addresses for native v1+ segregated Witness outputs use bech32m instead of bech32 as of v22.0 (PR 20861).
|
||||
- BIP371: Taproot fields for PSBT as of v24.0 (PR 22558).
|
||||
- BIP380 381 382 383 384 385: Output Script Descriptors, and most of Script Expressions are implemented as of v0.17.0 (PR 13697).
|
||||
- BIP386: tr() Output Script Descriptors are implemented as of v22.0 (PR 22051).
|
||||
|
@ -510,7 +510,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 ork (PoW).
|
||||
block--is called 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
|
||||
|
@ -263,7 +263,7 @@ Here are some useful options that override the default behavior of the
|
||||
<dd><p>If you are building a wallet, allow the use of an incompatible version of the Berkeley DB library.</p></dd>
|
||||
|
||||
<dt><code>--with-gui=no</code></dt>
|
||||
<dd><p>Don't build the graphical user interface, which requires the Qt library. This builds server and command-line Bitcoin only.</p></dd>
|
||||
<dd><p>Don't build the graphical user interface, which requires the Qt library. This builds server and command-line Bitcoin Core only.</p></dd>
|
||||
</dl>
|
||||
++++
|
||||
|
||||
@ -297,7 +297,7 @@ will compile the source code, a process that can take up to an hour to
|
||||
complete, depending on the speed of your CPU and available memory.
|
||||
If an error
|
||||
occurs, or the compilation process is interrupted, it can be resumed any
|
||||
time by typing +make+ again. Type +make+ to start compiling the
|
||||
time by typing +make+ again. Type *+make+* to start compiling the
|
||||
executable application:
|
||||
|
||||
----
|
||||
@ -707,10 +707,10 @@ and their expected output.
|
||||
Bitcoin
|
||||
Core provides status reports on different modules through the JSON-RPC
|
||||
interface. The most important commands include +getblockchaininfo+,
|
||||
+getmempoolinfo+, +getnetworkinfo+, and +getwalletinfo+.
|
||||
+getmempoo⁠l​info+, +getnetworkinfo+, and +getwalletinfo+.
|
||||
|
||||
Bitcoin's +getblockchaininfo+ RPC command was introduced earlier. The
|
||||
+getnetworkinfo+ command displays basic information about the status of
|
||||
+getnetwor⁠k​info+ command displays basic information about the status of
|
||||
the Bitcoin network node. Use +bitcoin-cli+ to run it:
|
||||
|
||||
----
|
||||
@ -1012,7 +1012,7 @@ $ curl --user __cookie__:17c9b71cef21b893e1a019f4bc071950c7942f49796ed061b274031
|
||||
|
||||
Alternatively, you can
|
||||
create a static password with the helper script provided in
|
||||
_./share/rpcauth/rpcauth.py_ in Bitcoin Core's source directory.
|
||||
[.keep-together]#_./share/rpcauth/rpcauth.py_# in Bitcoin Core's source directory.
|
||||
|
||||
If you're implementing a JSON-RPC call in your own program, you can use
|
||||
a generic HTTP library to construct the call, similar to what is shown
|
||||
|
@ -832,7 +832,7 @@ 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
|
||||
for which she needs to pay transaction fees every time she wants to spend. However, the solution of using hash functions to create
|
||||
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.
|
||||
|
||||
The BIP16 upgrade to the Bitcoin protocol in 2012 allows an
|
||||
@ -859,7 +859,7 @@ OP_HASH160 <commitment> OP_EQUAL
|
||||
|
||||
[WARNING]
|
||||
====
|
||||
When using Spay to script hash (P2SH), you must use the specific P2SH template
|
||||
When using pay to script hash (P2SH), you must use the specific P2SH template
|
||||
with no extra data or conditions in the output script. If the
|
||||
output script is not exactly +OP_HASH160 <20 bytes> OP_EQUAL+, the
|
||||
redeem script will not be used and any bitcoins may either be unspendable
|
||||
@ -1232,7 +1232,6 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
|
||||
|
||||
[[scripts_for_diff_segwit_outputs]]
|
||||
.Scripts for different types of segwit outputs
|
||||
[cols="1,1"]
|
||||
[options="header"]
|
||||
|===
|
||||
|
||||
@ -1398,7 +1397,7 @@ wallets support the ability to export or import an individual key. The
|
||||
information in this section is mainly of interest to anyone needing
|
||||
compatibility with early Bitcoin wallets.
|
||||
|
||||
For more information, see <<hd_wallets>>.
|
||||
See <<hd_wallets>> for more information.
|
||||
|
||||
****
|
||||
|
||||
@ -1639,17 +1638,6 @@ keys, possibly with a hardware signing device to store keys and sign transaction
|
||||
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.
|
||||
<<table_4-14>> 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
|
||||
[options="header"]
|
||||
|=======================
|
||||
|Public address|Private key (WIF)
|
||||
|1424C2F4bC9JidNjjTUZCbUxv6Sa1Mt62x|5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
|
||||
|=======================
|
||||
|
||||
Paper wallets come in many designs and sizes, with many different
|
||||
features. <<paper_wallet_simple>> shows a sample paper wallet.
|
||||
|
@ -431,7 +431,6 @@ an example, see <<alice_tx_labels>>.
|
||||
|
||||
[[alice_tx_labels]]
|
||||
.Alice's transaction history with each transaction labeled
|
||||
[cols="1,1,>1"]
|
||||
[options="header"]
|
||||
|===
|
||||
| Date | Label | BTC
|
||||
@ -514,7 +513,6 @@ paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implic
|
||||
|
||||
[[bip_implicit_paths]]
|
||||
.Implicit script paths defined by various BIPs
|
||||
[cols="1,1,1"]
|
||||
[options="header"]
|
||||
|===
|
||||
| Standard | Script | BIP32 path
|
||||
@ -1034,16 +1032,16 @@ coding for extended keys uses a special version number that results in
|
||||
the prefix "xprv" and "xpub" when encoded in base58 characters to make
|
||||
them easily recognizable. Because the extended key contains many more
|
||||
bytes than regular addresses,
|
||||
it is also much longer than other Base58Check-encoded strings we have
|
||||
it is also much longer than other base58check-encoded strings we have
|
||||
seen previously.
|
||||
|
||||
Here's an example of an extended _private_ key, encoded in Base58Check:
|
||||
Here's an example of an extended _private_ key, encoded in base58check:
|
||||
|
||||
----
|
||||
xprv9tyUQV64JT5qs3RSTJkXCWKMyUgoQp7F3hA1xzG6ZGu6u6Q9VMNjGr67Lctvy5P8oyaYAL9CAWrUE9i6GoNMKUga5biW6Hx4tws2six3b9c
|
||||
----
|
||||
|
||||
Here's the corresponding extended _public_ key, encoded in Base58Check:
|
||||
Here's the corresponding extended _public_ key, encoded in base58check:
|
||||
|
||||
----
|
||||
xpub67xpozcx8pe95XVuZLHXZeG6XWXHpGq6Qv5cmNfi7cS5mtjJ2tgypeQbBs2UAR6KECeeMVKZBPLrtJunSDMstweyLXhRgPxdp14sk9tJPW9
|
||||
|
@ -152,7 +152,7 @@ of +TRUE+ or +FALSE+. For example, +OP_EQUAL+ pops two items from the stack
|
||||
and pushes +TRUE+ (+TRUE+ is represented by the number 1) if they are equal
|
||||
or +FALSE+ (represented by zero) if they are not equal. Bitcoin
|
||||
transaction scripts usually contain a conditional operator, so that they
|
||||
can produce the TRUE result that signifies a valid transaction.
|
||||
can produce the +TRUE+ result that signifies a valid transaction.
|
||||
|
||||
===== A simple script
|
||||
|
||||
@ -170,7 +170,7 @@ page].
|
||||
Although most legacy output scripts refer to a public key hash (essentially, a
|
||||
legacy Bitcoin address), thereby requiring proof of ownership to spend the
|
||||
funds, the script does not have to be that complex. Any combination of
|
||||
output and input scripts that results in a TRUE value is valid. The
|
||||
output and input scripts that results in a +TRUE+ value is valid. The
|
||||
simple arithmetic we used as an example of the scripting language is
|
||||
also a valid script.
|
||||
|
||||
@ -268,10 +268,10 @@ signature created by the corresponding private key (see
|
||||
OP_DUP OP_HASH160 <Key Hash> OP_EQUALVERIFY OP_CHECKSIG
|
||||
----
|
||||
|
||||
The +Key Hash+ is the data that would be encoded into a legacy Base58Check
|
||||
The +Key Hash+ is the data that would be encoded into a legacy base58check
|
||||
address. Most applications would show the _public key hash_ in a script
|
||||
using hexadecimal encoding and not the familiar Bitcoin
|
||||
address Base58Check format that begins with a "1."
|
||||
address base58check format that begins with a "1."
|
||||
|
||||
The preceding output script can be satisfied with an input script
|
||||
of the form:
|
||||
@ -287,7 +287,7 @@ script:
|
||||
<Sig> <Pubkey> OP_DUP OP_HASH160 <Hash> OP_EQUALVERIFY OP_CHECKSIG
|
||||
----
|
||||
|
||||
The result will be TRUE if the input script
|
||||
The result will be +TRUE+ if the input script
|
||||
has a valid signature from Bob's private key that corresponds to
|
||||
the public key hash set as an encumbrance.
|
||||
|
||||
@ -358,7 +358,7 @@ The two scripts together would form the combined validation script:
|
||||
<Sig B> <Sig C> 2 <Pubkey A> <Pubkey B> <Pubkey C> 3 OP_CHECKMULTISIG
|
||||
----
|
||||
|
||||
When executed, this combined script will evaluate to TRUE if
|
||||
When executed, this combined script will evaluate to +TRUE+ if
|
||||
the input script has
|
||||
two valid signatures from private keys that correspond to two of
|
||||
the three public keys set as an encumbrance.
|
||||
@ -605,13 +605,13 @@ If the redeem script hash matches, the redeem script is executed:
|
||||
|
||||
Another
|
||||
important part of the P2SH feature is the ability to encode a script
|
||||
hash as an address, as defined in BIP13. P2SH addresses are Base58Check
|
||||
hash as an address, as defined in BIP13. P2SH addresses are base58check
|
||||
encodings of the 20-byte hash of a script, just like Bitcoin addresses
|
||||
are Base58Check encodings of the 20-byte hash of a public key. P2SH
|
||||
are base58check encodings of the 20-byte hash of a public key. P2SH
|
||||
addresses use the version prefix "5," which results in
|
||||
Base58Check-encoded addresses that start with a "3."
|
||||
base58check-encoded addresses that start with a "3."
|
||||
|
||||
For example, Mohammed's complex script, hashed and Base58Check-encoded
|
||||
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
|
||||
@ -782,7 +782,7 @@ The +OP_CLTV+ opcode takes one parameter as input, expressed as a number in
|
||||
the same format as lock time (either a block height or Unix epoch
|
||||
time). As indicated by the +VERIFY+ suffix, +OP_CLTV+ is the type of opcode
|
||||
that halts execution of the script if the outcome is +FALSE+. If it
|
||||
results in TRUE, execution continues.
|
||||
results in +TRUE+, execution continues.
|
||||
|
||||
In order to use +OP_CLTV+, you insert it into the redeem script of the
|
||||
output in the transaction that creates the output. For
|
||||
@ -902,7 +902,7 @@ implemented according to the specifications in
|
||||
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP68,
|
||||
Relative lock-time using consensus-enforced sequence numbers] and
|
||||
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
|
||||
OP_CHECKSEQUENCEVERIFY].
|
||||
+OP_CHECKSEQUENCEVERIFY+].
|
||||
|
||||
BIP68 and BIP112 were activated in May 2016 as a soft fork upgrade to
|
||||
the consensus rules.
|
||||
@ -1035,7 +1035,7 @@ valid preimage and a signature:
|
||||
<Bob's Sig> <hash pre-image>
|
||||
----
|
||||
|
||||
Without presenting the pre-image, Bob can't get to the part of the
|
||||
Without presenting the preimage, Bob can't get to the part of the
|
||||
script that checks for his signature.
|
||||
|
||||
|
||||
|
@ -141,7 +141,7 @@ and is applied by bitwise OR, resulting in the combined flags as shown
|
||||
in <<sighash_types_with_modifiers>>.
|
||||
|
||||
[[sighash_types_with_modifiers]]
|
||||
.++SIGHASH++ types with modifiers and their meanings
|
||||
.[.plain]#++SIGHASH++# types with modifiers and their meanings
|
||||
[options="header"]
|
||||
|=======================
|
||||
|++SIGHASH++ flag| Value | Description
|
||||
|
@ -525,7 +525,7 @@ Protocol developers have been working on mitigating problems with
|
||||
transaction pinning for several years. One partial solution is
|
||||
described in <<cpfp_carve_out>>. Several other solutions have been
|
||||
proposed, and at least one solution is being actively developed as of
|
||||
this writing—https://bitcoinops.org/en/topics/ephemeral-anchors/[ephemeral anchors].
|
||||
this writing&emdash;https://bitcoinops.org/en/topics/ephemeral-anchors[ephemeral anchors].
|
||||
|
||||
[[cpfp_carve_out]]
|
||||
=== CPFP Carve Out and Anchor Outputs
|
||||
|
@ -270,7 +270,7 @@ information, including:
|
||||
+nTime+:: The current time
|
||||
+addrYou+:: The IP address of the remote node as seen from this node
|
||||
+addrMe+:: The IP address of the local node, as discovered by the local node
|
||||
+subver+:: A subversion showing the type of software running on this node (e.g., pass:[<span class="keep-together"><code>/Satoshi:0.9.2.1/</code></span>])
|
||||
+subver+:: A subversion showing the type of software running on this [.keep-together]#node (e.g.,# pass:[<span class="keep-together"><code>/Satoshi:0.9.2.1/</code></span>])
|
||||
+BestHeight+:: The block height of this node's blockchain
|
||||
+fRelay+:: A field added by BIP37 for requesting not to receive unconfirmed transactions
|
||||
|
||||
|
@ -119,8 +119,8 @@ block header twice through the SHA256 algorithm. The resulting 32-byte
|
||||
hash is called the _block hash_ but is more accurately the _block header
|
||||
hash_, pass:[<span class="keep-together">because only the block header is
|
||||
used to compute it. For example,</span>]
|
||||
+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ is
|
||||
the block hash of the first block on Bitcoin's blockchain. The block hash
|
||||
+000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f+ [.keep-together]#is
|
||||
the block# hash of the first block on Bitcoin's blockchain. The block hash
|
||||
identifies a block uniquely and unambiguously and can be independently
|
||||
derived by any node by simply hashing the block header.
|
||||
|
||||
@ -765,17 +765,17 @@ ecommerce site; or even developing novel smart contracts and complex
|
||||
scripts.
|
||||
|
||||
You can use the test blockchains to establish a development pipeline.
|
||||
Test your code locally on a +regtest+ as you develop it. Once you are
|
||||
ready to try it on a public network, switch to +signet+ or +testnet+ to expose your
|
||||
Test your code locally on a regtest as you develop it. Once you are
|
||||
ready to try it on a public network, switch to signet or testnet to expose your
|
||||
code to a more dynamic environment with more diversity of code and
|
||||
applications. Finally, once you are confident your code works as
|
||||
expected, switch to +mainnet+ to deploy it in production. As you make
|
||||
expected, switch to mainnet to deploy it in production. As you make
|
||||
changes, improvements, bug fixes, etc., start the pipeline again,
|
||||
deploying each change first on +regtest+, then on +signet+ or +testnet+, and finally
|
||||
deploying each change first on regtest, then on signet or testnet, and finally
|
||||
into production.
|
||||
|
||||
Now that we know what data the blockchain contains and how cryptographic
|
||||
commitments securely tie the various parts together, we will look at the
|
||||
specical commitment that both provides computational security and
|
||||
special commitment that both provides computational security and
|
||||
ensures no block can be changed without invalidating all other blocks
|
||||
built on top of it: Bitcoin's mining function.
|
||||
|
@ -1,6 +1,6 @@
|
||||
++++
|
||||
<ul class="twocolumn">
|
||||
<li>Abdussamad Abdurrazzaq (AbdussamadA)</li>
|
||||
<li>Abdussamad Abdurrazzaq [.keep-together]#(AbdussamadA)#</li>
|
||||
<li>Adán SDPC (aesedepece)</li>
|
||||
<li>Akira Chiku (achiku)</li>
|
||||
<li>Alex Waters (alexwaters)</li>
|
||||
@ -117,9 +117,9 @@
|
||||
<li>Maximilian Reichel (phramz)</li>
|
||||
<li>MG-ng (MG-ng)</li>
|
||||
<li>Michalis Kargakis (kargakis)</li>
|
||||
<li>Michael C. Ippolito (michaelcippolito)</li>
|
||||
<li>Michael C. Ippolito [.keep-together]#(michaelcippolito)#</li>
|
||||
<li>Michael Galero (mikong)</li>
|
||||
<li>Michael Newman (michaelbnewman)</li>
|
||||
<li>Michael Newman [.keep-together]#(michaelbnewman)#</li>
|
||||
<li>Mihail Russu (MihailRussu)</li>
|
||||
<li>mikew (mikew)</li>
|
||||
<li>milansismanovic</li>
|
||||
@ -137,7 +137,7 @@
|
||||
<li>Omar Boukli-Hacene (oboukli)</li>
|
||||
<li>Óscar Nájera (Titan-C)</li>
|
||||
<li>Parzival (Parz-val)</li>
|
||||
<li>Paul Desmond Parker (sunwukonga)</li>
|
||||
<li>Paul Desmond Parker [.keep-together]#(sunwukonga)#</li>
|
||||
<li>Philipp Gille (philippgille)</li>
|
||||
<li>ratijas</li>
|
||||
<li>rating89us</li>
|
||||
|
@ -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 a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.
|
||||
|
||||
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2023, ISBN 978-1-491-95438-6.”
|
||||
We appreciate, but do not require, attribution. An attribution usually includes [.keep-together]#the title,# author, publisher, and ISBN. For example: “_Mastering Bitcoin_ by Andreas M. Antonopoulos and David A. Harding (O’Reilly). Copyright 2024, ISBN 978-1-491-95438-6.”
|
||||
|
||||
Some editions of this book are offered under an open source license, such as https://creativecommons.org/licenses/by-nc/4.0/[CC-BY-NC], in which case the terms of that license apply.
|
||||
|
||||
|
@ -65,11 +65,11 @@ pre.c_less_space2 {
|
||||
line-height: 105%;
|
||||
}
|
||||
|
||||
/*----Uncomment to temporarily turn on code-eyballer highlighting (make sure to recomment after you build)---*/
|
||||
/*----Uncomment to temporarily turn on code-eyballer highlighting (make sure to recomment after you build)
|
||||
|
||||
pre {
|
||||
background-color: yellow;
|
||||
}
|
||||
}---*/
|
||||
|
||||
|
||||
/*----Uncomment to turn on automatic code wrapping
|
||||
|
Loading…
Reference in New Issue
Block a user