@ -496,9 +497,9 @@ those children each potentially having four billion children of their
own, and so on. It's not possible for a wallet application to generate
even a small fraction of every possible key in a BIP32 tree, which means
that recovering from data loss requires knowing more than just the
recovery code, the algorithm for obtaining your seed (e.g. BIP39), and
recovery code, the algorithm for obtaining your seed (e.g., BIP39), and
the deterministic key derivation algorithm
(e.g., BIP32)--it also requires knowing what paths in the tree of keys
(e.g., BIP32)—it also requires knowing what paths in the tree of keys
your wallet application used for generating the specific keys it distributed.
Two solutions to this problem have been adopted. The first is using
@ -509,15 +510,18 @@ defining what key derivation path to use. For example, BIP44 defines
legacy address). A wallet application implementing this standard uses
the keys in that path both when it is first started and after a
restoration from a recovery code. We call this solution _implicit
paths_.
paths_. Several popular implicit paths defined by BIPs are shown in <<bip_implicit_paths>>
[[bip_implicit_paths]]
.Implicit script paths defined by various BIPs
[cols="1,1,1"]
[options="header"]
|===
| Standard | Script | BIP32 Path
| BIP44 | P2PKH | m/44'/0'/0'
| BIP49 | Nested P2WPKH | m/49'/1'/0'
| BIP84 | P2WPKH | m/84'/0'/0'
| BIP86 | P2TR Single-key | m/86'/0'/0'
| Standard | Script | BIP32 path
| BIP44 | P2PKH | +m/44'/0'/0'+
| BIP49 | Nested P2WPKH | +m/49'/1'/0'+
| BIP84 | P2WPKH | +m/84'/0'/0'+
| BIP86 | P2TR Single-key | +m/86'/0'/0'+
|===
The second solution is to back up the path information with the recovery
@ -550,28 +554,28 @@ direct them to appropriate resources.
The final consequence of implicit paths is that they can only include
information that is either universal (such as a standardized path) or
derived from the seed (such as keys). Important non-deterministic
derived from the seed (such as keys). Important nondeterministic
information that's specific to a certain user can't be restored using
a recovery code. For example, Alice, Bob, and Carol receive funds that
can only be spent with signatures from two out of three of them. Although
Alice only needs either Bob's or Carol's signature to spend, she needs
both of their public keys in order to find their joint funds on the
blockchain. That means each of them must back up the public keys for
all three of them. As multi-signature and other advanced scripts become
all three of them. As multisignature and other advanced scripts become
more common on Bitcoin, the inflexibility of implicit paths becomes more
significant.
The advantage of explicit paths is that they can describe exactly what
keys should be used with what scripts. There's no need to support
outdated scripts, no problems with backwards or forwards compatibility,
outdated scripts, no problems with backward or forward compatibility,
and any extra information (like the public keys of other users) can be
included directly. Their disadvantage is that they require users back
included directly. Their disadvantage is that they require users to back
up additional information along with their recovery code. The
additional information usually can't compromise a user's security, so it
doesn't require as much protection as the recovery code, although it can
reduce their privacy and so does require some protection.
Almost all wallet applications which use explicit paths as of this
Almost all wallet applications that use explicit paths as of this
writing use the _output script descriptors_ standard (called
_descriptors_ for short) as specified in BIPs 380, 381, 382, 383, 384,
385, 386, and 389. Descriptors
@ -579,29 +583,29 @@ describe a script and the keys (or key paths) to be used with it.
A few example descriptors are shown in <<sample_descriptors>>.
[[sample_descriptors]]
.Sample Descriptors from Bitcoin Core documentation (with elision)
.Sample descriptors from Bitcoin Core documentation (with elision)
[cols="1,1"]
|===
| Descriptor | Explanation
| pkh(02c6...9ee5)
| +pkh(02c6...9ee5)+
| P2PKH script for the provided public key
| sh(multi(2,022f...2a01,03ac...ccbe))
| P2SH multi-signature requring two signatures corresponding to these two keys
| +sh(multi(2,022f...2a01,03ac...ccbe))+
| P2SH multisignature requring two signatures corresponding to these two keys
| pkh([d34db33f/44'/0'/0']xpub6ERA...RcEL/1/*)
| P2PKH scripts for the BIP32 +d34db33f+ with the extended public key (xpub) at the path M/44'/0'/0', which is xpub6ERA...RcEL, using the keys at M/1/* of that xpub.
| +pkh([d34db33f/44'/0'/0']xpub6ERA...RcEL/1/*)+
| P2PKH scripts for the BIP32 +d34db33f+ with the extended public key (xpub) at the path +M/44'/0'/0'+, which is +xpub6ERA...RcEL+, using the keys at +M/1/*+ of that xpub
|===
It has long been the trend for wallet applications designed only for
single signature scripts to use implicit paths. Wallet applications
designed for multiple signatures or other advanced scripts are
increasingly adopting support for explicit paths using descriptors.
Applications which do both will usually conform to the standards for
Applications that do both will usually conform to the standards for
implicit paths and also provide descriptors.
=== A Wallet Technology Stack In Detail
=== A Wallet Technology Stack in Detail
Developers of modern wallets can choose from a variety of different
technologies to help users create and use backups--and new solutions
@ -611,7 +615,7 @@ this chapter on the stack of technologies that we think is most widely
The length prefix is a compactSize unsigned integer indicating the
length of the serialized input script field. In this case, it's a single
byte (0x6b) indicating the input script is 107 bytes. We'll cover parsing
and using scripts in detail in the next chapter,
<<c_authorization_authentication>>.
and using scripts in detail in <<c_authorization_authentication>>.
[[sequence]]
==== Sequence
@ -383,7 +383,7 @@ The final four bytes of an input are its _sequence_ number.
The use and meaning of this field has changed over time.
[[original_tx_replacement]]
===== Original Sequence-Based Transaction Replacement
===== Original sequence-based transaction replacement
The sequence field was originally intended to allow creation of
multiple versions of the same transaction, with later versions replacing
@ -392,12 +392,12 @@ tracked the version of the transaction.
For example, imagine Alice and Bob want to bet on a game of cards. They
start by each signing a transaction that deposits some money into an
output with a script which requires signatures from both of them to spend, a
_multi-signature_ script (_multisig_ for short). This is called the
_setup transaction_. They then create a transaction which spends that
output with a script that requires signatures from both of them to spend, a
_multisignature_ script (_multisig_ for short). This is called the
_setup transaction_. They then create a transaction that spends that
output:
- The first version of the transaction, with nSequenece 0 (0x00000000)
- The first version of the transaction, with nSequence 0 (0x00000000),
pays Alice and Bob back the money they initially deposited. This is
called a _refund transaction_. Neither of them broadcasts the refund
transaction at this time. They only need it if there's a problem.
@ -441,7 +441,7 @@ alternative scenarios:
This type of protocol is what we now call a _payment channel_.
Bitcoin's creator, in an email attributed to him, called these
high-frequency transactions and described a number of features added to
_high-frequency transactions_ and described a number of features added to
the protocol to support them. We'll learn about several of those other
features later and also discover how modern versions of payment channels
are increasingly being used in Bitcoin today.
@ -476,20 +476,20 @@ indicated by its outpoint) to be replaced by a different transaction
containing the same input. However, that situation didn't last forever.
[[sequence-bip125]]
===== Opt-in Transaction Replacement Signaling
===== Opt-in transaction replacement signaling
After the original sequence-based transaction replacement was disabled
due to the potential for abuse, a solution was proposed: programming
Bitcoin Core and other relaying full node software to allow a
transaction that paid a higher transaction fee rate to replace a
conflicting transaction that paid a lower fee rate. This is called
_Replace-By-Fee_, or _RBF_ for short. Some users and businesses
_replace by fee_, or _RBF_ for short. Some users and businesses
objected to adding support for transaction replacement back into Bitcoin
Core, so a compromise was reached that once again used the sequence
field in support of replacement.
As documented in BIP125, an unconfirmed transaction with any input that
has an sequence set to a value below 0xfffffffe (i.e., at least 2 below
has a sequence set to a value below 0xfffffffe (i.e., at least 2 below
the maximum value) signals to the network that its signer wants it to be
replaceable by a conflicting transaction paying a higher fee rate.
Bitcoin Core allowed those unconfirmed transactions to be replaced and
@ -504,7 +504,7 @@ and sequence signals, which we'll see in <<rbf>>.
[[relative_timelocks]]
===== Sequence as a consensus-enforced relative timelock
In the <<version>> section, we learned that the BIP68 soft fork added
In <<version>>, we learned that the BIP68 soft fork added
a new constraint to transactions with version numbers 2 or higher. That
constraint applies to the sequence field.
@ -547,14 +547,14 @@ as defined by BIP68.
image::images/mbc3_0603.png["BIP68 definition of sequence encoding"]
Note that any transaction which sets a relative timelock using sequence
also sends the signal for opt-in replace-by-fee as described in
also sends the signal for opt-in replace by fee as described in
<<sequence-bip125>>.
=== Outputs
The outputs field of a transaction contains several fields related to
specific outputs. Just as we did with the inputs field, we'll start by
looking at the specific bytes of the output field from the example
looking at the specific bytes of the outputs field from the example
transaction where Alice pays Bob, displayed as
a map of those bytes in <<output-byte-map>>.
@ -564,7 +564,7 @@ image::images/mbc3_0604.png["A byte map of the outputs field from Alice's transa
==== Outputs Count
Identical to the start of the input section of a transaction, the output
Identical to the start of the inputs section of a transaction, the outputs
field begins with a count indicating the number of outputs in this
transaction. It's a compactSize integer and must be greater than zero.
@ -573,7 +573,7 @@ The example transaction has two outputs.
==== Amount
The first field of a specific output is its _amount_, also called
"value" in Bitcoin Core. This is an eight-byte signed integer indicating
"value" in Bitcoin Core. This is an 8-byte signed integer indicating
the number of _satoshis_ to transfer. A satoshi is the smallest unit of
bitcoin that can be represented in an onchain Bitcoin transaction.
There are 100 million satoshis in a bitcoin.
@ -584,7 +584,7 @@ zero and as large as 21 million bitcoins (2.1 quadrillion satoshis).
//TODO:describe early integer overflow problem
[[uneconomical_outputs]]
===== Uneconomical Outputs and Disallowed Dust
===== Uneconomical outputs and disallowed dust
Despite not having any value, a zero-value output can be spent under
the same rules as any other output. However, spending an output (using
@ -622,7 +622,7 @@ several arbitrary numbers, so many programs we're aware of simply
assume outputs with less than 546 satoshis are dust and will not be
relayed or mined by default. There are occasionally proposals to lower
dust limits, and counterproposals to raise them, so we encourage
developers using presigned transactions or multi-party protocols to
developers using presigned transactions or multiparty protocols to
check whether the policy has changed since publication of this book.
[TIP]
@ -644,7 +644,7 @@ use Utreexo.
Bitcoin Core's policy rules about dust do have one exception: output
scripts starting with +OP_RETURN+, called _data carrier outputs_,
can have a value of zero. The OP_RETURN opcode causes the script to
can have a value of zero. The +OP_RETURN+ opcode causes the script to
immediately fail no matter what comes after it, so these outputs can
never be spent. That means full nodes don't need to keep track of them,
a feature Bitcoin Core takes advantage of to allow users to store small
@ -654,7 +654,7 @@ uneconomical--any satoshis assigned to them become
permanently unspendable--so allowing the amount to be zero ensures
satoshis aren't being destroyed.
==== Output scripts
==== Output Scripts
The output amount is followed by a compactSize integer indicating the
length of the _output script_, the script that contains the
@ -662,7 +662,7 @@ conditions which will need to be fulfilled in order to spend the
bitcoins. According to Bitcoin's
consensus rules, the minimum size of an output script is zero.
The consensus maximum allowed size of an outputs script varies depending on
The consensus maximum allowed size of an output script varies depending on
when it's being checked. There's no explicit limit on the size of an
output script in the output of a transaction, but a later transaction can
only spend a previous output with a script of 10,000 bytes or
@ -673,10 +673,10 @@ the block containing it.
[[anyone-can-spend]]
[TIP]
====
An output script with zero length can be spent by a input script containing
OP_TRUE. Anyone can create that input script, which means anyone
An output script with zero length can be spent by an input script containing
++OP_TRUE++. Anyone can create that input script, which means anyone
can spend an empty output script. There are an essentially unlimited
number of scripts which anyone can spend and they are known to Bitcoin
number of scripts that anyone can spend and they are known to Bitcoin
protocol developers as _anyone can spends_. Upgrades to Bitcoin's
script language often take an existing anyone-can-spend script and add
new constraints to it, making it only spendable under the new
@ -692,14 +692,14 @@ transaction outputs_. This was originally implemented after the
discovery of several early bugs in Bitcoin related to the Script
language and is retained in modern Bitcoin Core to support
anyone-can-spend upgrades and to encourage the best practice of placing
script conditions in P2SH redeemScripts, segwit v0 witness scripts, and
script conditions in P2SH redeem script, segwit v0 witness scripts, and
segwit v1 (taproot) leaf scripts.
We'll look at each of the current standard transaction templates and
learn how to parse scripts in <<c_authorization_authentication>>.
[[witness_structure]]
=== Witness structure
=== Witness Structure
In court, a witness is someone who testifies that they saw something
important happen. Human witnesses aren't always reliable, so courts
@ -717,7 +717,7 @@ decide that the important problem had been solved.
When spending bitcoins, the important problem we want to solve is
determining whether the spend was authorized by the person or people who
control those bitcoins. The thousands of full nodes which enforce
control those bitcoins. The thousands of full nodes that enforce
Bitcoin's consensus rules can't interrogate human witnesses, but they can
accept _witnesses_ that consist entirely of data for solving math
problems. For example, a witness of _2_ will allow spending bitcoins
@ -730,14 +730,14 @@ 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 <<c_signatures>>, an
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 that 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
solution to the equation is called a _signature_.
The following script contains a public key and an opcode that requires
a corresponding signature commit to the data in the spending transaction. Like
the number _2_ in our simple example, the signature is our witness.
the number _2_ in our simple example, the signature is our witness:
----
<public key> OP_CHECKSIG
@ -759,14 +759,14 @@ that are signed out of order. For example, Alice and Bob want to
deposit funds into a script that can only be spent with signatures from
both of them, but they each also want to get their money back if the
other person becomes unresponsive. A simple solution is to sign
transactions out of order.
transactions out of order:
- Tx~0~ pays money from Alice and money from Bob into an output with a
script that requries signatures from both Alice and Bob to spend
script that requires signatures from both Alice and Bob to spend.
- Tx~1~ spends the previous output to two outputs, one refunding Alice
her money and one refunding Bob his money (minus a small amount for
transaction fees)
transaction fees).
- If Alice and Bob sign Tx~1~ before they sign Tx~0~, then they're both
guaranteed to be able to get a refund at any time. The protocol
@ -774,7 +774,7 @@ transactions out of order.
protocol_.
A problem with this construction in the legacy transaction format is
that every field, including the input script field which contains
that every field, including the input script field that contains
signatures, is used to derive a transaction's identifier (txid). The
txid for Tx~0~ is part of the input's outpoint in Tx~1~. That means
there's no way for Alice and Bob to construct Tx~1~ until both
@ -794,7 +794,7 @@ consider our simple script from <<witness_structure>>:
2 OP_ADD 4 OP_EQUAL
----
We can make this script pass by providing the value _2_ in a input script,
We can make this script pass by providing the value _2_ in an input script,
but there are several ways to put that value on the stack in Bitcoin.
Here are just a few:
@ -831,7 +831,7 @@ include Alice's original version in the same blockchain, which means
there's no way for Bob's transaction to spend its output.
Bob's payment to Carol has been made invalid even though neither Alice,
Bob, nor Carol did anything wrong. Someone not involved in the
transaction (a third-party) was able to change (mutate) Alice's
transaction (a thirdparty) was able to change (mutate) Alice's
transaction, a problem called _unwanted third-party transaction
malleability_.
@ -861,17 +861,17 @@ For example, Alice and Bob have deposited their money into a script
requiring a signature from both of them to spend. They've also created
a refund transaction that allows each of them to get their money back at
any time. Alice decides she wants to spend just some of the
money, so she cooperates with Bob to create a chain of transactions.
money, so she cooperates with Bob to create a chain of transactions:
- Tx~0~ includes signatures from both Alice and Bob, spending its
bitcoins to two outputs. The first output spends some of Alice's
money; the second output returns the remainder of the bitcoins back to
the script requiring Alice and Bob's signatures. Before signing this
transaction, they create a new refund transaction, Tx~1~
transaction, they create a new refund transaction, Tx~1~.
- Tx~1~ spends the second output of Tx~0~ to two new outputs, one to
Alice for her share of the joint funds, and one to Bob for his share.
Alice and Bob both sign this transaction before they sign Tx~0~
Alice and Bob both sign this transaction before they sign Tx~0~.
There's no circular dependency here and, if we ignore third-party
transaction malleability, this looks like it should provide us with a
@ -898,7 +898,7 @@ protocol developers knew how to solve the problems of circular
dependence, third-party malleability, and second-party malleability. The
idea was to avoid including the input script in the calculation that
produces a transaction's txid. Recall that an abstract name for the data
held by a input script is a _witness_. The idea of separating the rest of
held by an input script is a _witness_. The idea of separating the rest of
the data in a transaction from its witness for the purpose of generating
a txid is called _segregated witness_ (segwit).
@ -909,8 +909,8 @@ a _hard fork_. Hard forks come with a lot of challenges, as we'll
discuss further in <<hard_forks>>.
An alternative approach to segwit was described in late 2015. This
would use a backwards-compatible change to the consensus rules, called a
_soft fork_. Backwards compatible means that full nodes implementing
would use a backward-compatible change to the consensus rules, called a
_soft fork_. Backward compatible means that full nodes implementing
the change must not accept any blocks that full nodes without the change
would consider invalid. As long as they obey that rule, newer full
nodes can reject blocks that older full nodes would accept, giving them
@ -920,15 +920,15 @@ explore the details of upgrading Bitcoin's consensus rules in
<<mining>>).
The soft fork segwit approach is based on anyone-can-spend
output scripts. A script which starts with any of the numbers 0 to 16
output scripts. A script that starts with any of the numbers 0 to 16
and followed by 2 to 40 bytes of data is defined as a segwit
output script template. The number indicates its version (e.g. 0 is
output script template. The number indicates its version (e.g., 0 is
segwit version 0, or _segwit v0_). The data is called a _witness
program_. It's also possible to wrap the segwit template in a P2SH
commitment, but we won't deal with that in this chapter.
From the perspective of old nodes, these output script templates can be
spent with an empty input script. From the perspective of a new node which
spent with an empty input script. From the perspective of a new node that
is aware of the new segwit rules, any payment to a segwit output script
template must only be spent with an empty input script. Notice the
difference here: old nodes _allow_ an empty input script; new nodes
@ -951,8 +951,9 @@ from someone who controlled the private key. To make that system more
flexible, the initial release of Bitcoin introduced scripts that allow
bitcoins to be received to output scripts and spent with input scripts.
Later experience with contract protocols inspired allowing bitcoins to
be received to witness programs and spent with the witness structure.
be received to witness programs and spent with the witness structure. The terms and fields used in different versions of Bitcoin are shown in <<terms_used_authorization_authentication>>.
[[terms_used_authorization_authentication]]
.Terms used for authorization and authentication data in different parts of Bitcoin
[cols="1,1,1"]
|===
@ -966,7 +967,7 @@ be received to witness programs and spent with the witness structure.
Similar to the inputs and outputs fields, the witness structure contains
other fields, so we'll start with a map of those bytes from
Alice's transaction in <<alice_tx_witness_map>>:
Alice's transaction in <<alice_tx_witness_map>>.
[[alice_tx_witness_map]]
.A byte map of the witness structure from Alice's transaction
@ -1013,7 +1014,7 @@ transaction in a block unless it satisfies one of the following rules:
included in the blockchain by setting its lock time to a value of
500,000,000 or greater. In this case, the field is parsed as epoch
time (the number of seconds since 1970-01-01T00:00 UTC) and the
transaction can only be included in a block with a _Median Time Past_
transaction can only be included in a block with a _median time past_
(MTP) greater than the lock time. MTP is normally about an hour or
two behind the current time. The rules for MTP are described in
<<mtp>>.
@ -1039,12 +1040,12 @@ Some of the special rules for coinbase transactions include:
- They may only have one input.
- The single input must have an outpoint with a null txid (consisting entirely
of zeroes) and a maximal output index (0xffffffff). This prevents the
of zeros) and a maximal output index (0xffffffff). This prevents the
coinbase transaction from referencing a previous transaction output,
which would (at the very least) be confusing given that the coinbase
transaction pays out fees and subsidy.
- The field which would contain a input script in a normal transaction is
- The field that would contain an input script in a normal transaction is
called a _coinbase_. It's this field that gives the coinbase
transaction its name. The coinbase field must be at least two bytes
and not longer than 100 bytes. This script is not executed but legacy
@ -1070,13 +1071,13 @@ A coinbase transaction can have any other outputs that would be valid in
a normal transaction. However, a transaction spending one of those
outputs cannot be included in any block until after the coinbase
transaction has received 100 confirmations. This is called the
_maturity rule_ and coinbase transaction outputs which don't yet have
_maturity rule_, and coinbase transaction outputs that don't yet have
100 confirmations are called _immature_.
//TODO:stretch goal to describe the reason for the maturity rule and,
//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 occasionally be the cause of
unusual problems in software that's not designed to expect them.
@ -1171,7 +1172,7 @@ In this chapter, we looked at each of the fields in a transaction and
discovered how they communicate to full nodes the details about the
bitcoins to be transferred between users. We only briefly looked at the
output script, input script, and witness structure that allow specifying and
satisfying conditions which restrict who can spend what bitcoins.
satisfying conditions that restrict who can spend what bitcoins.
Understanding how to construct and use these conditions is essential to
ensuring that only Alice can spend her bitcoins, so they will be the
Multisignature scripts set a condition where _k_ public keys
are recorded in the script and at least _t_ of those must provide
@ -320,12 +320,12 @@ spend the funds.
[TIP]
====
Some Bitcoin documentation, including earlier editions of this book,
uses the term "m-of-n" for traditional multisignature. However, it's hard
uses the term "m-of-n" for a traditional multisignature. However, it's hard
to tell "m" and "n" apart when they're spoken, so we use the alternative
t-of-k. Both phrases refer to the same type of signature scheme.
====
The general form of a output script setting a t-of-k multisignature
The general form of an output script setting a t-of-k multisignature
condition is:
----
@ -363,21 +363,21 @@ the input script has
two valid signatures from private keys that correspond to two of
the three public keys set as an encumbrance.
At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most 3
At this time, Bitcoin Core's transaction relay policy limits multisignature output scripts to at most three
listed public keys, meaning you can do anything from a 1-of-1 to a
3-of-3 multisignature or any combination within that range.
You may want to check the +IsStandard()+ function to see what is currently
accepted by the network. Note that the limit of 3 keys applies only to
accepted by the network. Note that the limit of three keys applies only to
standard (also known as "bare") multisignature scripts, not to
scripts wrapped in another structure like P2SH, P2WSH, or P2TR.
P2SH multisignature scripts are limited by both policy and consensus to
15 keys, allowing for up to 15-of-15 multisignature. We will learn about
15 keys, allowing for up to a 15-of-15 multisignature. We will learn about
P2SH in <<p2sh>>. All other scripts are consensus limited to 20 keys
per +OP_CHECKMULTSIG+ or +OP_CHECKMULTISIGVERIFY+ opcode, although one
script may include multiple of those opcodes.
[[multisig_bug]]
==== An oddity in CHECKMULTISIG execution
==== An Oddity in CHECKMULTISIG Execution
There is an oddity in
++OP_CHECKMULTISIG++'s execution that requires a slight workaround. When
@ -393,8 +393,8 @@ example:
----
First, +OP_CHECKMULTISIG+ pops the top item, which is +k+ (in this example
"3"). Then it pops +k+ items, which are the public keys that can sign.
In this example, public keys A, B, and C. Then, it pops one item, which
"3"). Then it pops +k+ items, which are the public keys that can sign;
in this example, public keys A, B, and C. Then, it pops one item, which
is +t+, the quorum (how many signatures are needed). Here t = 2. At this
point, +OP_CHECKMULTISIG+ should pop the final +t+ items, which are the
signatures, and see if they are valid. However, unfortunately, an oddity in
@ -402,7 +402,7 @@ the implementation causes +OP_CHECKMULTISIG+ to pop one more item (t+1
total) than it should. The extra item is called the _dummy stack
element_ and it is disregarded when checking the
signatures so it has no direct effect on +OP_CHECKMULTISIG+ itself.
However, the dummy element must be present because, if it is not present,
However, the dummy element must be present because, if it isn't present,
when +OP_CHECKMULTISIG+ attempts to pop on an empty stack, it will cause a
stack error and script failure (marking the transaction as invalid).
Because the dummy element is disregarded it can be anything, but
@ -443,9 +443,9 @@ The signature is checked first against +key0+, then +key1+, and then
the other keys before it is finally compared to its corresponding
+key4+. That means five signature checking operations need to be
performed even though there's only one signature. One way to eliminate
this redundancy would have been to provide OP_CHECKMULTISIG a map
this redundancy would have been to provide +OP_CHECKMULTISIG+ a map
indicating which provided signature corresponds to which public key,
allowing the OP_CHECKMULTISIG operation to only perform exactly +t+
allowing the +OP_CHECKMULTISIG+ operation to only perform exactly +t+
signature-checking operations. It's possible that Bitcoin's original
developer added the extra element (which we now call the dummy stack
element) in the original version of Bitcoin so that they could add the
@ -463,9 +463,9 @@ to see an extra +OP_0+ in the beginning, whose only purpose is as a
workaround to an oddity in the consensus rules.
[[p2sh]]
=== Pay-to-Script-Hash (P2SH)
=== Pay to Script Hash
Pay-to-Script-Hash (P2SH) was
Pay to script hash (P2SH) was
introduced in 2012 as a powerful new type of operation that greatly
simplifies the use of complex scripts. To explain the need
for P2SH, let's look at a practical example.
@ -507,7 +507,7 @@ the use of complex scripts as easy as a payment to a single-key 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 satisfies the script. In simple terms,
matches the commitment in addition to the data that 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."
@ -536,7 +536,7 @@ with P2SH.
As you can see from the tables, with P2SH the complex script that
details the conditions for spending the output (redeem script) is not
presented in the output script. Instead, only a hash of it is in the
output script and the reedemScript itself is presented later, as part
output script and the redeem script itself is presented later, as part
of the input script when the output is spent. This shifts the burden
in fees and complexity from the spender to the receiver of the
transaction.
@ -562,7 +562,7 @@ very long:
This entire script can instead be represented by a 20-byte cryptographic
hash, by first applying the SHA256 hashing algorithm and then applying
the RIPEMD160 algorithm on the result. For example, starting with the
the RIPEMD-160 algorithm on the result. For example, starting with the
hash of Mohammed's redeem script:
----
@ -694,7 +694,7 @@ to the inclusion of nonpayment data argue that it
burdens 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 may create UTXOs that cannot be spent,
using legacy Bitcoin address as a freeform 20-byte field.
using a 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
@ -732,16 +732,16 @@ whole point of an +OP_RETURN+ output is that you can't spend the money locked in
output, and therefore it does not need to be held in the UTXO set as
potentially spendable: +OP_RETURN+ outputs are _provably unspendable_. +OP_RETURN+ outputs
usually have a zero amount, because any bitcoins
assigned to such an output is effectively lost forever. If an +OP_RETURN+ output is
assigned to such an output are effectively lost forever. If an +OP_RETURN+ output is
referenced as an input in a transaction, the script validation engine
will halt the execution of the validation script and mark the
transaction as invalid. The execution of +OP_RETURN+ essentially causes the
script to "RETURN" with a +FALSE+ and halt. Thus, if you accidentally
reference a +OP_RETURN+ output as an input in a transaction, that
reference an +OP_RETURN+ output as an input in a transaction, that
transaction is invalid.
[[lock_time_limitations]]
==== Transaction lock time limitations
==== Transaction Lock Time Limitations
Use of the lock time allows a spender to restrict a transaction from
being included in a block until a specific block height, but it does not
@ -758,7 +758,7 @@ However:
* Alice can create a conflicting transaction, spending the same inputs without a lock time. Thus, Alice can spend the same UTXO before the 3 months have elapsed.
* Bob has no guarantee that Alice won't do that.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. One way to guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed, the timelock restriction must be placed on the UTXO itself and be part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
It is important to understand the limitations of transaction lock time. The only guarantee is that Bob will not be able to redeem the presigned transaction before 3 months have elapsed. There is no guarantee that Bob will get the funds. One way to guarantee that Bob will receive the funds but cannot spend them until 3 months have elapsed is to place the timelock restriction on the UTXO itself as part of the script, rather than on the transaction. This is achieved by the next form of timelock, called Check Lock Time Verify.
==== Check Lock Time Verify (OP_CLTV)
@ -814,29 +814,29 @@ Alice set. Bob then broadcasts the transaction on the Bitcoin network.
Bob's transaction is evaluated as follows. If the +OP_CHECKLOCKTIMEVERIFY+
parameter Alice set is less than or equal the spending transaction's
lock time, script execution continues (acts as if a _no
operation_ or OP_NOP opcode was executed). Otherwise, script
operation_ or +OP_NOP+ opcode was executed). Otherwise, script
execution halts and the transaction is deemed invalid.
More precisely, BIP65 explains that +OP_CHECKLOCKTIMEVERIFY+ fails and
halts execution if:
halts execution if one of the following occurs:
1. the stack is empty; or
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 lock time field are not the same; or
4. the top stack item is greater than the transaction's lock time field; or
5. the sequence field of the input is 0xffffffff.
* The stack is empty.
* The top item on the stack is less than 0.
* The lock-time type (height versus timestamp) of the top stack item and the lock time field are not the same.
* The top stack item is greater than the transaction's lock time field.
* The sequence field of the input is 0xffffffff.
[[timelock_conflicts]]
.Timelock conflicts
.Timelock Conflicts
[WARNING]
====
+OP_CLTV+ and lock time use the same format to describe timelocks, either
a block height or the time elapsed in seconds since Unix epoch.
a block height or the time elapsed in seconds since the Unix epoch.
Critically, when used together, the format of lock time must match
that of +OP_CLTV+ in the outputs--they must both reference either
block height or time in seconds.
The above implies that a script can never be valid if it must execute
This implies that a script can never be valid if it must execute
two different calls to +OP_CLTV+, one that uses a height and one that
uses a time. It can be easy to make this mistake when writing advanced
scripts, so be sure to thoroughly test your scripts on a test network or
@ -895,7 +895,7 @@ transaction-level feature and a script-level opcode. The
transaction-level relative timelock is implemented as a consensus rule
on the value of +sequence+, a transaction field that is set in every
transaction input. Script-level relative timelocks are implemented with
the +OP_CHECKSEQUENCEVERIFY+ (OP_CSV) opcode.
the +OP_CHECKSEQUENCEVERIFY+ (+OP_CSV+) opcode.
Relative timelocks are
implemented according to the specifications in
@ -909,12 +909,12 @@ the consensus rules.
==== Relative Timelocks with OP_CSV
Just like OP_CLTV
Just like +OP_CLTV+
and lock time, there is a script opcode for relative timelocks that
leverages the sequence value in scripts. That opcode is
+OP_CHECKSEQUENCEVERIFY+, commonly referred to as +OP_CSV+ for short.
The +OP_CSV+ opcode when evaluated in an UTXO's script allows
The +OP_CSV+ opcode when evaluated in a UTXO's script allows
spending only in a transaction whose input sequence value is greater
than or equal to the +OP_CSV+ parameter. Essentially, this restricts
spending the UTXO until a certain number of blocks or seconds have
@ -939,8 +939,7 @@ 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>>.
specified in the relative timelock. One application of this use case is shown in <<state_channels>> and <<lightning_network>>.
Clare Laylock
8 months ago