arno/bitcoinbook
1
0
Fork 0
mirror of https://github.com/bitcoinbook/bitcoinbook synced 2024-11-26 09:58:22 +00:00
Code Issues Releases Wiki Activity

CH07: Minor edits

Browse Source 
A bunch of minor edits just from reading through the previous text.
This commit is contained in:
David A. Harding 2023-03-14 09:14:46 -10:00
parent 3d659cec16
commit eb1a75ad97
1 changed files with 93 additions and 95 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

188
chapters/authorization-authentication.adoc
View File

@ -65,7 +65,7 @@ validation mechanism from being used as a vulnerability.
==== Stateless Verification
((("stateless verification")))The bitcoin transaction script language is
((("stateless verification")))The Bitcoin transaction script language is
stateless, in that there is no state prior to execution of the script,
or state saved after execution of the script. All the
information needed to execute a script is contained within the script
@ -80,7 +80,7 @@ system.
[[tx_lock_unlock]]
==== Script Construction
Bitcoin's legacy transaction validation engine relies on two types of scripts
Bitcoin's legacy transaction validation engine relies on two parts of scripts
to validate transactions: a scriptPubKey and a scriptSig.
A scriptPubKey is a spending condition placed on an output:
@ -91,7 +91,7 @@ be authenticated.
A scriptSig is a script that satisfies the
conditions placed on an output by a scriptPubKey and allows the output
to be spent. ScriptSigs are part of every transaction input. Most
of the time they contain a digital signature produced by the user's
of the time in legacy transactions they contain a digital signature produced by the user's
wallet from his or her private key, but not all scriptSigs
must contain signatures.
@ -102,16 +102,16 @@ previous transaction output. The input also contains a scriptSig. The
validation software will copy the scriptSig, retrieve the UTXO
referenced by the input, and copy the scriptPubKey from that UTXO. The
scriptSig and scriptPubKey are then executed in sequence. The input is
valid if the scriptSig satisfies the scriptPubUey conditions
valid if the scriptSig satisfies the scriptPubKey conditions
(see <<script_exec>>). All the inputs are validated independently, as
part of the overall validation of the transaction.
Note that the UTXO is permanently recorded in the blockchain, and
therefore is invariable and is unaffected by failed attempts to spend it
by reference in a new transaction. Only a valid transaction that
correctly satisfies the conditions of the output results in the output
being considered as "spent" and removed from the set of unspent
transaction outputs (UTXO set).
Note that the steps above involve making copies of all data. The
original data in the previous output and current input is never changed.
In particular, the previous output is invariable and unaffected by
failed attempts to spend it. Only a valid transaction that correctly
satisfies the conditions of the scriptPubKey results in the output being
considered as "spent".
<<scriptSig_and_scriptPubKey>> is an example of the scriptPubKey and
scriptSig for the most common type of legacy Bitcoin transaction (a
@ -220,7 +220,7 @@ the next operator:
----
Try validating the preceding script yourself using pencil and paper.
When the script execution ends, you should be left with the value +TRUE+
When the script execution ends, you should be left with a +TRUE+ value
on the stack.
[[script_exec]]
@ -237,10 +237,10 @@ First, the scriptSig executed using the stack execution
engine. If the scriptSig is executed without errors and has
no operations left over, the stack is copied and the
scriptPubKey is executed. If the result of executing scriptPubKey
with the stack data copied from scriptSig is "TRUE,"
with the stack data copied from scriptSig is +TRUE+,
the scriptSig has succeeded in resolving the conditions imposed
by the scriptPubKey and, therefore, the input is a valid authorization
to spend the UTXO. If any result other than "TRUE" remains after
to spend the UTXO. If any result other than +TRUE+ remains after
execution of the combined script, the input is invalid because it has
failed to satisfy the spending conditions placed on the output.
@ -261,7 +261,7 @@ signature created by the corresponding private key (see
OP_DUP OP_HASH160 <Key Hash> OP_EQUALVERIFY OP_CHECKSIG
----
The +Key Hash+ 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."
@ -528,7 +528,7 @@ the use of complex scripts as easy as a payment to a Bitcoin address.
With P2SH payments, the complex script is replaced with a
commitment, the digest of a cryptographic hash. When a transaction attempting
to spend the UTXO is presented later, it must contain the script that
matches the commitment in addition to the data which satisifies the script. In simple terms,
matches the commitment in addition to the data which satisfies the script. In simple terms,
P2SH means "pay to a script matching this hash, a script that will be
presented later when this output is spent."
@ -671,10 +671,10 @@ Now, Mohammed can give this "address" to his customers and they can use
almost any bitcoin wallet to make a simple payment, as if it were a
Bitcoin address. The 3 prefix gives them a hint that this is a special
type of address, one corresponding to a script instead of a public key,
but otherwise it works in exactly the same way as a payment to a Bitcoin
but otherwise it works in exactly the same way as a payment to any other Bitcoin
address.
P2SH addresses hide all of the complexity, so that the person making a
P2SH addresses hide all of the complexity so that the person making a
payment does not see the script.
==== Benefits of P2SH
@ -751,14 +751,14 @@ transaction.
((("blockchain bloat")))((("bloat")))((("unspent transaction outputs
(UTXO)")))((("UTXO sets")))The use of bitcoin's blockchain to store data
unrelated to bitcoin payments is a controversial subject. Many
developers consider such use abusive and want to discourage it. Others
people consider such use abusive and want to discourage it. Others
view it as a demonstration of the powerful capabilities of blockchain
technology and want to encourage such experimentation. Those who object
to the inclusion of nonpayment data argue that it causes "blockchain
bloat," burdening those running full Bitcoin nodes with carrying the
cost of disk storage for data that the blockchain was not intended to
carry. Moreover, such transactions create UTXO that cannot be spent,
using the destination Bitcoin address as a freeform 20-byte field.
using the destination legacy Bitcoin address as a freeform 20-byte field.
Because the address is used for data, it doesn't correspond to a private
key and the resulting UTXO can _never_ be spent; it's a fake payment.
These transactions that can never be spent are therefore never removed
@ -768,7 +768,7 @@ increase, or "bloat."
A compromise was reached
that allows the a scriptPubKey starting with +OP_RETURN+ to
add nonpayment data to a transaction output. However, unlike
the use of "fake" UTXO, the +OP_RETURN+ operator creates an explicitly
the use of "fake" UTXOs, the +OP_RETURN+ operator creates an explicitly
_provably unspendable_ output, which does not need to be stored in the
UTXO set. +OP_RETURN+ outputs are recorded on the blockchain, so they
consume disk space and contribute to the increase in the blockchain's
@ -782,7 +782,7 @@ expensive database operations.
OP_RETURN <data>
----
((("Proof of Existence")))((("DOCPROOF prefix")))The data portion is
((("Proof of Existence")))((("DOCPROOF prefix")))The data portion
often represents a hash, such as the output
from the SHA256 algorithm (32 bytes). Some applications put a prefix in
front of the data to help identify the application. For example, the
@ -794,7 +794,7 @@ Keep in mind that there is no scriptSig that corresponds to
+OP_RETURN+ that could possibly be used to "spend" an +OP_RETURN+ output. The
whole point of an +OP_RETURN+ output is that you can't spend the money locked in that
output, and therefore it does not need to be held in the UTXO set as
potentially spendable--+OP_RETURN+ is _provably unspendable_. +OP_RETURN+ is
potentially spendable: +OP_RETURN+ is _provably unspendable_. +OP_RETURN+ is
usually an output with a zero amount, because any bitcoins
assigned to such an output is effectively lost forever. If an +OP_RETURN+ is
referenced as an input in a transaction, the script validation engine
@ -805,7 +805,7 @@ reference a +OP_RETURN+ output as an input in a transaction, that
transaction is invalid.
[[locktime_limitations]]
===== Transaction locktime limitations
==== Transaction locktime limitations
+nLockTime+ has the limitation that while it makes it possible to spend some outputs in the future, it does not make it impossible to spend them until that time. Let's explain that with the following example.
@ -834,8 +834,8 @@ _OP_CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
as is the case with +nLockTime+. This allows for much greater
flexibility in the way timelocks are applied.
In simple terms, by adding the +OP_CLTV+ opcode in the redeemScript of an
output it restricts the output, so that it can only be spent after the
In simple terms, by committing to the +OP_CLTV+ opcode in an
output, that output is restricted so that it can only be spent after the
specified time has elapsed.
[TIP]
@ -892,10 +892,10 @@ More precisely, +OP_CHECKLOCKTIMEVERIFY+ fails and halts execution, marking
the transaction invalid if (source: BIP65):
1. the stack is empty; or
1. the top item on the stack is less than 0; or
1. the lock-time type (height versus timestamp) of the top stack item and the +nLockTime+ field are not the same; or
1. the top stack item is greater than the transaction's +nLockTime+ field; or
1. the +nSequence+ field of the input is 0xffffffff.
2. the top item on the stack is less than 0; or
3. the lock-time type (height versus timestamp) of the top stack item and the +nLockTime+ field are not the same; or
4. the top stack item is greater than the transaction's +nLockTime+ field; or
5. the +nSequence+ field of the input is 0xffffffff.
[[timelock_conflicts]]
.Timelock conflicts
@ -948,8 +948,8 @@ next two timelock features we will examine are _relative timelocks_ in
that they specify, as a condition of spending an output, an elapsed time
from the confirmation of the output in the blockchain.
Relative timelocks are useful because they allow a chain of two or more
interdependent transactions to be held off chain, while imposing a time
Relative timelocks are useful because they allow
imposing a time
constraint on one transaction that is dependent on the elapsed time from
the confirmation of a previous transaction. In other words, the clock
doesn't start counting until the UTXO is recorded on the blockchain.
@ -994,7 +994,6 @@ corresponding +nSequence+ value. If +OP_CSV+ is specified in terms of
blocks, then so must +nSequence+. If +OP_CSV+ is specified in terms of
seconds, then so must +nSequence+.
Relative timelocks with +CSV+ are especially useful when several
[[WARNING]]
====
A script executing multiple +OP_CSV+ opcodes must only use the same
@ -1004,8 +1003,10 @@ saw with +OP_CLTV+ in <<timelock_conflicts>>. However, +OP_CSV+ allows
any two valid inputs to be included in the same transaction, so the problem
of interaction across inputs that occurs with +OP_CLTV+ doesn't affect +OP_CSV+.
====
(chained) transactions are created and signed, but not propagated, when
they're kept "off-chain." A child transaction cannot be used until the
Relative timelocks with +OP_CSV+ are especially useful when several
(chained) transactions are created and signed, but not propagated--that
is, they're kept off the blockchain (_offchain_). A child transaction cannot be used until the
parent transaction has been propagated, mined, and aged by the time
specified in the relative timelock. One application of this use case can
be seen in <<state_channels>> and <<lightning_network>>.((("",
@ -1029,15 +1030,15 @@ the same construct.
At a basic level, bitcoin conditional opcodes allow us to construct a
script that has two ways of being unlocked, depending on a
+TRUE+/+FALSE+ outcome of evaluating a logical condition. For example,
if x is +TRUE+, the redeemScript is A and the ELSE redeemScript is B.
if x is +TRUE+, the executed code path is A and the ELSE code path is B.
Additionally, bitcoin conditional expressions can be "nested"
indefinitely, meaning that a conditional clause can contain another
within it, which contains another, etc. Bitcoin Script flow control can
be used to construct very complex scripts with hundreds or even
thousands of possible execution paths. There is no limit to nesting, but
consensus rules impose a limit on the maximum size, in bytes, of a
script.
be used to construct very complex scripts with hundreds
of possible execution paths. There is no limit to nesting, but
consensus rules impose a limit on the maximum size of a
script in bytes.
Bitcoin implements flow control using the +OP_IF+, +OP_ELSE+, +OP_ENDIF+, and
+OP_NOTIF+ opcodes. Additionally, conditional expressions can contain
@ -1057,6 +1058,7 @@ if (condition):
code to run when condition is true
else:
code to run when condition is false
endif
code to run in either case
----
@ -1150,10 +1152,11 @@ clause:
----
OP_IF
<Alice's Pubkey> OP_CHECKSIG
<Alice's Pubkey>
OP_ELSE
<Bob's Pubkey> OP_CHECKSIG
<Bob's Pubkey>
OP_ENDIF
OP_CHECKSIG
----
Looking at this redeemScript, you may be wondering: "Where is the
@ -1163,13 +1166,14 @@ The condition is not part of the script. Instead, the condition
will be offered at spending time, allowing Alice and Bob to
"choose" which execution path they want.
.Alice satisifies the above script:
.Alice satisfies the above script:
----
<Alice's Sig> OP_TRUE
----
The +OP_TRUE+ at the end serves as the condition (+TRUE+) that will make the
+OP_IF+ clause execute the first redemption path for which Alice has a
+OP_IF+ clause execute the first redemption path which puts the public
key on the stack for which Alice has a
signature. The +OP_TRUE+ opcode, also known as +OP_1+, will put the
number 1 on the stack.
@ -1181,7 +1185,7 @@ known as +OP_0+, pushes an empty byte array to the stack.
<Bob's Sig> OP_FALSE
----
Bob's scriptSig puts a +0+ on the stack, causing the +OP_IF+ clause
Bob's scriptSig causes the +OP_IF+ clause
to execute the second (+OP_ELSE+) script, which requires Bob's signature.
Since +OP_IF+ clauses can be nested, we can create a "maze" of execution
@ -1242,7 +1246,7 @@ incapacitated for a while, they want the lawyer to be able to manage the
account directly.
Here's the redeemScript that Mohammed designs to achieve this (line
number prefix as XX):
number prefixed as XX):
.Variable Multi-Signature with Timelock
----
@ -1281,7 +1285,7 @@ OP_0 <Mohammed's Sig> <Zaira's Sig> OP_TRUE OP_TRUE
The +OP_0+ at the beginning of this scriptSig is because of an oddity in
+OP_CHECKMULTISIG+ that pops an extra value from the stack. The extra value
is disregarded by the +OP_CHECKMULTISIG+, but it must be present or the
script fails. Pushing an empty byte array with +OP_0+ is a workaround to the bug, as
script fails. Pushing an empty byte array with +OP_0+ is a workaround to the oddity, as
described in <<multisig_bug>>.
====
@ -1321,14 +1325,14 @@ find the answers:
- Why can't the lawyer redeem the third execution path at any time by
selecting it with +OP_FALSE+ on the scriptSig?
* How many execution paths can be used 5, 35, and 105 days,
* respectively, after the UTXO is mined?
- How many execution paths can be used 5, 35, and 105 days,
respectively, after the UTXO is mined?
* Are the funds lost if the lawyer loses his key? Does your answer
* change if 91 days have elapsed?
- Are the funds lost if the lawyer loses his key? Does your answer
change if 91 days have elapsed?
* How do the partners "reset" the clock every 29 or 89 days to prevent
* the lawyer from accessing the funds?
- How do the partners "reset" the clock every 29 or 89 days to prevent
the lawyer from accessing the funds?
- Why do some +OP_CHECKSIG+ opcodes in this script have the +VERIFY+ suffix
while others don't?((("", startref="Scomplex07")))((("",
@ -1347,8 +1351,7 @@ inside a P2SH script.
[[p2wpkh]]
===== Pay-to-Witness-Public-Key-Hash (P2WPKH)
In <<spending_bitcoin>>, ((("use cases", "buying coffee",
id="aliced")))Let's start by looking at the example of a P2PKH
Let's start by looking at the example of a P2PKH
scriptPubKey:
.Example P2PKH scriptPubKey
@ -1366,18 +1369,17 @@ to the same public key, it would look like this:
----
As you can see, a P2WPKH scriptPubKey is much
simpler than the P2PKH equivilent. It consists of two values that are
simpler than the P2PKH equivalent. It consists of two values that are
pushed on to the script evaluation stack. To an old (nonsegwit-aware)
Bitcoin client, the two pushes would look like an output that anyone can
spend and does not require a signature (or rather, can be spent with an
empty signature). To a newer, segwit-aware client, the first number (0)
spend. To a newer, segwit-aware client, the first number (0)
is interpreted as a version number (the _witness version_) and the
second part (20 bytes) is a
_witness program_. The 20-byte witness program is simply the hash of the
public key, as in a P2PKH script
Now, let’s look at the corresponding transaction that Bob uses to spend
this output. For the original script (nonsegwit), Bob’s transaction
this output. For the original script, the spending transaction
would have to include a signature within the transaction input:
.Decoded transaction showing a P2PKH output being spent with a signature
@ -1391,12 +1393,11 @@ would have to include a signature within the transaction input:
[...]
----
However, to spend the Segregated Witness output, the transaction has no
However, to spend the P2PKH output, the transaction has no
signature on that input. Instead, Bob’s transaction has an empty
+scriptSig+ and includes a Segregated Witness, outside the transaction
itself:
+scriptSig+ and includes a witness field:
.Decoded transaction showing a P2WPKH output being spent with separate witness data
.Decoded transaction showing a P2WPKH output being spent with a witness field
----
[...]
“Vin” : [
@ -1411,7 +1412,7 @@ itself:
===== Wallet construction of P2WPKH
It is extremely important to note that P2WPKH should only be created by
It is extremely important to note that P2WPKH witness programs should only be created by
the payee (recipient) and not converted by the sender from a known
public key, P2PKH script, or address. The sender has no way of knowing
if the recipient's wallet has the ability to construct segwit
@ -1437,12 +1438,12 @@ witness script.
===== Pay-to-Witness-Script-Hash (P2WSH)
The ((("use cases", "import/export", id="mohamappd")))second type of
witness program corresponds to a Pay-to-Script-Hash (P2SH) script. We
segwit v0 witness program corresponds to a Pay-to-Script-Hash (P2SH) script. We
saw this type of script in <<p2sh>>. In that example, P2SH was used by
Mohammed's company to express a multisignature script. Payments to
Mohammed's company were encoded with a script like this:
.Example P2SH output script
.Example P2SH scriptPubKey
----
OP_HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e OP_EQUAL
----
@ -1463,41 +1464,39 @@ satisfy that redeemScript, all inside the transaction input:
]
----
Now, let's look at how this entire example would be upgraded to segwit.
Now, let's look at how this entire example would be upgraded to segwit v0.
If Mohammed's customers were using a segwit-compatible wallet, they
would make a payment, creating a Pay-to-Witness-Script-Hash (P2WSH)
output that would look like this:
.Example P2WSH output script
.Example P2WSH scriptPubKey
----
0 a9b7b38d972cabc7961dbfbcb841ad4508d133c47ba87457b4a0e8aae86dbb89
----
Again, as with the example of P2WPKH, you can see that the Segregated
Witness equivalent script is a lot simpler and omits the various script
operands that you see in P2SH scripts. Instead, the Segregated Witness
program consists of two values pushed to the stack: a witness version
Witness equivalent script is a lot simpler and reduces the template
overhead that you see in P2SH scripts. Instead, the Segregated Witness
scriptPubKey consists of two values pushed to the stack: a witness version
(0) and the 32-byte SHA256 hash of the witness script.
[TIP]
====
While P2SH uses the 20-byte +RIPEMD160(SHA256(script))+ hash, the P2WSH
witness program uses a 32-byte +SHA256(script)+ hash. This difference in
the selection of the hashing algorithm is deliberate and is used to
differentiate between the two types of witness programs (P2WPKH and
P2WSH) by the length of the hash and to provide stronger security to
P2WSH (128 bits of security in P2WSH versus 80 bits of security in
P2SH).
the selection of the hashing algorithm is deliberate
to provide stronger security to
P2WSH in certain use cases (128 bits of security in P2WSH versus 80 bits
of security in P2SH). For details, see <<p2sh_collision_attacks>>.
====
Mohammed's company can spend outputs the P2WSH output by presenting the
redeem script and the signatures would be segregated _outside_ the
spending transaction as part of the witness data. Within the transaction
input, Mohammed's ((("", startref="mohamappd")))wallet would put an
empty +scriptSig+:
Mohammed's company can spend the P2WSH output by presenting the
correct witness script and sufficient signatures to satisfy it. Both the
witness script and the signatures would be
included as part of the witness data. No data would be placed in the
scriptSig.
.Decoded transaction showing a P2WSH output being spent with separate witness data
.Decoded transaction showing a P2WSH output being spent with witness data
----
[...]
“Vin” : [
@ -1514,16 +1513,16 @@ correct witness script and sufficient signatures to satisfy it. Both the
In the previous two sections, we demonstrated two types of witness
programs: <<p2wpkh>> and <<p2wsh>>. Both types of witness programs
consist of a single byte version number followed by a longer hash. They
consist of the same version number followed by a data push. They
look very similar, but are interpreted very differently: one is
interpreted as a public key hash, which is satisfied by a signature and
critical difference between them is the length of the hash:
the other as a script hash, which is satisfied by a witness script. The
critical difference between them is the length of the witness program:
- The public key hash in P2WPKH is 20 bytes
- The script hash in P2WSH is 32 bytes
- The witness program in P2WPKH is 20 bytes
- The witness program in P2WSH is 32 bytes
This is the one difference that allows a wallet to differentiate between
This is the one difference that allows a full node to differentiate between
the two types of witness programs. By looking at the length of the hash,
a node can determine what type of witness program it is, P2WPKH or
P2WSH.
@ -1531,7 +1530,7 @@ P2WSH.
==== Upgrading to Segregated Witness
As we can see from the previous examples, upgrading to Segregated
Witness is a two-step process. First, wallets must create special segwit
Witness is a two-step process. First, wallets must create segwit
type outputs. Then, these outputs can be spent by wallets that know how
to construct Segregated Witness transactions. In the examples, Alice's
wallet is able to create outputs paying
@ -1557,15 +1556,15 @@ important scenarios, which are addressed in the next section:
Let's assume, for example, that Alice's wallet is not upgraded to
segwit, but Bob's wallet is upgraded and can handle segwit transactions.
Alice and Bob can use "old" non-segwit transactions. But Bob would
Alice and Bob can use legacy non-segwit outputs. But Bob would
likely want to use segwit to reduce transaction fees, taking advantage
of the discount that applies to witness data.
of the reduced cost of witness data.
In this case Bob's wallet can construct a P2SH address that contains a
segwit script inside it. Alice's wallet sees this as a "normal" P2SH
address and can make payments to it without any knowledge of segwit.
Bob's wallet can then spend this payment with a segwit transaction,
taking full advantage of segwit and reducing transaction fees.
taking advantage of segwit and reducing transaction fees.
Both forms of witness scripts, P2WPKH and P2WSH, can be embedded in a
P2SH address. The first is noted as nested P2WPKH and the second is noted
@ -1617,8 +1616,7 @@ echo \
37Lx99uaGn5avKBxiW26HjedQE3LrDCZru
----
Now, Bob can display this address for customers to pay for their coffee.
Alice's wallet can make a payment to
Now, Alice's wallet can make a payment to
+37Lx99uaGn5avKBxiW26HjedQE3LrDCZru+, just as it would to any other
Bitcoin address.
@ -1668,7 +1666,7 @@ Next, the hashed redeemScript is turned into a P2WSH witness program:
----
Then, the witness program itself is hashed with SHA256 and RIPEMD160,
producing a new 20-byte hash, as used in traditional P2SH. Let's use
producing a new 20-byte hash, as used in legacy P2SH. Let's use
+bx+ on the command-line to do that:
.The HASH160 of the P2WSH witness program
@ -1690,8 +1688,8 @@ echo \
3Dwz1MXhM6EfFoJChHCxh1jWHb8GQqRenG
----
Now, Mohammed's clients can make payments to this address without any
need to support segwit. To send a payment to Mohammed, a wallet would
Now, Mohammed's clients can make payments to this address even if they
don't support segwit. To send a payment to Mohammed, a wallet would
lock the output with the following P2SH script:
.P2SH script used to lock payments to Mohammed's multisig