From a0a50cb547b21afaf162de2b1c792a10da72cbea Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Thu, 30 Mar 2023 14:00:19 -1000 Subject: [PATCH] CH06: edits for feedback from arufino (thanks!) --- ch03.asciidoc | 11 ++++++++++- chapters/transactions.adoc | 32 +++++++++++++++++++++----------- 2 files changed, 31 insertions(+), 12 deletions(-) diff --git a/ch03.asciidoc b/ch03.asciidoc index 9e86eb5f..85daf0f6 100644 --- a/ch03.asciidoc +++ b/ch03.asciidoc @@ -784,7 +784,16 @@ the txid as a parameter: .Alice's serialized transaction [listing] ---- -include::snippets/getrawtransaction-alice.txt[] +$ bitcoin-cli getrawtransaction 466200308696215bbc949d5141a49a41\ +38ecdfdfaa2a8029c1f9bcecd1f96177 + +01000000000101eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da13569 +8679268041c54a0100000000ffffffff02204e0000000000002251203b41daba +4c9ace578369740f15e5ec880c28279ee7f51b07dca69c7061e07068f8240100 +000000001600147752c165ea7be772b2c0acb7f4d6047ae6f4768e0141cf5efe +2d8ef13ed0af21d4f4cb82422d6252d70324f6f4576b727b7d918e521c00b51b +e739df2f899c49dc267c0ad280aca6dab0d2fa2b42a45182fc83e81713010000 +0000 ---- [TIP] diff --git a/chapters/transactions.adoc b/chapters/transactions.adoc index 3c602826..3f274ee4 100644 --- a/chapters/transactions.adoc +++ b/chapters/transactions.adoc @@ -36,7 +36,16 @@ Let's retrieve the transaction containing that payment again. .Alice's serialized transaction [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. @@ -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 (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 transaction serialization format, now called _legacy serialization_. For details, see <>. @@ -159,7 +168,7 @@ future. [[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]] @@ -275,7 +284,7 @@ pieces of information from it: One of Bitcoin's consensus rules forbids any output from being spent more than once within a valid blockchain. This is the rule against _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 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 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 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 -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 transaction. It's a compactSize integer and must be greater than zero. @@ -582,8 +591,8 @@ A zero-value output is always an uneconomical output; it wouldn't contribute any value to a transaction spending it even if the transaction's fee rate was zero. However, many other outputs with low values can be uneconomical as well, even unintentionally. For example, -at the feerates prevelant on the network today, an output might add more -value to a transaction than it costs to spend--but, tomorrow, feerates +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 might rise and make the output uneconomical. The need for full nodes to keep track of all unspent transaction outputs @@ -713,7 +722,7 @@ protected by the following script: Obviously, allowing your bitcoins to be spent by anyone who can solve a simple equation wouldn't be secure. As we'll see in <>, 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 keep secret. They're able to reference that secret data using a public 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 second-party transaction malleability. But, with no ability to put 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, 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 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"] |=== | | **Authorization** | **Authentication** @@ -1062,7 +1072,7 @@ to spend their block reward. //by extension the reason for no expiring timelocks 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. // Useful content deleted