@ -1,517 +1,4 @@
[[ch06]]
[[transactions]]
== Transactions
[[ch06_intro]]
=== Introduction
((("transactions", "defined")))((("warnings and cautions", see="also
security")))Transactions are the most important part of the Bitcoin
system. Everything else in bitcoin is designed to ensure that
transactions can be created, propagated on the network, validated, and
finally added to the global ledger of transactions (the blockchain).
Transactions are data structures that encode the transfer of value
between participants in the Bitcoin system. Each transaction is a public
entry in bitcoin's blockchain, the global double-entry bookkeeping
ledger.
In this chapter we will examine all the various forms of transactions,
what they contain, how to create them, how they are verified, and how
they become part of the permanent record of all transactions. When we
use the term "wallet" in this chapter, we are referring to the software
that constructs transactions, not just the database of keys.
[[tx_structure]]
=== Transactions in Detail
((("use cases", "buying coffee", id="alicesix")))In
<<ch02_bitcoin_overview>>, we looked at the transaction Alice used to
pay for coffee at Bob's coffee shop using a block explorer
(<<alices_transactions_to_bobs_cafe>>).
The block explorer application shows a transaction from Alice's
"address" to Bob's "address." This is a much simplified view of what is
contained in a transaction. In fact, as we will see in this chapter,
much of the information shown is constructed by the block explorer and
is not actually in the transaction.
[[alices_transactions_to_bobs_cafe]]
.Alice's transaction to Bob's Cafe
image::images/mbc2_0208.png["Alice Coffee Transaction"]
[[transactions_behind_the_scenes]]
==== Transactions—Behind the Scenes
((("transactions", "behind the scenes details of")))Behind the scenes,
an actual transaction looks very different from a transaction provided
by a typical block explorer. In fact, most of the high-level constructs
we see in the various bitcoin application user interfaces _do not
actually exist_ in the Bitcoin system.
We can use Bitcoin Core's command-line interface (+getrawtransaction+
and +decoderawtransaction+) to retrieve Alice's "raw" transaction,
decode it, and see what it contains. The result looks like this:
[[alice_tx]]
.Alice's transaction decoded
[source,json]
----
{
"version": 1,
"locktime": 0,
"vin": [
{
"txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
"vout": 0,
"scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.01500000,
"scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY OP_CHECKSIG"
},
{
"value": 0.08450000,
"scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
}
]
}
----
You may notice a few things about this transaction, mostly the things
that are missing! Where is Alice's address? Where is Bob's address?
Where is the 0.1 input "sent" by Alice? In bitcoin, there are no coins,
no senders, no recipients, no balances, no accounts, and no addresses.
All those things are constructed at a higher level for the benefit of
the user, to make things easier to understand.
You may also notice a lot of strange and indecipherable fields and
hexadecimal strings. Don't worry, we will explain each field shown here
in detail in this chapter.
[[tx_inputs_outputs]]
=== Transaction Outputs and Inputs
((("transactions", "outputs and inputs", id="Tout06")))((("outputs and
inputs", "outputs defined")))((("unspent transaction outputs
(UTXO)")))((("UTXO sets")))((("transactions", "outputs and inputs",
"output characteristics")))((("outputs and inputs", "output
characteristics")))The fundamental building block of a bitcoin
transaction is a _transaction output_. Transaction outputs are
indivisible chunks of bitcoin currency, recorded on the blockchain, and
recognized as valid by the entire network. Bitcoin full nodes track all
available and spendable outputs, known as _unspent transaction outputs_,
or _UTXO_. The collection of all UTXO is known as the _UTXO set_ and
currently numbers in the millions of UTXO. The UTXO set grows as new
UTXO is created and shrinks when UTXO is consumed. Every transaction
represents a change (state transition) in the UTXO set.
((("balances")))When we say that a user's wallet has "received" bitcoin,
what we mean is that the wallet has detected an UTXO that can be spent
with one of the keys controlled by that wallet. Thus, a user's bitcoin
"balance" is the sum of all UTXO that user's wallet can spend and which
may be scattered among hundreds of transactions and hundreds of blocks.
The concept of a balance is created by the wallet application. The
wallet calculates the user's balance by scanning the blockchain and
aggregating the value of any UTXO the wallet can spend with the keys it
controls. Most wallets maintain a database or use a database service to
store a quick reference set of all the UTXO they can spend with the keys
they control.
((("satoshis")))A transaction output can have an arbitrary (integer)
value denominated as a multiple of satoshis. Just as dollars can be
divided down to two decimal places as cents, bitcoin can be divided down
to eight decimal places as satoshis. Although an output can have any
arbitrary value, once created it is indivisible. This is an important
characteristic of outputs that needs to be emphasized: outputs are
_discrete_ and _indivisible_ units of value, denominated in integer
satoshis. An unspent output can only be consumed in its entirety by a
transaction.
((("change, making")))If an UTXO is larger than the desired value of a
transaction, it must still be consumed in its entirety and change must
be generated in the transaction. In other words, if you have an UTXO
worth 20 bitcoin and want to pay only 1 bitcoin, your transaction must
consume the entire 20-bitcoin UTXO and produce two outputs: one paying 1
bitcoin to your desired recipient and another paying 19 bitcoin in
change back to your wallet. As a result of the indivisible nature of
transaction outputs, most bitcoin transactions will have to generate
change.
Imagine a shopper buying a $1.50 beverage, reaching into her wallet and
trying to find a combination of coins and bank notes to cover the $1.50
cost. The shopper will choose exact change if available e.g. a dollar
bill and two quarters (a quarter is $0.25), or a combination of smaller
denominations (six quarters), or if necessary, a larger unit such as a
$5 note. If she hands too much money, say $5, to the shop owner, she
will expect $3.50 change, which she will return to her wallet and have
available for future transactions.
Similarly, a bitcoin transaction must be created from a user's UTXO in
whatever denominations that user has available. Users cannot cut an UTXO
in half any more than they can cut a dollar bill in half and use it as
currency. The user's wallet application will typically select from the
user's available UTXO to compose an amount greater than or equal to the
desired transaction amount.
As with real life, the bitcoin application can use several strategies to
satisfy the purchase amount: combining several smaller units, finding
exact change, or using a single unit larger than the transaction value
and making change. All of this complex assembly of spendable UTXO is
done by the user's wallet automatically and is invisible to users. It is
only relevant if you are programmatically constructing raw transactions
from UTXO.
A transaction consumes previously recorded unspent transaction outputs
and creates new transaction outputs that can be consumed by a future
transaction. This way, chunks of bitcoin value move forward from owner
to owner in a chain of transactions consuming and creating UTXO.
((("transactions", "coinbase transactions")))((("coinbase
transactions")))((("mining and consensus", "coinbase transactions")))The
exception to the output and input chain is a special type of transaction
called the _coinbase_ transaction, which is the first transaction in
each block. This transaction is placed there by the "winning" miner and
creates brand-new bitcoin payable to that miner as a reward for mining.
This special coinbase transaction does not consume UTXO; instead, it has
a special type of input called the "coinbase." This is how bitcoin's
money supply is created during the mining process, as we will see in
<<mining>>.
[TIP]
====
What comes first? Inputs or outputs, the chicken or the egg? Strictly
speaking, outputs come first because coinbase transactions, which
generate new bitcoin, have no inputs and create outputs from nothing.
====
[[tx_outs]]
==== Transaction Outputs
((("transactions", "outputs and inputs", "output
components")))((("outputs and inputs", "output parts")))Every bitcoin
transaction creates outputs, which are recorded on the bitcoin ledger.
Almost all of these outputs, with one exception (see <<op_return>>)
create spendable chunks of bitcoin called UTXO, which are then
recognized by the whole network and available for the owner to spend in
a future transaction.
UTXO are tracked by every full-node Bitcoin client in the UTXO set. New
transactions consume (spend) one or more of these outputs from the UTXO
set.
Transaction outputs consist of two parts:
- An amount of bitcoin, denominated in _satoshis_, the smallest bitcoin
unit
- A cryptographic puzzle that determines the conditions required to
spend the output
((("locking scripts")))((("scripting", "locking
scripts")))((("witnesses")))((("scriptPubKey")))The cryptographic puzzle
is also known as a _locking script_, a _witness script_, or a
+scriptPubKey+.
The transaction scripting language, used in the locking script mentioned
previously, is discussed in detail in <<tx_script>>.
Now, let's look at Alice's transaction (shown previously in
<<transactions_behind_the_scenes>>) and see if we can identify the
outputs. In the JSON encoding, the outputs are in an array (list) named
+vout+:
[source,json]
----
"vout": [
{
"value": 0.01500000,
"scriptPubKey": "OP_DUP OP_HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 OP_EQUALVERIFY
OP_CHECKSIG"
},
{
"value": 0.08450000,
"scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG",
}
]
----
As you can see, the transaction contains two outputs. Each output is
defined by a value and a cryptographic puzzle. In the encoding shown by
Bitcoin Core, the value is shown in bitcoin, but in the transaction
itself it is recorded as an integer denominated in satoshis. The second
part of each output is the cryptographic puzzle that sets the conditions
for spending. Bitcoin Core shows this as +scriptPubKey+ and shows us a
human-readable representation of the script.
The topic of locking and unlocking UTXO will be discussed later, in
<<tx_lock_unlock>>. The scripting language that is used for the script
in +scriptPubKey+ is discussed in <<tx_script>>. But before we delve
into those topics, we need to understand the overall structure of
transaction inputs and outputs.
===== Transaction serialization—outputs
((("transactions", "outputs and inputs", "structure of")))((("outputs
and inputs", "structure of")))((("serialization", "outputs")))When
transactions are transmitted over the network or exchanged between
applications, they are _serialized_. Serialization is the process of
converting the internal representation of a data structure into a format
that can be transmitted one byte at a time, also known as a byte stream.
Serialization is most commonly used for encoding data structures for
transmission over a network or for storage in a file. The serialization
format of a transaction output is shown in <<tx_out_structure>>.
[[tx_out_structure]]
.Transaction output serialization
[options="header"]
|=======
|Size| Field | Description
| 8 bytes (little-endian) | Amount | Bitcoin value in satoshis (10^-8^ bitcoin)
| 1–9 bytes (VarInt) | Locking-Script Size | Locking-Script length in bytes, to follow
| Variable | Locking-Script | A script defining the conditions needed to spend the output
|=======
Most bitcoin libraries and frameworks do not store transactions
internally as byte-streams, as that would require complex parsing every
time you needed to access a single field. For convenience and
readability, bitcoin libraries store transactions internally in data
structures (usually object-oriented structures).
((("deserialization")))((("parsing")))((("transactions", "parsing")))The
process of converting from the byte-stream representation of a
transaction to a library's internal representation data structure is
called _deserialization_ or _transaction parsing_. The process of
converting back to a byte-stream for transmission over the network, for
hashing, or for storage on disk is called _serialization_. Most bitcoin
libraries have built-in functions for transaction serialization and
deserialization.
See if you can manually decode Alice's transaction from the serialized
hexadecimal form, finding some of the elements we saw previously. The
section containing the two outputs is highlighted in <<example_6_1>> to
help you:
[[example_6_1]]
.Alice's transaction, serialized and presented in hexadecimal notation
====
+0100000001186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd73+
+4d2804fe65fa35779000000008b483045022100884d142d86652a3f47+
+ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039+
+ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813+
+01410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade84+
+16ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc1+
+7b4a10fa336a8d752adfffffffff02+*+60e31600000000001976a914ab6+*
*+8025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef800000000000+*
*+1976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac+*
+00000000+
====
Here are some hints:
- There are two outputs in the highlighted section, each serialized as
shown in <<tx_out_structure>>.
- The value of 0.015 bitcoin is 1,500,000 satoshis. That's +16 e3 60+ in
hexadecimal.
- In the serialized transaction, the value +16 e3 60+ is encoded in
little-endian (least-significant-byte-first) byte order, so it looks
like +60 e3 16+.
- The +scriptPubKey+ length is 25 bytes, which is +19+ in hexadecimal.
[[tx_inputs]]
==== Transaction Inputs
((("transactions", "outputs and inputs", "input
components")))((("outputs and inputs", "input components")))((("unspent
transaction outputs (UTXO)")))((("UTXO sets")))Transaction inputs
identify (by reference) which UTXO will be consumed and provide proof of
ownership through an unlocking script.
To build a transaction, a wallet selects from the UTXO it controls, UTXO
with enough value to make the requested payment. Sometimes one UTXO is
enough, other times more than one is needed. For each UTXO that will be
consumed to make this payment, the wallet creates one input pointing to
the UTXO and unlocks it with an unlocking script.
Let's look at the components of an input in greater detail. The first
part of an input is a pointer to an UTXO by reference to the transaction
hash and an output index, which identifies the specific UTXO in that
transaction. The second part is an unlocking script, which the wallet
constructs in order to satisfy the spending conditions set in the UTXO.
Most often, the unlocking script is a digital signature and public key
proving ownership of the bitcoin. However, not all unlocking scripts
contain signatures. The third part is a sequence number, which will be
discussed later.
Consider our example in <<transactions_behind_the_scenes>>. The
transaction inputs are an array (list) called +vin+:
[[vin]]
.The transaction inputs in Alice's transaction
[source,json]
----
"vin": [
{
"txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
"vout": 0,
"scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
"sequence": 4294967295
}
]
----
As you can see, there is only one input in the list (because one UTXO
contained sufficient value to make this payment). The input contains
four elements:
- A ((("transaction IDs (txd)")))transaction ID, referencing the
transaction that contains the UTXO being spent
- An output index (+vout+), identifying which UTXO from that transaction
is referenced (first one is zero)
- A +scriptSig+, which satisfies the conditions placed on the UTXO,
unlocking it for spending
- A sequence number (to be discussed later)
In Alice's transaction, the input points to the transaction ID:
----
7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18
----
and output index +0+ (i.e., the first UTXO created by that transaction).
The unlocking script is constructed by Alice's wallet by first
retrieving the referenced UTXO, examining its locking script, and then
using it to build the necessary unlocking script to satisfy it.
Looking just at the input you may have noticed that we don't know
anything about this UTXO, other than a reference to the transaction
containing it. We don't know its value (amount in satoshi), and we don't
know the locking script that sets the conditions for spending it. To
find this information, we must retrieve the referenced UTXO by
retrieving the underlying transaction. Notice that because the value of
the input is not explicitly stated, we must also use the referenced UTXO
in order to calculate the fees that will be paid in this transaction
(see <<tx_fees>>).
It's not just Alice's wallet that needs to retrieve UTXO referenced in
the inputs. Once this transaction is broadcast to the network, every
validating node will also need to retrieve the UTXO referenced in the
transaction inputs in order to validate the transaction.
Transactions on their own seem incomplete because they lack context.
They reference UTXO in their inputs but without retrieving that UTXO we
cannot know the value of the inputs or their locking conditions. When
writing bitcoin software, anytime you decode a transaction with the
intent of validating it or counting the fees or checking the unlocking
script, your code will first have to retrieve the referenced UTXO from
the blockchain in order to build the context implied but not present in
the UTXO references of the inputs. For example, to calculate the amount
paid in fees, you must know the sum of the values of inputs and outputs.
But without retrieving the UTXO referenced in the inputs, you do not
know their value. So a seemingly simple operation like counting fees in
a single transaction in fact involves multiple steps and data from
multiple transactions.
We can use the same sequence of commands with Bitcoin Core as we used
when retrieving Alice's transaction (+getrawtransaction+ and
+decoderawtransaction+). With that we can get the UTXO referenced in the
preceding input and take a look:
[[alice_input_tx]]
.Alice's UTXO from the previous transaction, referenced in the input
[source,json]
----
"vout": [
{
"value": 0.10000000,
"scriptPubKey": "OP_DUP OP_HASH160 7f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a8 OP_EQUALVERIFY OP_CHECKSIG"
}
]
----
We see that this UTXO has a value of 0.1 BTC and that it has a locking
script (+scriptPubKey+) that contains "OP_DUP OP_HASH160...".
[TIP]
====
To fully understand Alice's transaction we had to retrieve the previous
transaction(s) referenced as inputs. A function that retrieves previous
transactions and unspent transaction outputs is very common and exists
in almost every bitcoin library and API.
====
===== Transaction serialization—inputs
((("serialization", "inputs")))((("transactions", "outputs and inputs",
"input serialization")))((("outputs and inputs", "input
serialization")))When transactions are serialized for transmission on
the network, their inputs are encoded into a byte stream as shown in
<<tx_in_structure>>.
[[tx_in_structure]]
.Transaction input serialization
[options="header"]
|=======
|Size| Field | Description
| 32 bytes | Transaction Hash | Pointer to the transaction containing the UTXO to be spent
| 4 bytes | Output Index | The index number of the UTXO to be spent; first one is 0
| 1–9 bytes (VarInt) | Unlocking-Script Size | Unlocking-Script length in bytes, to follow
| Variable | Unlocking-Script | A script that fulfills the conditions of the UTXO locking script
| 4 bytes | Sequence Number | Used for locktime or disabled (0xFFFFFFFF)
|=======
As with the outputs, let's see if we can find the inputs from Alice's
transaction in the serialized format. First, the inputs decoded:
[source,json]
----
"vin": [
{
"txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18",
"vout": 0,
"scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf",
"sequence": 4294967295
}
],
----
Now, let's see if we can identify these fields in the serialized hex
encoding in <<example_6_2>>:
[[example_6_2]]
.Alice's transaction, serialized and presented in hexadecimal notation
====
+0100000001+*+186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd73+*
*+4d2804fe65fa35779000000008b483045022100884d142d86652a3f47+*
*+ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039+*
*+ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813+*
*+01410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade84+*
*+16ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc1+*
*+7b4a10fa336a8d752adfffffffff+*+0260e31600000000001976a914ab6+
+8025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef800000000000+
+1976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac00000+
+000+
====
Hints:
- The transaction ID is serialized in reversed byte order, so it starts
with (hex) +18+ and ends with +79+
- The output index is a 4-byte group of zeros, easy to identify
- The length of the +scriptSig+ is 139 bytes, or +8b+ in hex
- The sequence number is set to +FFFFFFFF+, again easy to identify((("",
startref="alicesix")))
[[tx_fees]]
==== Transaction Fees
@ -1406,112 +893,3 @@ you _must_ use RFC 6979 or a similarly deterministic-random algorithm to
ensure you generate a different _k_ for each transaction.((("",
startref="Tdigsig06")))
=== Bitcoin Addresses, Balances, and Other Abstractions
((("transactions", "higher-level abstractions", id="Thigher06")))We
began this chapter with the discovery that transactions look very
different "behind the scenes" than how they are presented in wallets,
blockchain explorers, and other user-facing applications. Many of the
simplistic and familiar concepts from the earlier chapters, such as
Bitcoin addresses and balances, seem to be absent from the transaction
structure. We saw that transactions don't contain Bitcoin addresses, per
se, but instead operate through scripts that lock and unlock discrete
values of bitcoin. Balances are not present anywhere in this system and
yet every wallet application prominently displays the balance of the
user's wallet.
Now that we have explored what is actually included in a bitcoin
transaction, we can examine how the higher-level abstractions are
derived from the seemingly primitive components of the transaction.
Let's look again at how Alice's transaction was presented on a popular
block explorer (<<alice_transaction_to_bobs_cafe>>).
[[alice_transaction_to_bobs_cafe]]
.Alice's transaction to Bob's Cafe
image::images/mbc2_0208.png["Alice Coffee Transaction"]
On the left side of the transaction, the blockchain explorer shows
Alice's Bitcoin address as the "sender." In fact, this information is
not in the transaction itself. When the blockchain explorer retrieved
the transaction it also retrieved the previous transaction referenced in
the input and extracted the first output from that older transaction.
Within that output is a locking script that locks the UTXO to Alice's
public key hash (a P2PKH script). The blockchain explorer extracted the
public key hash and encoded it using Base58Check encoding to produce and
display the Bitcoin address that represents that public key.
Similarly, on the right side, the blockchain explorer shows the two
outputs; the first to Bob's Bitcoin address and the second to Alice's
Bitcoin address (as change). Once again, to create these Bitcoin
addresses, the blockchain explorer extracted the locking script from
each output, recognized it as a P2PKH script, and extracted the
public-key-hash from within. Finally, the blockchain explorer reencoded
that public key hash with Base58Check to produce and display the Bitcoin
addresses.
If you were to click on Bob's Bitcoin address, the blockchain explorer
would show you the view in <<the_balance_of_bobs_bitcoin_address>>.
[[the_balance_of_bobs_bitcoin_address]]
.The balance of Bob's Bitcoin address
image::images/mbc2_0608.png["The balance of Bob's Bitcoin address"]
The blockchain explorer displays the balance of Bob's Bitcoin address.
But nowhere in the Bitcoin system is there a concept of a "balance."
Rather, the values displayed here are constructed by the blockchain
explorer as follows.
To construct the "Total Received" amount, the blockchain explorer first
will decode the Base58Check encoding of the Bitcoin address to retrieve
the 160-bit hash of Bob's public key that is encoded within the address.
Then, the blockchain explorer will search through the database of
transactions, looking for outputs with P2PKH locking scripts that
contain Bob's public key hash. By summing up the value of all the
outputs, the blockchain explorer can produce the total value received.
Constructing the current balance (displayed as "Final Balance") requires
a bit more work. The blockchain explorer keeps a separate database of
the outputs that are currently unspent, the UTXO set. To maintain this
database, the blockchain explorer must monitor the Bitcoin network, add
newly created UTXO, and remove spent UTXO, in real time, as they appear
in unconfirmed transactions. This is a complicated process that depends
on keeping track of transactions as they propagate, as well as
maintaining consensus with the Bitcoin network to ensure that the
correct chain is followed. Sometimes, the blockchain explorer goes out
of sync and its perspective of the UTXO set is incomplete or incorrect.
From the UTXO set, the blockchain explorer sums up the value of all
unspent outputs referencing Bob's public key hash and produces the
"Final Balance" number shown to the user.
In order to produce this one image, with these two "balances," the
blockchain explorer has to index and search through dozens, hundreds, or
even hundreds of thousands of transactions.
In summary, the information presented to users through wallet
applications, blockchain explorers, and other bitcoin user interfaces is
often composed of higher-level abstractions that are derived by
searching many different transactions, inspecting their content, and
manipulating the data contained within them. By presenting this
simplistic view of bitcoin transactions that resemble bank checks from
one sender to one recipient, these applications have to abstract a lot
of underlying detail. They mostly focus on the common types of
transactions: P2PKH with SIGHASH_ALL signatures on every input. Thus,
while bitcoin applications can present more than 80% of all transactions
in an easy-to-read manner, they are sometimes stumped by transactions
that deviate from the norm. Transactions that contain more complex
locking scripts, or different SIGHASH flags, or many inputs and outputs,
demonstrate the simplicity and weakness of these abstractions.
Every day, hundreds of transactions that do not contain P2PKH outputs
are confirmed on the blockchain. The blockchain explorers often present
these with red warning messages saying they cannot decode an address.
The following link contains the most recent "strange transactions" that
were not fully decoded: https://blockchain.info/strange-transactions[].
As we will see in the next chapter, these are not necessarily strange
transactions. They are transactions that contain more complex locking
scripts than the common P2PKH. We will learn how to decode and
understand more complex scripts and the applications they support
next.((("", startref="Thigher06")))((("", startref="alicesixtwo")))
David A. Harding
1 year ago