mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-13 19:38:56 +00:00
Update cross-references
This commit is contained in:
parent
56c701a6ad
commit
f3689a028a
@ -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[]
|
||||
|
@ -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",
|
||||
|
@ -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.
|
||||
|
@ -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.
|
||||
|
@ -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_.
|
||||
|
||||
|
@ -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
|
||||
|
4
chapters/authorization-authentication.adoc
Normal file
4
chapters/authorization-authentication.adoc
Normal file
@ -0,0 +1,4 @@
|
||||
[[c_authorization_authentication]]
|
||||
=== Authorization and Authentication with Scripts and Witnesses
|
||||
|
||||
FIXME
|
9
chapters/fees.adoc
Normal file
9
chapters/fees.adoc
Normal file
@ -0,0 +1,9 @@
|
||||
[[transaction-pinning]]
|
||||
=== Transaction Pinning
|
||||
|
||||
FIXME
|
||||
|
||||
[[rbf]]
|
||||
=== Replace by Fee (RBF)
|
||||
|
||||
FIXME
|
9
chapters/signatures.adoc
Normal file
9
chapters/signatures.adoc
Normal file
@ -0,0 +1,9 @@
|
||||
[[signatures]]
|
||||
=== Signatures
|
||||
|
||||
FIXME
|
||||
|
||||
[[sighashes]]
|
||||
=== Signature Hashes (Sighashes)
|
||||
|
||||
FIXME
|
Loading…
Reference in New Issue
Block a user