1
0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-13 19:38:56 +00:00

Update cross-references

This commit is contained in:
David A. Harding 2023-03-05 10:37:16 -10:00
parent 56c701a6ad
commit f3689a028a
9 changed files with 50 additions and 11 deletions

View File

@ -14,6 +14,14 @@ include::ch04.asciidoc[]
include::ch05.asciidoc[]
include::chapters/transactions.adoc[]
include::chapters/authorization-authentication.adoc[]
include::chapters/signatures.adoc[]
include::chapters/fees.adoc[]
include::ch06.asciidoc[]
include::ch07.asciidoc[]

View File

@ -526,7 +526,7 @@ options")))((("txindex option")))((("full indexing option")))By default,
Bitcoin Core builds a database containing _only_ the transactions
related to the user's wallet. If you want to be able to access _any_
transaction with commands like +getrawtransaction+ (see
<<exploring_and_decoding_transanctions>>), you need to configure Bitcoin
<<exploring_and_decoding_transactions>>), you need to configure Bitcoin
Core to build a complete transaction index, which can be achieved with
the +txindex+ option. Set +txindex=1+ in the Bitcoin Core configuration
file. If you don't set this option at first and later set it to full
@ -771,7 +771,7 @@ blocks from other Bitcoin nodes. You can check its progress using
+getblockchaininfo+ to see the number of known blocks.
====
[[exploring_and_decoding_transanctions]]
[[exploring_and_decoding_transactions]]
==== Exploring and Decoding Transactions
In <<spending_bitcoin>>, ((("use cases", "buying coffee",

View File

@ -478,13 +478,13 @@ full nodes will consider the transaction to be valid.
In short, the script above uses the same public key and signature
described in the original paper but adds in the complexity of two script
fields and an opcode. That seems like extra work here, but we'll begin
to see the benefits when we look at <<p2pkh>>.
to see the benefits when we look at <<addresses_for_p2pkh>>.
This type of output is known today as _Pay-to-Public-Key_, or _P2PK_ for
short. It was never widely used for payments, and no widely-used
program has supported IP address payments for almost a decade.
[[p2pkh]]
[[addresses_for_p2pkh]]
=== Legacy Addresses for P2PKH
Entering the IP address of the person you want to pay has a number of
@ -861,7 +861,7 @@ represent them is implemented slightly differently in newer Bitcoin
wallets, to indicate that these private keys have been used to produce
compressed public keys.
[[p2sh]]
[[addresses_for_p2sh]]
=== Legacy Pay-to-Script-Hash (P2SH)
As we've seen in preceding sections, someone receiving Bitcoins (like
@ -869,7 +869,7 @@ Bob) can require payments to him contain certain constraints in their
scriptPubKeys. Bob will need to fulfill those constraints using a
scriptSig when he spends those bitcoins. In <<p2pk>>, the constraint
was simply that the scriptSig needed to provide an appropriate
signature. In <<p2pkh>>, an appropriate public key also needed to be
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
@ -1295,7 +1295,7 @@ scripts are listed in <<scripts_for_diff_segwit_outputs>>.
|===
For the P2WPKH output, the witness program contains a commitment constructed in exactly the same
way as the commitment for a P2PKH output seen in <<p2pkh>>. A public key is passed into a SHA256 hash
way as the commitment for a P2PKH output seen in <<addresses_for_p2pkh>>. A public key is passed into a SHA256 hash
function. The resultant 32 byte digest is then passed into a RIPEMD-160
hash function. The digest of that function (the commitment) is placed
in the witness program.

View File

@ -924,7 +924,7 @@ code_ (c).
The master private key (m) then generates a corresponding master public
key (M) using the normal elliptic curve multiplication process +m * G+
that we saw in <<pubkey>>.
that we saw in <<public_key_derivation>>.
The chain code (c) is used to introduce entropy in the function that
creates child keys from parent keys, as we will see in the next section.

View File

@ -734,7 +734,7 @@ different subsets of the data in the transaction. By including the
[NOTE]
====
All +SIGHASH+ types sign the transaction +nLocktime+ field (see
<<transaction_locktime_nlocktime>>). In addition, the +SIGHASH+ type
<<nlocktime>>). In addition, the +SIGHASH+ type
itself is appended to the transaction before it is signed, so that it
can't be modified once signed.
====
@ -808,7 +808,7 @@ the transaction hash.
The temporary key pair is based on a random number _k_, which is used as
the temporary private key. From _k_, we generate the corresponding
temporary public key _P_ (calculated as _P = k*G_, in the same way
bitcoin public keys are derived; see <<pubkey>>). The _R_ value of the
bitcoin public keys are derived; see <<public_key_derivation>>). The _R_ value of the
digital signature is then the x coordinate of the ephemeral public key
_P_.

View File

@ -1,6 +1,15 @@
[[mining]]
== Mining and Consensus
[[mtp]]
=== Median Time Past (MTP)
FIXME
[[duplicate_transactions]]
=== Preventing Duplicate Transactions
FIXME:BIP30 and 34
=== Introduction
@ -296,7 +305,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 <<generation_tx_example>>, 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 <<tx_in_structure>>. Let's compare a regular transaction input with a coinbase transaction input. <<table_8-1>> shows the structure of a regular transaction, while <<table_8-2>> shows the structure of the coinbase transaction's input.
As you can see in <<generation_tx_example>>, 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 <<inputs>>. Let's compare a regular transaction input with a coinbase transaction input. <<table_8-1>> shows the structure of a regular transaction, while <<table_8-2>> shows the structure of the coinbase transaction's input.
[[table_8-1]]
.The structure of a "normal" transaction input

View File

@ -0,0 +1,4 @@
[[c_authorization_authentication]]
=== Authorization and Authentication with Scripts and Witnesses
FIXME

9
chapters/fees.adoc Normal file
View File

@ -0,0 +1,9 @@
[[transaction-pinning]]
=== Transaction Pinning
FIXME
[[rbf]]
=== Replace by Fee (RBF)
FIXME

9
chapters/signatures.adoc Normal file
View File

@ -0,0 +1,9 @@
[[signatures]]
=== Signatures
FIXME
[[sighashes]]
=== Signature Hashes (Sighashes)
FIXME