mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2025-01-11 16:20:57 +00:00
CH06: edits for feedback from arufino (thanks!)
This commit is contained in:
parent
1a27ee296e
commit
a0a50cb547
@ -784,7 +784,16 @@ the txid as a parameter:
|
|||||||
.Alice's serialized transaction
|
.Alice's serialized transaction
|
||||||
[listing]
|
[listing]
|
||||||
----
|
----
|
||||||
include::snippets/getrawtransaction-alice.txt[]
|
$ bitcoin-cli getrawtransaction 466200308696215bbc949d5141a49a41\
|
||||||
|
38ecdfdfaa2a8029c1f9bcecd1f96177
|
||||||
|
|
||||||
|
01000000000101eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da13569
|
||||||
|
8679268041c54a0100000000ffffffff02204e0000000000002251203b41daba
|
||||||
|
4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f8240100
|
||||||
|
000000001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe
|
||||||
|
2d8ef13ed0af21d4f4cb82422d6252d70324f6f4576b727b7d918e521c00b51b
|
||||||
|
e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
|
||||||
|
0000
|
||||||
----
|
----
|
||||||
|
|
||||||
[TIP]
|
[TIP]
|
||||||
|
@ -36,7 +36,16 @@ Let's retrieve the transaction containing that payment again.
|
|||||||
.Alice's serialized transaction
|
.Alice's serialized transaction
|
||||||
[listing]
|
[listing]
|
||||||
----
|
----
|
||||||
include::../snippets/getrawtransaction-alice.txt[]
|
$ bitcoin-cli getrawtransaction 466200308696215bbc949d5141a49a41\
|
||||||
|
38ecdfdfaa2a8029c1f9bcecd1f96177
|
||||||
|
|
||||||
|
01000000000101eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da13569
|
||||||
|
8679268041c54a0100000000ffffffff02204e0000000000002251203b41daba
|
||||||
|
4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f8240100
|
||||||
|
000000001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe
|
||||||
|
2d8ef13ed0af21d4f4cb82422d6252d70324f6f4576b727b7d918e521c00b51b
|
||||||
|
e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000
|
||||||
|
0000
|
||||||
----
|
----
|
||||||
|
|
||||||
There's nothing special about Bitcoin Core's serialization format.
|
There's nothing special about Bitcoin Core's serialization format.
|
||||||
@ -144,7 +153,7 @@ If the transaction includes a witness field (which we'll describe in
|
|||||||
non-zero. In the current P2P protocol, the flag should always be one
|
non-zero. In the current P2P protocol, the flag should always be one
|
||||||
(0x01); alternative flags are reserved for later protocol upgrades.
|
(0x01); alternative flags are reserved for later protocol upgrades.
|
||||||
|
|
||||||
If the transaction doesn't need a witness, the marker and flag most not
|
If the transaction doesn't need a witness, the marker and flag must not
|
||||||
be present. This is compatible with the original version of Bitcoin's
|
be present. This is compatible with the original version of Bitcoin's
|
||||||
transaction serialization format, now called _legacy serialization_.
|
transaction serialization format, now called _legacy serialization_.
|
||||||
For details, see <<legacy_serialization>>.
|
For details, see <<legacy_serialization>>.
|
||||||
@ -159,7 +168,7 @@ future.
|
|||||||
[[inputs]]
|
[[inputs]]
|
||||||
=== Inputs
|
=== Inputs
|
||||||
|
|
||||||
The inputs field contains several other fields, so let's start by with a
|
The inputs field contains several other fields, so let's start by showing a
|
||||||
map of those bytes in <<alice_tx_input_map>>.
|
map of those bytes in <<alice_tx_input_map>>.
|
||||||
|
|
||||||
[[alice_tx_input_map]]
|
[[alice_tx_input_map]]
|
||||||
@ -275,7 +284,7 @@ pieces of information from it:
|
|||||||
One of Bitcoin's consensus rules forbids any output from being spent
|
One of Bitcoin's consensus rules forbids any output from being spent
|
||||||
more than once within a valid blockchain. This is the rule against
|
more than once within a valid blockchain. This is the rule against
|
||||||
_double spending_--Alice can't use the same previous output to pay
|
_double spending_--Alice can't use the same previous output to pay
|
||||||
both Bob and Carol. Two transactions which each try to the spend the
|
both Bob and Carol. Two transactions which each try to spend the
|
||||||
same previous output are called _conflicting transactions_ because
|
same previous output are called _conflicting transactions_ because
|
||||||
only one of them can be included in a valid blockchain.
|
only one of them can be included in a valid blockchain.
|
||||||
|
|
||||||
@ -388,7 +397,7 @@ output:
|
|||||||
|
|
||||||
- Alice wins the first round of the card game, so the second version of
|
- Alice wins the first round of the card game, so the second version of
|
||||||
the transaction, with nSequence 1, increases the amount of money paid
|
the transaction, with nSequence 1, increases the amount of money paid
|
||||||
to Alice and decreases Bob's share. The both sign the updated
|
to Alice and decreases Bob's share. They both sign the updated
|
||||||
transaction. Again, they don't need to broadcast this version of the
|
transaction. Again, they don't need to broadcast this version of the
|
||||||
transaction unless there's a problem.
|
transaction unless there's a problem.
|
||||||
|
|
||||||
@ -548,7 +557,7 @@ image::../images/output-byte-map.png["A byte map of the outputs field from Alice
|
|||||||
|
|
||||||
==== Outputs Count
|
==== Outputs Count
|
||||||
|
|
||||||
Identical to the start of the input section of transaction, the output
|
Identical to the start of the input section of a transaction, the output
|
||||||
field begins with a count indicating the number of outputs in this
|
field begins with a count indicating the number of outputs in this
|
||||||
transaction. It's a compactSize integer and must be greater than zero.
|
transaction. It's a compactSize integer and must be greater than zero.
|
||||||
|
|
||||||
@ -582,7 +591,7 @@ A zero-value output is always an uneconomical output; it wouldn't
|
|||||||
contribute any value to a transaction spending it even if the
|
contribute any value to a transaction spending it even if the
|
||||||
transaction's fee rate was zero. However, many other outputs with low
|
transaction's fee rate was zero. However, many other outputs with low
|
||||||
values can be uneconomical as well, even unintentionally. For example,
|
values can be uneconomical as well, even unintentionally. For example,
|
||||||
at the feerates prevelant on the network today, an output might add more
|
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
|
value to a transaction than it costs to spend--but, tomorrow, fee rates
|
||||||
might rise and make the output uneconomical.
|
might rise and make the output uneconomical.
|
||||||
|
|
||||||
@ -713,7 +722,7 @@ protected by the following script:
|
|||||||
|
|
||||||
Obviously, allowing your bitcoins to be spent by anyone who can solve a
|
Obviously, allowing your bitcoins to be spent by anyone who can solve a
|
||||||
simple equation wouldn't be secure. As we'll see in <<c_signatures>>, an
|
simple equation wouldn't be secure. As we'll see in <<c_signatures>>, an
|
||||||
unforgable digital signature scheme uses an equation that can only be
|
unforgeable digital signature scheme uses an equation that can only be
|
||||||
solved by someone in possession of certain data which they're able to
|
solved by someone in possession of certain data which they're able to
|
||||||
keep secret. They're able to reference that secret data using a public
|
keep secret. They're able to reference that secret data using a public
|
||||||
identifier. That public identifier is called a _public key_ and a
|
identifier. That public identifier is called a _public key_ and a
|
||||||
@ -922,7 +931,7 @@ An empty scriptSig keeps witnesses from affecting the txid, eliminating
|
|||||||
circular dependencies, third-party transaction malleability, and
|
circular dependencies, third-party transaction malleability, and
|
||||||
second-party transaction malleability. But, with no ability to put
|
second-party transaction malleability. But, with no ability to put
|
||||||
data in a scriptSig, users of segwit scriptPubKey templates need a
|
data in a scriptSig, users of segwit scriptPubKey templates need a
|
||||||
new field. That field is called is called the _witness_.
|
new field. That field is called the _witness_.
|
||||||
|
|
||||||
The introduction of witnesses and witness programs complicates Bitcoin,
|
The introduction of witnesses and witness programs complicates Bitcoin,
|
||||||
but it follows an existing trend of increasing abstraction. Recall from
|
but it follows an existing trend of increasing abstraction. Recall from
|
||||||
@ -937,6 +946,7 @@ bitcoins to be received to scriptPubKeys and spent with scriptSigs.
|
|||||||
Later experience with contract protocols inspired allowing bitcoins to
|
Later experience with contract protocols inspired allowing bitcoins to
|
||||||
be received to witness programs and spent with witnesses.
|
be received to witness programs and spent with witnesses.
|
||||||
|
|
||||||
|
.Terms used for authorization and authentication data in different parts of Bitcoin
|
||||||
[cols="1,1,1"]
|
[cols="1,1,1"]
|
||||||
|===
|
|===
|
||||||
| | **Authorization** | **Authentication**
|
| | **Authorization** | **Authentication**
|
||||||
@ -1062,7 +1072,7 @@ to spend their block reward.
|
|||||||
//by extension the reason for no expiring timelocks
|
//by extension the reason for no expiring timelocks
|
||||||
|
|
||||||
Most Bitcoin software doesn't need to deal with coinbase transactions
|
Most Bitcoin software doesn't need to deal with coinbase transactions
|
||||||
but their special nature does mean they can occasional be the cause of
|
but their special nature does mean they can occasionally be the cause of
|
||||||
unusual problems in software that's not designed to expect them.
|
unusual problems in software that's not designed to expect them.
|
||||||
|
|
||||||
// Useful content deleted
|
// Useful content deleted
|
||||||
|
Loading…
Reference in New Issue
Block a user