From 56c701a6ad2529b9a7da0662f1616b2414c02718 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Sat, 18 Feb 2023 20:48:04 -1000 Subject: [PATCH] C_Txes: edits (nearly complete rewrite) This chapter, containing parts of previous chapters 6 and 7, is almost entirely rewritten. - Instead of introducing concepts in a somewhat arbitrary order, almost every section except the last three (coinbase txes, weight, and legacy serializitaion) follows the order of transaction fields as seen in a P2P serialized transaction. - We leave details of scripts for the next chapter (authorization & authentication), signatures for the chapter after that, and fees and fee bumping for the chapter after that (reflecting the increased importance of fees). --- chapters/transactions.adoc | 1954 ++++++++++++++++++----------------- images/input-byte-map.png | Bin 0 -> 12983 bytes images/output-byte-map.png | Bin 0 -> 17152 bytes images/tx-map-1.png | Bin 0 -> 18220 bytes images/tx-weight-map.png | Bin 0 -> 14542 bytes images/witness-byte-map.png | Bin 0 -> 9355 bytes 6 files changed, 1016 insertions(+), 938 deletions(-) create mode 100644 images/input-byte-map.png create mode 100644 images/output-byte-map.png create mode 100644 images/tx-map-1.png create mode 100644 images/tx-weight-map.png create mode 100644 images/witness-byte-map.png diff --git a/chapters/transactions.adoc b/chapters/transactions.adoc index b7bd7db1..a227066e 100644 --- a/chapters/transactions.adoc +++ b/chapters/transactions.adoc @@ -1,752 +1,512 @@ [[transactions]] == Transactions -[[ch06_intro]] -=== Introduction +The way we typically transfer physical cash has little resemblance to +the way we transfer bitcoins. Physical cash is a bearer token. Alice +pays Bob by handing him some number of tokens, such as dollar bills. +By comparison, bitcoins don't exist either physically or as digital +data--Alice can't hand Bob some bitcoins or send them by email. -((("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. +Instead, consider how Alice might transfer control over a parcel of land +to Bob. She can't physically pick up the land and hand it to Bob. +Rather there exists some sort of record (usually maintained by a local +government) which describes the land Alice owns. Alice transfers that +land to Bob by convincing the government to update the record to say +that Bob now owns the land. -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. +Bitcoin works in a similar way. There exists a database on every +Bitcoin full node which says that Alice controls some number of +bitcoins. Alice pays Bob by convincing full nodes to update their +database to say that some of Alice's bitcoins are now controlled by Bob. +The data that Alice uses to convince full nodes to update their +databases is called a _transaction_. + +In this chapter we'll deconstruct a Bitcoin transaction and examine each +of its parts to see how they facilitate the transfer of value in a way +that's highly expressive and amazingly reliable. [[tx_structure]] -=== Transactions in Detail +=== A Serialized Bitcoin Transaction -((("use cases", "buying coffee", id="alicesix")))In -<>, we looked at the transaction Alice used to -pay for coffee at Bob's coffee shop using a block explorer -(<>). +In <>, we used Bitcoin Core with +the txindex option enabled to retrieve a copy of Alice's payment to Bob. +Let's retrieve the transaction containing that payment again. -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] +[[alice_tx_serialized_reprint]] +.Alice's serialized transaction +[listing] ---- -{ - "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", - } - ] -} +include::../snippets/getrawtransaction-alice.txt[] ---- -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 -<>. +There's nothing special about Bitcoin Core's serialization format. +Programs can use a different format as long as they transmit all of the +same data. However, Bitcoin Core's format is reasonably compact for the +data it transmits and simple to parse, so many other Bitcoin programs +use this format. [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. +The only other widely-used transaction serialization format of which +we're aware is the Partially Signed Bitcoin Transaction (PSBT) format +documented in BIPs 174 and 370 (with extensions documented in other +BIPs). PSBT allows an untrusted program to produce a transaction +template which can be verified and updated by trusted programs (such as +hardware signing devices) that posses the necessary private keys or +other sensitive data to fill in the template. To accomplish this, PSBT +allows storing a significant amount of metadata about a transaction, +making it much less compact than the standard serialization format. +This book does not go into detail about PSBT, but we strongly recommend +it to developers of wallets that plan to support hardware signing +devices or multiple-signer security. + ==== -[[tx_outs]] -==== Transaction Outputs +The transaction displayed in hexadecimal in <> is +replicated as a byte map in <>. Note that it takes +64 hexadecimal characters to display 32 bytes. This map shows only the +top-level fields. We'll examine each of them in the order they appear +in the transaction and describe any additional fields that they contain. -((("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 <>) -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. +[[alice_tx_byte_map]] +.A byte map of Alice's transaction +image::../images/tx-map-1.png["A byte map of Alice's 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. +[[nVersion]] +=== Version -Transaction outputs consist of two parts: +The first four bytes of a serialized Bitcoin transaction are its +version. The original version of Bitcoin transactions was version 1 +(0x01000000). All transactions in Bitcoin must follow +the rules of version 1 transactions, with many of those rules being +described throughout this book. -- An amount of bitcoin, denominated in _satoshis_, the smallest bitcoin - unit +Version 2 Bitcoin transactions were introduced in the BIP68 soft fork +change to Bitcoin's consensus rules. BIP68 places additional +constraints on the nSequence field, but those constraints only apply to +transactions with version 2 or higher. Version 1 transactions are +unaffected. BIP112, which was part of the same soft fork as BIP68, +upgraded an opcode (OP_CHECKSEQUENCEVERIFY) which will now fail if it is +evaluated as part of a transaction with a version less than 2. Beyond +those two changes, version 2 transactions are identical to version 1 +transactions. -- A cryptographic puzzle that determines the conditions required to - spend the output +.Protecting Pre-Signed Transactions +**** +The last step before broadcasting a transaction to the network for +inclusion in the blockchain is to sign it. However, it's possible to +sign a transaction without broadcasting it immediately. You can save +that pre-signed transaction for months or years in the belief that it +can be added to the blockchain later when you do broadcast it. In the +interim, you may even lose access to the private key (or keys) necessary +to sign an alternative transaction spending the funds. This isn't +hypothetical: several protocols built on Bitcoin, including Lightning +Network, depend on pre-signed transactions. -((("locking scripts")))((("scripting", "locking -scripts")))((("witnesses")))((("scriptPubKey")))The cryptographic puzzle -is also known as a _locking script_, a _witness script_, or a -+scriptPubKey+. +This creates a challenge for protocol developers when they assist users +in upgrading the Bitcoin consensus protocol. Adding new +constraints--such as BIP68 did to the nSequence field--may invalidate +some pre-signed transactions. If there's no way to create a new +signature for an equivalent transaction, then the money being spent in +the pre-signed transaction is permanently lost. -The transaction scripting language, used in the locking script mentioned -previously, is discussed in detail in <>. +This problem is solved by reserving some transaction features for +upgrades, such as version numbers. Anyone creating pre-signed +transactions prior to BIP68 should have been using version 1 +transactions, so only applying BIP68's additional constraints on +nSequence to transactions v2 or higher should not invalidate any +pre-signed transactions. -Now, let's look at Alice's transaction (shown previously in -<>) and see if we can identify the -outputs. In the JSON encoding, the outputs are in an array (list) named -+vout+: +If you implement a protocol that uses pre-signed transactions, ensure +that it doesn't use any features that are reserved for future upgrades. +Bitcoin Core's default transaction relay policy does not allow the use +of reserved features. You can test whether a transaction complies with +that policy by using the Bitcoin Core RPC +testmempoolaccept+ on Bitcoin +mainnet. +**** -[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 of this writing, a proposal to begin using version 3 transactions is +being widely considered. That proposal does not seek to change the +consensus rules but only the policy that Bitcoin full nodes use to relay +transactions. Under the proposal, version 3 transactions would be +subject to additional constraints in order to prevent certain Denial of +Service (DoS) attacks that we'll discuss further in <> -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. +=== Extended Marker and Flag -The topic of locking and unlocking UTXO will be discussed later, in -<>. The scripting language that is used for the script -in +scriptPubKey+ is discussed in <>. But before we delve -into those topics, we need to understand the overall structure of -transaction inputs and outputs. +The next two fields of the example serialized transaction were added as +part of the Segregated Witness (segwit) soft fork change to Bitcoin's +consensus rules. The rules were changed according to BIPs 141 and 143, +but the _extended serialization format_ is defined in BIP144. -===== Transaction serialization—outputs +If the transaction includes a witness field (which we'll describe in +<>), the marker must be zero (0x00) and the flag must be +non-zero. In the current P2P protocol, the flag should always be one +(0x01); alternative flags are reserved for later protocol upgrades. -((("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 <>. +If the transaction doesn't need a witness, the marker and flag most not +be present. This is compatible with the original version of Bitcoin's +transaction serialization format, now called _legacy serialization_. +For details, see <>. -[[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 -|======= +In legacy serialization, the marker byte would have been interpreted as +the number of inputs (zero). A transaction can't have zero inputs, so +the marker signals to modern programs that extended serialization is +being used. The flag field provides a similar signal and also +simplifies the process of updating the serialization format in the +future. -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). +[[inputs]] +=== Inputs -((("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. +The inputs field contains several other fields, so let's start by with a +map of those bytes in <>. -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 <> to -help you: +[[alice_tx_input_map]] +.Map of bytes in the input field of Alice's transaction +image::../images/input-byte-map.png["map of bytes in the input field of Alice's transaction"] -[[example_6_1]] -.Alice's transaction, serialized and presented in hexadecimal notation +==== Inputs Count + +The input field starts with an integer indicating the number of inputs +in the transaction. The minimum value is one. There's no explicit +maximum value, but restrictions on the maximum size of a transaction +effectively limit transactions to a few thousand inputs. The number is +encoded as a compactSize unsigned integer. + +.CompactSize Unsigned Integers +**** +Unsigned integers in Bitcoin that often have low values, but which may +sometimes have high values, are usually encoded using the compactSize +data type. CompactSize is a version of a variable-length integer, so +it's sometimes called var_int or varint (see, for example, documentation +for BIPs 37 and 144). + +[WARNING] ==== -+0100000001186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd73+ -+4d2804fe65fa35779000000008b483045022100884d142d86652a3f47+ -+ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039+ -+ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813+ -+01410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade84+ -+16ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc1+ -+7b4a10fa336a8d752adfffffffff02+*+60e31600000000001976a914ab6+* -*+8025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef800000000000+* -*+1976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac+* -+00000000+ +There are several different varieties of variable length integers used +in different programs, including in different Bitcoin programs. For +example, Bitcoin Core serializes its UTXO database using a data type it +calls +VarInts+ which is different from compactSize. Additionally, the +nBits field in a Bitcoin block header is encoded using a custom data +type known as +Compact+, which is unrelated to compactSize. When +talking about the variable length integers used in Bitcoin transaction +serialization and other parts of the Bitcoin P2P protocol, we will +always use the full name compactSize. ==== -Here are some hints: +For numbers from 0 to 252, compactSize unsigned integers are identical +to the C-language data type +uint8_t+, which is probably the native +encoding familiar to any programmer. For other numbers up to +0xffffffffffffffff, a byte is prefixed to the number to indicate its +length—but otherwise the numbers look like regular unsigned integers. -- There are two outputs in the highlighted section, each serialized as - shown in <>. +[cols="1,1,1"] +|=== +| Value | Bytes Used | Format +| >= 0 && \<= 252 (0xfc) | 1 | uint8_t +| >= 253 && \<= 0xffff | 3 | 0xfd followed by the number as uint16_t +| >= 0x10000 && \<= 0xffffffff | 5 | 0xfe followed by the number as uint32_t +| >= 0x100000000 && \<= 0xffffffffffffffff | 9 | 0xff followed by the number as uint64_t +|=== +**** -- The value of 0.015 bitcoin is 1,500,000 satoshis. That's +16 e3 60+ in - hexadecimal. +Each input in a transaction must contain three fields: -- 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+. +- An _outpoint_ field -- The +scriptPubKey+ length is 25 bytes, which is +19+ in hexadecimal. +- A length-prefixed _scriptSig_ field -[[tx_inputs]] -==== Transaction Inputs +- An _nSequence_ -((("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. +We'll look at each of those fields in the following sections. Some +inputs also include a witness, but this is serialized at the end of a +transaction and so we'll examine it later. -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. +[[outpoints]] +==== Outpoint -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. +A Bitcoin transaction is a request for full nodes to update their +database of coin ownership information. For Alice to transfer control +of some of her bitcoins to Bob, she first needs to tell full nodes how +to find the previous transfer where she received those bitcoins. Since +control over bitcoins is assigned in transaction outputs, Alice _points_ +to the previous _output_ using an _outpoint_ field. Each input must +contain a single outpoint. -Consider our example in <>. The -transaction inputs are an array (list) called +vin+: +The outpoint contains a 32-byte transaction identifier (_txid_) for the +transaction where Alice received the bitcoins she now wants to spend. +This txid is in Bitcoin's internal byte order for hashes, see +<>. -[[vin]] -.The transaction inputs in Alice's transaction -[source,json] ----- -"vin": [ - { - "txid": "7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18", - "vout": 0, - "scriptSig" : "3045022100884d142d86652a3f47ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813[ALL] 0484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade8416ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc17b4a10fa336a8d752adf", - "sequence": 4294967295 - } -] ----- +Because transactions may contain multiple outputs, Alice also needs to +identify which particular output from that transaction to use, called +its output vector (_vout_). Output vectors are four-byte unsigned +integers indexed from zero. -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: +When a full node encounters an outpoint, it uses that information to +try to find the referenced output. Full nodes only look at earlier +transactions in the blockchain. For example, Alice's transaction is +included in block 774,958. A full node verifying her transaction will +only look for the previous output referenced by her outpoint in that +block and previous blocks, not any later blocks. Within block 774,958, +they will only look at transactions placed in the block prior to Alice's +transaction, as determined by the order of leaves in the block's merkle +tree (see <>). -- A ((("transaction IDs (txd)")))transaction ID, referencing the - transaction that contains the UTXO being spent +Upon finding the previous output, the full node obtains several critical +pieces of information from it: -- An output index (+vout+), identifying which UTXO from that transaction - is referenced (first one is zero) +- The value of bitcoins assigned to that previous output. All of those + bitcoins will be transferred in this transaction. In the example + transaction, the value of the previous output was 100,000 satoshis. -- A +scriptSig+, which satisfies the conditions placed on the UTXO, - unlocking it for spending +- The authorization conditions for that previous output. These are the + conditions that must be fulfilled in order to spend the bitcoins + assigned to that previous output. -- A sequence number (to be discussed later) +- For confirmed transactions, the height of the block which confirmed it + and the Median Time Past (MTP) for that block. This is required for + relative timelocks (described in <>) and outputs + of coinbase transactions (described in <>). -In Alice's transaction, the input points to the transaction ID: +- Proof that the previous output exists in the blockchain (or as a known + unconfirmed transaction) and that no other transaction has spent it. + One of Bitcoin's consensus rules forbids any output from being spent + more than once within a valid blockchain. This is the rule against + _double spending_--Alice can't use the same previous output to pay + both Bob and Carol. Two transactions which each try to the spend the + same previous output are called _conflicting transactions_ because + only one of them can be included in a valid blockchain. + +Different approaches to tracking previous outputs have been tried by +different full node implementations at various times. Bitcoin Core +currently uses the solution believed to be most effective at retaining +all necessary information while minimizing disk space: it keeps a +database that stores every Unspent Transaction Output (UTXO) and +essential metadata about it (like its confirmation block height). Each +time a new block of transactions arrives, all of the outputs they spend +are removed from the UTXO database and all of the outputs they create +are added to the database. + +[[internal_and_display_order]] +.Internal and Display Byte Orders +**** +Bitcoin uses the output of hash functions, called _digests_, in various +ways. Digests provide unique identifiers for blocks and transactions; +they're used in commitments for addresses, blocks, transactions, +signatures, and more; and digests are iterated upon in Bitcoin's +proof-of-work function. In some cases, hash digests are displayed to +users in one byte order but are used internally in a different byte +order, creating confusion. For example, consider the previous output +txid from the outpoint in our example transaction: ---- -7957a35fe64f80d234d76d83a2a8f1a0d8149a41d81de548f0a65a8a999f6f18 +eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a ---- -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. +If we try using that that txid to retrieve that transaction using +Bitcoin Core, we get an error and must reverse its byte order: -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 <>). - -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" - } - ] +$ bitcoin-cli getrawtransaction \ + eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a +error code: -5 +error message: +No such mempool or blockchain transaction. Use gettransaction for wallet transactions. + +$ echo eb3ae38f27191aa5f3850dc9cad00492b88b72404f9da135698679268041c54a \ + | fold -w2 | tac | tr -d "\n" +4ac541802679866935a19d4f40728bb89204d0cac90d85f3a51a19278fe33aeb + +$ bitcoin-cli getrawtransaction \ + 4ac541802679866935a19d4f40728bb89204d0cac90d85f3a51a19278fe33aeb +02000000000101c25ae90c9f3d40cc1fc509ecfd54b06e35450702... ---- -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...". +This odd behavior is probably an unintentional consequence of a +https://bitcoin.stackexchange.com/questions/116730/why-does-bitcoin-core-print-sha256-hashes-uint256-bytes-in-reverse-order[design +decision in early Bitcoin software]. As a practical matter, it means +developers of Bitcoin software need to remember to reverse the order of +bytes in transaction and block identifiers that they show to users. -[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. -==== +In this book, we use the term _internal byte order_ for the data that +appears within transactions and blocks. We use _display byte order_ for +the form displayed to users. Another set of common terms is +_little-endian byte order_ for the internal version and _big-endian byte +order_ for the display version. +**** -===== Transaction serialization—inputs +==== ScriptSig -((("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 -<>. +The scriptSig field is a remnant of the legacy transaction format. Our +example transaction input spends a native segwit output which doesn't +require any data in the scriptSig, so the length prefix for the +scriptSig is set to zero (0x00). -[[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) -|======= +For an example of a length-prefixed scriptSig that spends a legacy +output, we use one from an arbitrary transaction in the most recent +block as of this writing: -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 - } -], +6b483045022100a6cc4e8cd0847951a71fad3bc9b14f24d44ba59d19094e0a8c +fa2580bb664b020220366060ea8203d766722ed0a02d1599b99d3c95b97dab8e +41d3e4d3fe33a5706201210369e03e2c91f0badec46c9c903d9e9edae67c167b +9ef9b550356ee791c9a40896 ---- -Now, let's see if we can identify these fields in the serialized hex -encoding in <>: +The length prefix is a compactSize unsigned integer indicating the +length of the serialized scriptSig field. In this case, it's a single +byte (0x6b) indicating the scriptSig is 107 bytes. We'll cover parsing +and using scripts in detail in the next chapter, +<>. -[[example_6_2]] -.Alice's transaction, serialized and presented in hexadecimal notation -==== -+0100000001+*+186f9f998a5aa6f048e51dd8419a14d8a0f1a8a2836dd73+* -*+4d2804fe65fa35779000000008b483045022100884d142d86652a3f47+* -*+ba4746ec719bbfbd040a570b1deccbb6498c75c4ae24cb02204b9f039+* -*+ff08df09cbe9f6addac960298cad530a863ea8f53982c09db8f6e3813+* -*+01410484ecc0d46f1918b30928fa0e4ed99f16a0fb4fde0735e7ade84+* -*+16ab9fe423cc5412336376789d172787ec3457eee41c04f4938de5cc1+* -*+7b4a10fa336a8d752adfffffffff+*+0260e31600000000001976a914ab6+ -+8025513c3dbd2f7b92a94e0581f5d50f654e788acd0ef800000000000+ -+1976a9147f9b1a7fb68d60c536c2fd8aeaa53a8f3cc025a888ac00000+ -+000+ -==== +==== nSequence -Hints: +The final four bytes of an input are its sequence number, called +_nSequence_. The use and meaning of this field has changed over time. -- The transaction ID is serialized in reversed byte order, so it starts - with (hex) +18+ and ends with +79+ +[[original_tx_replacement]] +===== Original nSequence-based Transaction Replacement -- The output index is a 4-byte group of zeros, easy to identify +The +nSequence+ field was originally intended to allow creation of +multiple versions of the same transaction, with later versions replacing +earlier versions as candidates for confirmation. The nSequence number +tracked the version of the transaction. -- The length of the +scriptSig+ is 139 bytes, or +8b+ in hex +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: -- The sequence number is set to +FFFFFFFF+, again easy to identify((("", - startref="alicesix"))) +- The first version of the transaction, with nSequenece 0 (0x00000000) + pays Alice and Bob back the money they initially deposited. This is + called a _refund transaction_. Neither of them broadcasts the refund + the transaction at this time. They only need it if there's a problem. -=== Bitcoin Addresses, Balances, and Other Abstractions +- Alice wins the first round of the card game, so the second version of + the transaction, with nSequence 1, increases the amount of money paid + to Alice and decreases Bob's share. The both sign the updated + transaction. Again, they don't need to broadcast this version of the + transaction unless there's a problem. -((("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. +- Bob wins the second round, so the nSequence is incremented to 2, + Alice's share is decreased, and Bob's share is increased. They again + sign but don't broadcast. -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. +- After many more rounds where the nSequence is incremented, the + funds redistributed, and the resulting transaction is signed but not + broadcast, they decide to finalize the transaction. Creating a + transaction with the final balance of funds, they set nSequence to its + maximum value (0xffffffff), finalizing the transaction. They broadcast + this version of the transaction, it's relayed across the network, and + eventually confirmed by miners. -Let's look again at how Alice's transaction was presented on a popular -block explorer (<>). +We can see the replacement rules for nSequence at work if we consider +alternative scenarios: -[[alice_transaction_to_bobs_cafe]] -.Alice's transaction to Bob's Cafe -image::images/mbc2_0208.png["Alice Coffee Transaction"] +- Imagine that Alice broadcasts the final transaction, with an nSequence of + 0xffffffff, and then Bob broadcasts one of the earlier transactions + where his balance was higher. Because Bob's version of the + transaction has a lower sequence number, full nodes using the original + Bitcoin code won't relay it to miners, and miners who also used the + original code won't mine it. -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. +- In another scenario, imagine that Bob broadcasts an earlier version of + the transaction a few seconds before Alice broadcasts the final + version. Nodes will relay Bob's version and miners will attempt to + mine it, but when Alice's version with its higher nSequence number + arrives, nodes will also relay it and miners using the original + Bitcoin code will try to mine it instead of Bob's version. Unless Bob + got lucky and a block was discovered before Alice's version arrived, + it's Alice's version of the transaction that will get confirmed. -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. +This type of protocol is what we now call a _payment channel_. +Bitcoin's creator, in an email attributed to him, described these as +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. -If you were to click on Bob's Bitcoin address, the blockchain explorer -would show you the view in <>. +There were a few problems with purely nSequence-based payment channels. +The first was that the rules for replacing a lower-sequence transaction +with a higher-sequence transaction were only a matter of software +policy. There was no direct incentive for miners to prefer one version +of the transaction over any other. The second problem was that the +first person to send their transaction might get lucky and have it +confirmed even if it wasn't the highest-sequence transaction. A +security protocol that fails a few percent of the time due to bad luck +isn't a very effective protocol. -[[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 third problem was that it was possible to replace one version of a +transaction with a different version an unlimited number of +times. Each replacement would consume the bandwidth of all the relaying full nodes +on the network. For example, as of this writing there are about 50,000 +relaying full nodes; an attacker creating 1,000 replacement transactions +per minute at 200 bytes each would use about 20 kilobytes of their +personal bandwidth but about 10 gigabytes of full node network bandwidth +every minute. Except for the cost of their 20 KB/minute bandwidth and +the occasional fee when a transaction got confirmed, the attacker wouldn't +need to pay any costs for the enormous burden they placed on full node +operators. -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 eliminate the risk of this attack, the original type of +nSequence-based transaction replacement was disabled in an early version +of the Bitcoin software. For several years, Bitcoin full nodes would +not allow an unconfirmed transaction containing a particular input (as +indicated by its outpoint) to be replaced by a different transaction +containing the same input. However, that situation didn't last forever. -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. +[[nsequence-bip125]] +===== Opt-in Transaction Replacement Signaling -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. +After the original nSequence-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 +objected to adding support for transaction replacement back into Bitcoin +Core, so a compromise was reached that once again used the nSequence +field in support of replacement. -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. +As documented in BIP125, an unconfirmed transaction with any input that +has an nSequence 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 +continued to disallow other transactions from being replaced. This +allowed users and businesses that objected to replacement to simply +ignore unconfirmed transactions containing the BIP125 signal until they +became confirmed. -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"))) - - -=== Timelocks - -((("transactions", "advanced", "timelocks")))((("scripting", -"timelocks", id="Stimelock07")))((("nLocktime field")))((("scripting", -"timelocks", "uses for")))((("timelocks", "uses for")))Timelocks are -restrictions on transactions or outputs that only allow spending after a -point in time. Bitcoin has had a transaction-level timelock feature from -the beginning. It is implemented by the +nLocktime+ field in a -transaction. Two new timelock features were introduced in late 2015 and -mid-2016 that offer UTXO-level timelocks. These are -+CHECKLOCKTIMEVERIFY+ and +CHECKSEQUENCEVERIFY+. - -Timelocks are useful for postdating transactions and locking funds to a -date in the future. More importantly, timelocks extend bitcoin scripting -into the dimension of time, opening the door for complex multistep smart -contracts. - -[[transaction_locktime_nlocktime]] -==== Transaction Locktime (nLocktime) - -((("scripting", "timelocks", "nLocktime")))((("timelocks", -"nLocktime")))From the beginning, Bitcoin has had a transaction-level -timelock feature. Transaction locktime is a transaction-level setting (a -field in the transaction data structure) that defines the earliest time -that a transaction is valid and can be relayed on the network or added -to the blockchain. Locktime is also known as +nLocktime+ from the -variable name used in the Bitcoin Core codebase. It is set to zero in -most transactions to indicate immediate propagation and execution. If -+nLocktime+ is nonzero and below 500 million, it is interpreted as a -block height, meaning the transaction is not valid and is not relayed or -included in the blockchain prior to the specified block height. If it is -above 500 million, it is interpreted as a Unix Epoch timestamp (seconds -since Jan-1-1970) and the transaction is not valid prior to the -specified time. Transactions with +nLocktime+ specifying a future block -or time must be held by the originating system and transmitted to the -Bitcoin network only after they become valid. If a transaction is -transmitted to the network before the specified +nLocktime+, the -transaction will be rejected by the first node as invalid and will not -be relayed to other nodes. The use of +nLocktime+ is equivalent to -postdating a paper check. - -[[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. - -((("use cases", "buying coffee", id="alicesseven")))Alice signs a -transaction spending one of her outputs to Bob's address, and sets the -transaction +nLocktime+ to 3 months in the future. Alice sends that -transaction to Bob to hold. With this transaction Alice and Bob know -that: - -- Bob cannot transmit the transaction to redeem the funds until 3 months - have elapsed. - -- Bob may transmit the transaction after 3 months. - -However: - -- Alice can create another transaction, double-spending the same inputs - without a locktime. 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 -+nLocktime+. The only guarantee is that Bob will not be able to redeem -it before 3 months have elapsed. There is no guarantee that Bob will get -the funds. To achieve such a guarantee, the timelock restriction must be -placed on the UTXO itself and be part of the locking script, rather than -on the transaction. This is achieved by the next form of timelock, -called Check Lock Time Verify. - -==== Relative Timelocks with nSequence - -((("nSequence field")))((("scripting", "timelocks", "relative timelocks -with nSequence")))Relative timelocks can be set on each input of a -transaction, by setting the +nSequence+ field in each input. - -===== Original meaning of nSequence - -The +nSequence+ field was originally intended (but never properly -implemented) to allow modification of transactions in the mempool. In -that use, a transaction containing inputs with +nSequence+ value below -2^32^ - 1 (0xFFFFFFFF) indicated a transaction that was not yet -"finalized." Such a transaction would be held in the mempool until it -was replaced by another transaction spending the same inputs with a -higher +nSequence+ value. Once a transaction was received whose inputs -had an +nSequence+ value of 0xFFFFFFFF it would be considered -"finalized" and mined. - -The original meaning of +nSequence+ was never properly implemented and -the value of +nSequence+ is customarily set to 0xFFFFFFFF in -transactions that do not utilize timelocks. For transactions with -nLocktime or +CHECKLOCKTIMEVERIFY+, the +nSequence+ value must be set to -less than 2^31^ for the timelock guards to have an effect, as explained -below. +There's more to modern transaction replacement policies than fee rates +and nSequence signals, which we'll see in <>. +[[relative_timelocks]] ===== nSequence as a consensus-enforced relative timelock -Since the activation of BIP-68, new consensus rules apply for any -transaction containing an input whose +nSequence+ value is less than -2^31^ (bit 1<<31 is not set). Programmatically, that means that if the -most significant (bit 1<<31) is not set, it is a flag that means -"relative locktime." Otherwise (bit 1<<31 set), the +nSequence+ value is -reserved for other uses such as enabling +CHECKLOCKTIMEVERIFY+, -+nLocktime+, Opt-In-Replace-By-Fee, and other future developments. +In the <> section, we learned that the BIP68 soft fork added +a new constraint to transactions with version numbers 2 or higher. That +constraint applies to the nSequence field. Transaction inputs with +nSequence+ values less than 2^31^ are -interpreted as having a relative timelock. Such a transaction is only -valid once the input has aged by the relative timelock amount. For -example, a transaction with one input with an +nSequence+ relative -timelock of 30 blocks is only valid when at least 30 blocks have elapsed -from the time the UTXO referenced in the input was mined. Since -+nSequence+ is a per-input field, a transaction may contain any number -of timelocked inputs, all of which must have sufficiently aged for the -transaction to be valid. A transaction can include both timelocked -inputs (+nSequence+ < 2^31^) and inputs without a relative timelock -(+nSequence+ >= 2^31^). +interpreted as having a relative timelock. Such a transaction may only +be included in the blockchain once the previous output (referenced by the +outpoint) has aged by the relative timelock amount. For example, a +transaction with one input with a relative timelock of 30 blocks can +only be confirmed after least 30 blocks have elapsed from the time the +previous output was confirmed in a block on the current blockchain. +Since +nSequence+ is a per-input field, a transaction may contain any +number of timelocked inputs, all of which must have sufficiently aged +for the transaction to be valid. A transaction can include both +timelocked inputs (+nSequence+ < 2^31^) and inputs without a relative +timelock (+nSequence+ >= 2^31^). -The +nSequence+ value is specified in either blocks or seconds, but in a -slightly different format than we saw used in +nLocktime+. A type-flag +The +nSequence+ value is specified in either blocks or seconds. +A type-flag is used to differentiate between values counting blocks and values counting time in seconds. The type-flag is set in the 23rd least-significant bit (i.e., value 1<<22). If the type-flag is set, then @@ -754,331 +514,649 @@ the +nSequence+ value is interpreted as a multiple of 512 seconds. If the type-flag is not set, the +nSequence+ value is interpreted as a number of blocks. + When interpreting +nSequence+ as a relative timelock, only the 16 least significant bits are considered. Once the flags (bits 32 and 23) are evaluated, the +nSequence+ value is usually "masked" with a 16-bit mask -(e.g., +nSequence+ & 0x0000FFFF). +(e.g., +nSequence+ & 0x0000FFFF). The multiple of 512 seconds is +roughly equal to the average amount of time between blocks, so the +maximum relative timelock in both blocks and seconds from 16 bits +(2^16^) is about one year. <> shows the binary layout of the +nSequence+ value, -as defined by BIP-68. +as defined by BIP68. [[bip_68_def_of_nseq]] -.BIP-68 definition of nSequence encoding (Source: BIP-68) -image::images/mbc2_0701.png["BIP-68 definition of nSequence encoding"] +.BIP68 definition of nSequence encoding (Source: BIP68) +image::../images/mbc2_0701.png["BIP68 definition of nSequence encoding"] -Relative timelocks based on consensus enforcement of the +nSequence+ -value are defined in BIP-68. +Note that any transaction which sets a relative timelock using nSequence +also sends the signal for opt-in replace-by-fee as described in +<>. -The standard is defined in -https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP-68, -Relative lock-time using consensus-enforced sequence numbers]. +=== Outputs -[[segwit]] -=== Segregated Witness +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 +transaction where Alice pays Bob, displayed as +a map of those bytes in <>. -((("segwit (Segregated Witness)", id="Ssegwit07")))Segregated Witness -(segwit) is an upgrade to the bitcoin consensus rules and network -protocol, proposed and implemented as a BIP-9 soft-fork that was -activated on bitcoin's mainnet on August 1st, 2017. +[[output-byte-map]] +.A byte map of the outputs field from Alice's transaction +image::../images/output-byte-map.png["A byte map of the outputs field from Alice's transaction"] -In cryptography, the term "witness" is used to describe a solution to a -cryptographic puzzle. In bitcoin terms, the witness satisfies a -cryptographic condition placed on a unspent transaction output (UTXO). +==== Outputs Count -In the context of bitcoin, a digital signature is _one type of witness_, -but a witness is more broadly any solution that can satisfy the -conditions imposed on an UTXO and unlock that UTXO for spending. The -term “witness” is a more general term for an “unlocking script” or -“scriptSig.” +Identical to the start of the input section of transaction, the output +field begins with a count indicating the number of outputs in this +transaction. It's a compactSize integer and must be greater than zero. -Before segwit’s introduction, every input in a transaction was followed -by the witness data that unlocked it. The witness data was embedded in -the transaction as part of each input. The term _segregated witness_, or -_segwit_ for short, simply means separating the signature or unlocking -script of a specific output. Think "separate scriptSig," or “separate -signature” in the simplest form. +The example transaction has two outputs. -Segregated Witness therefore is an architectural change to bitcoin that -aims to move the witness data from the +scriptSig+ (unlocking script) -field of a transaction into a separate _witness_ data structure that -accompanies a transaction. Clients may request transaction data with or -without the accompanying witness data. +==== nValue -In this section we will look at some of the benefits of Segregated -Witness, describe the mechanism used to deploy and implement this -architecture change, and demonstrate the use of Segregated Witness in -transactions and addresses. +The first field of a specific output is its value, also called +_nValue_ in Bitcoin Core. This is an eight-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. -Segregated Witness is defined by the following BIPs: +Bitcoin's consensus rules allow an output to have a value as small as +zero and as large as 21 million bitcoins (2.1 quadrillion satoshis). -https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki[BIP-141] :: The main definition of Segregated Witness. +//TODO:describe early integer overflow problem -https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki[BIP-143] :: Transaction Signature Verification for Version 0 Witness Program +[[uneconomical_outputs]] +===== Uneconomical Outputs and Disallowed Dust -https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki[BIP-144] :: Peer Services—New network messages and serialization formats +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 +it as the input in a transaction) increases the size of a transaction, +which increases the amount of fee that needs to be paid. If the value +of the output is less than the cost of the additional fee, then it doesn't +make economic sense to spend the output. Such outputs are known as +_uneconomical outputs_. -https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki[BIP-145] :: getblocktemplate Updates for Segregated Witness (for mining) +A zero-value output is always an uneconomical output; it wouldn't +contribute any value to a transaction spending it even if the +transaction's fee rate was zero. However, many other outputs with low +values can be uneconomical as well, even unintentionally. For example, +at the feerates prevelant on the network today, an output might add more +value to a transaction than it costs to spend--but, tomorrow, feerates +might rise and make the output uneconomical. -https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki[BIP-173]:: Base32 address format for native v0-16 witness outputs +The need for full nodes to keep track of all unspent transaction outputs +(UTXOs), as described in <>, means that every UTXO makes it +slightly harder to run a full node. For UTXOs containing significant +value, there's an incentive to eventually spend them, so they aren't a +problem. But there's no incentive for the person controlling an +uneconomical UTXO to ever spend it, potentially making it a perpetual +burden on operators of full nodes. Because Bitcoin's decentralization +depends on many people being willing to run full nodes, several full +node implementations such as Bitcoin Core discourage the creation of +uneconomical outputs using policies for the relay and mining of +unconfirmed transactions. -==== Why Segregated Witness? - -Segregated Witness is an architectural change that has several effects -on the scalability, security, economic incentives, and performance of -bitcoin: - -Transaction Malleability :: By moving the witness outside the -transaction, the transaction hash used as an identifier no longer -includes the witness data. Since the witness data is the only part of -the transaction that can be modified by a third party (see -<>), removing it also removes the opportunity for -transaction malleability attacks. With Segregated Witness, transaction -hashes become immutable by anyone other than the creator of the -transaction, which greatly improves the implementation of many other -protocols that rely on advanced bitcoin transaction construction, such -as payment channels, chained transactions, and lightning networks. - -Script Versioning :: With the introduction of Segregated Witness -scripts, every locking script is preceded by a _script version_ number, -similar to how transactions and blocks have version numbers. The -addition of a script version number allows the scripting language to be -upgraded in a backward-compatible way (i.e., using soft fork upgrades) -to introduce new script operands, syntax, or semantics. The ability to -upgrade the scripting language in a nondisruptive way will greatly -accelerate the rate of innovation in bitcoin. - -Network and Storage Scaling :: The witness data is often a big -contributor to the total size of a transaction. More complex scripts -such as those used for multisig or payment channels are very large. In -some cases these scripts account for the majority (more than 75%) of the -data in a transaction. By moving the witness data outside the -transaction, Segregated Witness improves bitcoin’s scalability. Nodes -can prune the witness data after validating the signatures, or ignore it -altogether when doing simplified payment verification. The witness data -doesn’t need to be transmitted to all nodes and does not need to be -stored on disk by all nodes. - -Signature Verification Optimization :: Segregated Witness upgrades the -signature functions (+CHECKSIG+, +CHECKMULTISIG+, etc.) to reduce the -algorithm's computational complexity. Before segwit, the algorithm used -to produce a signature required a number of hash operations that was -proportional to the size of the transaction. Data-hashing computations -increased in O(n^2^) with respect to the number of signature operations, -introducing a substantial computational burden on all nodes verifying -the signature. With segwit, the algorithm is changed to reduce the -complexity to O(n). - -Offline Signing Improvement :: Segregated Witness signatures incorporate -the value (amount) referenced by each input in the hash that is signed. -Previously, an offline signing device, such as a hardware wallet, would -have to verify the amount of each input before signing a transaction. -This was usually accomplished by streaming a large amount of data about -the previous transactions referenced as inputs. Since the amount is now -part of the commitment hash that is signed, an offline device does not -need the previous transactions. If the amounts do not match (are -misrepresented by a compromised online system), the signature will be -invalid. - -==== How Segregated Witness Works - -At first glance, Segregated Witness appears to be a change to how -transactions are constructed and therefore a transaction-level feature, -but it is not. Rather, Segregated Witness is a change to how individual -UTXO are spent and therefore is a per-output feature. - -A transaction can spend Segregated Witness outputs or traditional -(inline-witness) outputs or both. Therefore, it does not make much sense -to refer to a transaction as a “Segregated Witness transaction.” Rather -we should refer to specific transaction outputs as “Segregated Witness -outputs." - -When a transaction spends an UTXO, it must provide a witness. In a -traditional UTXO, the locking script requires that witness data be -provided _inline_ in the input part of the transaction that spends the -UTXO. A Segregated Witness UTXO, however, specifies a locking script -that can be satisfied with witness data outside of the input -(segregated). - -==== Soft Fork (Backward Compatibility) - -Segregated Witness is a significant change to the way outputs and -transactions are architected. Such a change would normally require a -simultaneous change in every Bitcoin node and wallet to change the -consensus rules—what is known as a hard fork. Instead, segregated -witness is introduced with a much less disruptive change, which is -backward compatible, known as a soft fork. This type of upgrade allows -nonupgraded software to ignore the changes and continue to operate -without any disruption. - -Segregated Witness outputs are constructed so that older systems that -are not segwit-aware can still validate them. To an old wallet or node, -a Segregated Witness output looks like an output that _anyone can -spend_. Such outputs can be spent with an empty signature, therefore the -fact that there is no signature inside the transaction (it is -segregated) does not invalidate the transaction. Newer wallets and -mining nodes, however, see the Segregated Witness output and expect to -find a valid witness for it in the transaction’s witness data. - -[[segwit_txid]] -===== Transaction identifiers - -((("transaction IDs (txid)")))One of the greatest benefits of Segregated -Witness is that it eliminates third-party transaction malleability. - -Before segwit, transactions could have their signatures subtly modified -by third parties, changing their transaction ID (hash) without changing -any fundamental properties (inputs, outputs, amounts). This created -opportunities for denial-of-service attacks as well as attacks against -poorly written wallet software that assumed unconfirmed transaction -hashes were immutable. - -With the introduction of Segregated Witness, transactions have two -identifiers, +txid+ and +wtxid+. The traditional transaction ID +txid+ -is the double-SHA256 hash of the serialized transaction, without the -witness data. A transaction +wtxid+ is the double-SHA256 hash of the new -serialization format of the transaction with witness data. - -The traditional +txid+ is calculated in exactly the same way as with a -nonsegwit transaction. However, since the segwit transaction has empty -++scriptSig++s in every input, there is no part of the transaction that -can be modified by a third party. Therefore, in a segwit transaction, -the +txid+ is immutable by a third party, even when the transaction is -unconfirmed. - -The +wtxid+ is like an "extended" ID, in that the hash also incorporates -the witness data. If a transaction is transmitted without witness data, -then the +wtxid+ and +txid+ are identical. Note than since the +wtxid+ -includes witness data (signatures) and since witness data may be -malleable, the +wtxid+ should be considered malleable until the -transaction is confirmed. Only the +txid+ of a segwit transaction can be -considered immutable by third parties and only if _all_ the inputs of -the transaction are segwit inputs. +The policies against relaying or mining transactions creating new +uneconomical outputs are called _dust_ policies, based on a metaphorical +comparison between outputs with very small values and particles with +very small size. Bitcoin Core's dust policy is complicated and contains +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 +check whether the policy has changed since publication of this book. [TIP] ==== -Segregated Witness transactions have two IDs: +txid+ and +wtxid+. The -+txid+ is the hash of the transaction without the witness data and the -+wtxid+ is the hash inclusive of witness data. The +txid+ of a -transaction where all inputs are segwit inputs is not susceptible to -third-party transaction malleability. +Since Bitcoin's inception, every full node has needed to keep a copy of +every unspent transaction output (UTXO), but that might not always be +the case. Several developers have been working on Utreexo, a project +that allows full nodes to store a commitment to the set of UTXOs rather +than the data itself. A minimal commitment might be only a kilobyte or +two in size--compare that to the over five gigabytes Bitcoin Core stores +as of this writing. + +However, Utreexo will still require some nodes to store all UTXO data, +especially nodes serving miners and other operations that need to +quickly validate new blocks. That means uneconomical outputs can still +be a problem for full nodes even in a possible future where most nodes +use Utreexo. ==== -==== Economic Incentives for Segregated Witness +Bitcoin Core's policy rules about dust do have one exception: output +scriptPubKeys starting with +OP_RETURN+, called _data carrier outputs_, +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 +amounts of arbitrary data in the blockchain without increasing the size +of its UTXO database. Since the outputs are unspendable, they aren't +uneconomical--any satoshis in nValue assigned to them becomes +permanently unspendable--so allowing the nValue to be zero ensures +satoshis aren't being destroyed. -Bitcoin mining nodes and full nodes incur costs for the resources used -to support the Bitcoin network and the blockchain. As the volume of -bitcoin transactions increases, so does the cost of resources (CPU, -network bandwidth, disk space, memory). Miners are compensated for these -costs through fees that are proportional to the size (in bytes) of each -transaction. Nonmining full nodes are not compensated, so they incur -these costs because they have a need to run an authoritative fully -validating full-index node, perhaps because they use the node to operate -a bitcoin business. +==== ScriptPubKey -Without transaction fees, the growth in bitcoin data would arguably -increase dramatically. Fees are intended to align the needs of bitcoin -users with the burden their transactions impose on the network, through -a market-based price discovery mechanism. +The output amount is followed by a compactSize integer indicating the +length of the output's _scriptPubKey_, the script that contains the +conditions which will need to be fulfilled in order to spend the +bitcoins, the _spending authorization_. According to Bitcoin's +consensus rules, the minimum size of a scriptPubKey is zero. -The calculation of fees based on transaction size treats all the data in -the transaction as equal in cost. But from the perspective of full nodes -and miners, some parts of a transaction carry much higher costs. Every -transaction added to the Bitcoin network affects the consumption of four -resources on nodes: +The consensus maximum allowed size of a scriptPubKey varies depending on +when it's being checked. There's no explicit limit on the size of a +scriptPubKey in the output of a transaction, but a later transaction can +only spend a previous output with a scriptPubKey of 10,000 bytes or +smaller. Implicitly, a scriptPubKey can be almost as large as the +transaction containing it, and a transaction can be almost as large as +the block containing it. -Disk Space :: Every transaction is stored in the blockchain, adding to -the total size of the blockchain. The blockchain is stored on disk, but -the storage can be optimized by “pruning” older transactions. +[[anyone-can-spend]] +[TIP] +==== +A scriptPubKey with zero length can be spent by a scriptSig containing +OP_TRUE. Anyone can create that scriptSig, which means anyone +can spend an empty scriptPubKey. There are an essentially unlimited +number of scripts which 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 +conditions. Application developers should never need to use an +anyone-can-spend script, but if you do, we highly recommend that you +loudly announce your plans to Bitcoin users and developers so that +future upgrades don't accidentally interfere with your system. +==== -CPU :: Every transaction must be validated, which requires CPU time. +Bitcoin Core's policy for relaying and mining transactions effectively +limits scriptPubKeys to just a few templates, called _standard +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 v1 witness scripts, and +segwit v2 (taproot) tapscripts. -Bandwidth :: Every transaction is transmitted (through flood -propagation) across the network at least once. Without any optimization -in the block propagation protocol, transactions are transmitted again as -part of a block, doubling the impact on network capacity. +We'll look at each of the current standard transaction templates and +learn how to parse scripts in <>. -Memory :: Nodes that validate transactions keep the UTXO index or the -entire UTXO set in memory to speed up validation. Because memory is at -least one order of magnitude more expensive than disk, growth of the -UTXO set contributes disproportionately to the cost of running a node. +[[witnesses]] +=== Witnesses -As you can see from the list, not every part of a transaction has an -equal impact on the cost of running a node or on the ability of bitcoin -to scale to support more transactions. The most expensive part of a -transaction are the newly created outputs, as they are added to the -in-memory UTXO set. By comparison, signatures (aka witness data) add the -least burden to the network and the cost of running a node, because -witness data are only validated once and then never used again. -Furthermore, immediately after receiving a new transaction and -validating witness data, nodes can discard that witness data. If fees -are calculated on transaction size, without discriminating between these -two types of data, then the market incentives of fees are not aligned -with the actual costs imposed by a transaction. In fact, the current fee -structure actually encourages the opposite behavior, because witness -data is the largest part of a transaction. +In court, a witness is someone who testifies that they saw something +important happen. Human witnesses aren't always reliable, so courts +have various processes for interrogating witnesses to (ideally) only +accept evidence from those who are reliable. -The incentives created by fees matter because they affect the behavior -of wallets. All wallets must implement some strategy for assembling -transactions that takes into consideration a number of factors, such as -privacy (reducing address reuse), fragmentation (making lots of loose -change), and fees. If the fees are overwhelmingly motivating wallets to -use as few inputs as possible in transactions, this can lead to UTXO -picking and change address strategies that inadvertently bloat the UTXO -set. +Imagine what a witness would look like for a math problem. For example, +if the important problem was _x + 2 = 4_ and someone claimed they +witnessed the solution, what would we ask them? We'd want a +mathematical proof that showed a value which could be summed with two to +equal four. We could even omit the need for a person and just use the +proposed value for _x_ as our witness. If we were told that the witness +was _two_, then we could fill in the equation, check that it was correct, and +decide that the important problem had been solved. -Transactions consume UTXO in their inputs and create new UTXO with their -outputs. A transaction, therefore, that has more inputs than outputs -will result in a decrease in the UTXO set, whereas a transaction that -has more outputs than inputs will result in an increase in the UTXO set. -Let’s consider the _difference_ between inputs and outputs and call that -the “Net-new-UTXO.” That’s an important metric, as it tells us what -impact a transaction will have on the most expensive network-wide -resource, the in-memory UTXO set. A transaction with positive -Net-new-UTXO adds to that burden. A transaction with a negative -Net-new-UTXO reduces the burden. We would therefore want to encourage -transactions that are either negative Net-new-UTXO or neutral with zero -Net-new-UTXO. +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 +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 +protected by the following script: -Let’s look at an example of what incentives are created by the -transaction fee calculation, with and without Segregated Witness. We -will look at two different transactions. Transaction A is a 3-input, -2-output transaction, which has a Net-new-UTXO metric of –1, -meaning it consumes one more UTXO than it creates, reducing the UTXO set -by one. Transaction B is a 2-input, 3-output transaction, which has a -Net-new-UTXO metric of 1, meaning it adds one UTXO to the UTXO set, -imposing additional cost on the entire Bitcoin network. Both -transactions use multisignature (2-of-3) scripts to demonstrate how -complex scripts increase the impact of segregated witness on fees. Let’s -assume a transaction fee of 30 satoshi per byte and a 75% fee discount -on witness data: +---- +2 OP_ADD 4 OP_EQUAL +---- -++++ -
-
Without Segregated Witness
-
-

Transaction A fee: 25,710 satoshi

-

Transaction B fee: 18,990 satoshi

-
+Obviously, allowing your bitcoins to be spent by anyone who can solve a +simple equation wouldn't be secure. As we'll see in <>, an +unforgable digital signature scheme uses an equation that can only be +solved by someone in possession of certain data which they're able to +keep secret. They're able to reference that secret data using a public +identifier. That public identifier is called a _public key_ and a +solution to the equation is called a _signature_. -
With Segregated Witness
-
-

Transaction A fee: 8,130 satoshi

-

Transaction B fee: 12,045 satoshi

-
-
-++++ +The following script contains a public key and an opcode which requires +a corresponding signature commit to the data in spending transaction. Like +the number _2_ in our simple example, the signature is our witness. -Both transactions are less expensive when segregated witness is -implemented. But comparing the costs between the two transactions, we -see that before Segregated Witness, the fee is higher for the -transaction that has a negative Net-new-UTXO. After Segregated Witness, -the transaction fees align with the incentive to minimize new UTXO -creation by not inadvertently penalizing transactions with many inputs. +---- + OP_CHECKSIG +---- -Segregated Witness therefore has two main effects on the fees paid by -Bitcoin users. Firstly, segwit reduces the overall cost of transactions -by discounting witness data and increasing the capacity of the Bitcoin -blockchain. Secondly, segwit’s discount on witness data corrects a -misalignment of incentives that may have inadvertently created more -bloat in the UTXO set.((("", startref="Tadv07")))((("", -startref="Ssegwit07"))) +Witnesses, the values used to solve the math problems that protect +bitcoins, need to be included in the transactions where they're used in +order for full nodes to verify them. In the legacy transaction format +used for all early Bitcoin transactions, signatures and other data are +placed in the scriptSig field. However, when developers started to +implement contract protocols on Bitcoin, such as we saw in +<>, they discovered several significant +problems with placing witnesses in the scriptSig field. + +==== Circular Dependencies + +Many contract protocols for Bitcoin involve a series of transactions +which 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. + +- Tx~0~ pays money from Alice and money from Bob into an output with a + scriptPubKey that requries 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) + +- 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 + doesn't require either of them trust the other, making it a _trustless + protocol_. + +A problem with this construction in the legacy transaction format is +that every field, including the scriptSig field which contains +signatures, is used to build 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 +signatures for Tx~0~ are known--but if they know the signatures for +Tx~0~, one of them can broadcast that transaction before signing the +refund transaction, eliminating the guarantee of a refund. This is a +_circular dependency_. + +==== Third-Party Transaction Malleability + +A more complex series of transactions can sometimes eliminate a circular +dependency, but many protocols will then encounter a new concern: it's +often possible to solve the same script in different ways. For example, +consider our simple script from <>: + +---- +2 OP_ADD 4 OP_EQUAL +---- + +We can make this script pass by providing the value _2_ in a scriptSig, +but there are several ways to put that value on the stack in Bitcoin. +Here are just a few: + +---- +OP_2 +OP_PUSH1 0x02 +OP_PUSH2 0x0002 +OP_PUSH3 0x000002 +... +OP_PUSHDATA1 0x0102 +OP_PUSHDATA1 0x020002 +... +OP_PUSHDATA2 0x000102 +OP_PUSHDATA2 0x00020002 +... +OP_PUSHDATA4 0x0000000102 +OP_PUSHDATA4 0x000000020002 +... +---- + +Each alternative encoding of the number _2_ in a scriptSig will produce +a slightly different transaction with a completely different txid. Each +different version of the transaction spends the same inputs (outpoints) +as every other version of the transaction, making them all _conflict_ +with each other. Only one version of a set of conflicting transactions +can be contained within a valid blockchain. + +Imagine Alice creates one version of the transaction with +OP_2+ in the +scriptSig and an output that pays Bob. Bob then immediately spends that +output to Carol. Anyone on the network can replace +OP_2+ with ++OP_PUSH1 0x02+, creating a conflict with Alice's original version. If +that conflicting transaction is confirmed, then there's no way to +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 problem called _unwanted third-party transaction +malleability_. + +[TIP] +==== +There are cases when people want their transactions to be malleable and +Bitcoin provides several features to support that, most notably the +signature hashes (sighash) we'll learn about in <>. For +example, Alice can use a sighash to allow Bob to help her pay some +transaction fees. This mutates Alice's transaction but only in a way +that Alice wants. For that reason, we will occasionally prefix the +word _unwanted_ to the term _transaction malleability_. Even when we +and other Bitcoin technical writers use the base term, we're almost +certainly talking about the unwanted variant of malleability. +==== + +==== Second-Party Transaction Malleability + +When the legacy transaction format was the only transaction format, +developers worked on proposals to minimize third-party malleability, +such as BIP62. However, even if they were able to entirely eliminate +third-party malleability, users of contract protocols faced another problem: +if they required a signature from someone else involved in the protocol, +that person could generate alternative signatures and so change the txid. + +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 the 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. + +- 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~. + +- 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~. + +There's no circular dependency here and, if we ignore third-party +transaction malleability, this looks like it should provide us with a +trustless protocol. However, it's a property of Bitcoin signatures that +the signer has to choose a large random number when creating their +signature. Choosing a different random number will produce a different +signature even if everything being signed stays the same. It's sort of +like how, if you provide a handwritten signature for two copies of the +same contract, each of those physical signatures will look slightly +different. + +This mutability of signatures means that, if Alice tries to broadcast +Tx~0~ (which contains Bob's signature), Bob can generate an alternative +signature to create a conflicting transaction with a different txid. If +Bob's alternative version of Tx~0~ gets confirmed, then Alice can't use +the presigned version of Tx~1~ to claim her refund. This type of +mutation is called _unwanted second-party transaction malleability_. + +[[segwit]] +==== Segregated Witness + +As early as https://bitcointalk.org/index.php?topic=40627.msg494697[2011], +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 scriptSig in the calculation that +produces a transaction's txid. Recall that an abstract name for the data +held by a scriptSig 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). + +The obvious method for implementing segwit requires a +backwards-incompatible change to Bitcoin's consensus rules, also called +a _hard fork_. Hard forks come with a lot of challenges, as we'll +discuss further in <>. + +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 +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 +the ability to enforce new consensus rules (but only if the newer full +nodes represent the economic consensus among Bitcoin users--we'll +explore the details of upgrading Bitcoin's consensus rules in +<>). + +The soft fork segwit approach is based on anyone-can-spend +scriptPubKeys. A script which starts with any of the numbers 0 to 16 +and followed by 2 to 40 bytes of data is defined as a segwit +scriptPubKey template. The number indicates its version (e.g. 0 is +segwit version 0, or _segwit v0_). The data is called a _native witness +program_. It's also possible to wrap the segwit template in a P2SH +commitment, called a _P2SH witness program_, but we won't deal with that +here. + +From the perspective of old nodes, these scriptPubKey templates can be +spent with an empty scriptSig. From the perspective of a new node which +is aware of the new segwit rules, any payment to a segwit scriptPubKey +template must only be spent with an empty scriptSig. Notice the +difference here: old nodes _allow_ an empty scriptSig; new nodes +_require_ an empty scriptSig. + +An empty scriptSig keeps witnesses from affecting the txid, eliminating +circular dependencies, third-party transaction malleability, and +second-party transaction malleability. But, with no ability to put +data in a scriptSig, users of segwit scriptPubKey templates need a +new field. That field is called is called the _witness_. + +The introduction of witnesses and witness programs complicates Bitcoin, +but it follows an existing trend of increasing abstraction. Recall from +<> that the original Bitcoin whitepaper describes a system +where bitcoins were received to public keys (pubkeys) and spent with +signatures (sigs). The public key defined who was _authorized_ to spend +the bitcoins (whoever controlled the corresponding private key) and the +signature provided _authentication_ that the spending transaction came +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 scriptPubKeys and spent with scriptSigs. +Later experience with contract protocols inspired allowing bitcoins to +be received to witness programs and spent with witnesses. + +[cols="1,1,1"] +|=== +| | **Authorization** | **Authentication** +| **Whitepaper** | Public key | Signature +| **Original (Legacy)** | scriptPubKey | scriptSig +| **Segwit** | Witness program | Witness +|=== + +==== Witness Serialization + +Similar to the inputs and outputs fields, the witness field contains +several other fields, so we'll start with a map of those bytes from +Alice's transaction in <>: + +[[alice_tx_witness_map]] +.A byte map of the witness from Alice's transaction +image::../images/witness-byte-map.png["A byte map of the witness from Alice's transaction"] + +Unlike the inputs and outputs fields, the overall witness field doesn't +start with any indication of the total number of elements it contains. +Instead, this is implied by the inputs field--there's one witness +element for every input in a transaction. + +The witness field for a particular input does start with a count of the +number of elements they contain. Those elements are called _stack +items_. We'll explore them in detail in +<>, but for now we need to know that +each stack item is prefixed by a compactSize integer indicating its +size. + +Legacy inputs don't contain any witness stack items so their witness +consists entirely of a count of zero (0x00). + +Alice's transaction contains one input and one stack item. + +[[nlocktime]] +=== nLockTime + +The final field in a serialized transaction is its _nLockTime_. This +field was part of Bitcoin's original serialization format but it was +only initially enforced by Bitcoin's policy for choosing which +transactions to mine. Bitcoin's earliest known soft fork added a rule +that, starting at block height 31,000, forbid the inclusion of a +transaction in a block unless it satisfies one of the following rules: + +- The transaction indicates that it should be eligible for inclusion in + any block by setting its nLockTime to 0. + +- The transaction indicates that it wants to restrict which blocks it + can be included in by setting its nLockTime to a value less than + 500,000,000. In this case, the transaction can only be included in a + block that has a height equal to the nLockTime or higher. For + example, a transaction with an nLockTime of 123,456 can be included in + block 123,456 or any later block. + +- The transaction indicates that it wants to restrict when it can be + included in the blockchain by setting its nLockTime 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_ + (MTP) greater than the nLockTime. MTP is normally about an hour or + two behind the current time. The rules for MTP are described in + <>. + +[[coinbase_transactions]] +=== Coinbase Transactions + +The first transaction in each block is a special case. Most older +documentation calls this a _generation transaction_, but most newer +documentation calls it a _coinbase transaction_ (not to be confused with +transactions created by the company named "Coinbase"). + +Coinbase transactions are created by the miner of the block that +includes them and gives the miner the option to claim any fees paid by +transactions in that block. Additionally, up until block 6,720,000, +miners are allowed to claim a subsidy consisting of bitcoins that have +never previously been circulated, called the _block subsidy_. The total +amount a miner can claim for a block--the combination of fees and +subsidy--is called the _block reward_. + +Some of the special rules for coinbase transactions include: + +- They may only have one input. + +- The single input must have outpoint with a null txid (consisting entirely + of zeroes) 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 spends fees and subsidy. + +- The field which would contain a scriptSig 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 + transaction limits on the number of signature-checking operations + (sigops) do apply to it, so any arbitrary data placed in it should be + prefixed by a data-pushing opcode. Since a 2013 soft fork defined in + BIP34, the first few bytes of this field must follow additional rules + we'll describe in <>. + +- The sum of the outputs must not exceed the value of the fees collected + from all the transactions in that block plus the subsidy. The subsidy + started at 50 BTC per block and halves every 210,000 blocks + (approximately every four years). Subsidy values are rounded down to the + nearest satoshi. + +- Since the 2017 soft fork documented in BIP141, any block that contains + a transaction spending a segwit output must contain an output to the + coinbase transaction that commits to all of the transactions in the + block (including their witnesses). We'll explore this commitment in + <>. + +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 +100 confirmations are called _immature_. The maturity rule requires 100 +blocks to be built on top of a miner's block before that miner is able +to spend their block reward. + +//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 +but their special nature does mean they can occasional be the cause of +unusual problems in software that's not designed to expect them. + +// Useful content deleted +// - no input amount in transactions +// - no balances in transactions +// - UTXO model theory? +// Coin selection +// Change +// Inability for SPV clients to get old UTXOs + +=== Weight and Vbytes + +Each Bitcoin block is limited in the amount of transaction data it can +contain, so most Bitcoin software needs to be able to measure the +transactions it creates or processes. The modern unit of measurement +for Bitcoin is called _weight_. An alternative version of weight is +_vbytes_, where four units of weight equal one vbyte, providing an easy +comparison to the original _byte_ measurement unit used in legacy +Bitcoin blocks. + +Blocks are limited to 4 million weight. The block header takes up 240 +weight. An additional field, the transaction count, uses either 4 or +12 weight. All of the remaining weight may be used for transaction +data. + +To calculate the weight of a particular field in transaction, the size +of that serialized field in bytes is multiplied by a factor. To +calculate the weight of a transaction, sum together the weights of all +of its fields. The factors for each of the fields in a transaction are +shown in <>. To provide an example, we also calculate +the weight of each field in this chapter's example transaction from +Alice to Bob. + +The factors, and the fields to which they are applied, were chosen to +reduce the weight used when spending a UTXO. This helps discourage the +creation of uneconomical outputs as described in +<>. + +[[weight_factors]] +.Weight factors for all fields in a Bitcoin transaction +[cols="1,1,1"] +|=== +| **Field** | **Factor** | **Weight in Alice's Tx** +| Version | 4 | 16 +| Marker & Flag | 1 | 2 +| Inputs Count | 4 | 4 +| Outpoint | 4 | 144 +| scriptSig | 4 | 4 +| nSequence | 4 | 16 +| Outputs Count | 4 | 4 +| nValue | 4 | 64 (2 outputs) +| scriptPubKey | 4 | 232 (2 outputs with different scripts) +| Witness Count | 1 | 1 +| Witnesses | 1 | 66 +| nLockTime | 4 | 16 +| **Total** | _N/A_ | **569** +|=== + +We can verify our weight calculation by getting the total for Alice's +transaction from Bitcoin Core: + +---- +$ bitcoin-cli getrawtransaction 466200308696215bbc949d5141a49a41\ +38ecdfdfaa2a8029c1f9bcecd1f96177 2 | jq .weight +569 +---- + +Alice's transaction from <> at the beginning of +this chapter is shown represented in weight units in +<>. You can see the factor at work by comparing +the difference in size between the various fields in the two images. + +[[alice_tx_weight_map]] +.A byte map of Alice's transaction +image::../images/tx-weight-map.png["A weight map of Alice's transaction"] + +[[legacy_serialization]] +=== Legacy Serialization + +The serialization format described in this chapter is used for the +majority of new Bitcoin transactions as of the writing of this book, but +an older serialization format is still used for many transactions. That +older format, called _legacy serialization_, must be used on the Bitcoin +P2P network for any transaction with an empty witness (which is only +valid if the transaction doesn't spend any witness programs). + +Legacy serialization does not include the marker, flag, and witness +fields. + +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 +scriptPubKey, scriptSig, and witness fields that allow specifying and +satisfying conditions which 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 +subject of the next chapter. diff --git a/images/input-byte-map.png b/images/input-byte-map.png new file mode 100644 index 0000000000000000000000000000000000000000..c59358352617e66fe0bb1363de72afe0d7a9dfba GIT binary patch literal 12983 zcmdtJcQ}^+|37?Q_TC|~voZ^1Wp$CViDZu?WW|MS*$%hd%b04 z-Osc4{rMcfKfcF(AIJC4U&nc%%Xyx!*ZG`}$K!d5*44gDNyb8kAPD6Zb*w&u;I+cf zy(C2NmGst-If9%EynV@v3S@a%|BC3 zQ=CU@(*^6k*>$Dzj^0g=Dn2|TEPTx%K}LlnB{lWT&!0cH;#I@L!!t$|!lLFsJNg_{ zOXzs))OG7;2dG>X9P#DqNv)|lch>ej1*sC=JXtPJuq|>#s00_sz~|pnyVS8Ou{7-p zg=S{nY#28JrJ7Y6j#w%@>BU0ZbF^9aaGkl@NCPMDX6|`%sfJ0B8y^e^%o{!LLoFnK)tx)v$h}LXP5|*oDlzM1!HO7T%3M~*4p++o_RtA}D*V=0uu;eH zrKl+FQIWc_{2z03PDmx8Zv4pXXI~_(;QWC_|J0EXBH;2-rP2XYoB5~z>(>S~?xYKd z4`z&P$`ILj`SN93lKKxzLPEj=(uYwd!itKPemmpdlv@3FDLZyWf=?pZ#BLZz#oKhq zgo^W}x6+6X{(8}~XD3v-lS1VgY5NvX`%U_9YDtKQRA@+_vWSG$#}NyBn(h6=j{LrP zIz$Gyb4(q4+r(s~_qL?3TW_xN%F*s@hEasBz-fe&F1on*5Gh^#`m8GwDaDxSdbe!K zbLXcrOF5=I(&ST(q+&aY9-)3rt-DWtjUbq`6+agr$y;hTNkZU)=jL&mt_0y6*^i{A z&5{9gTtVs&{^=4z#)zyQcg{v5QJARw^T*?aR`p-zN z%t)TM?L)t_f2eFe#8bRNL|ZHD#2<{0G^ldZvRQcxbIS(U+1aV+F{Ec^mXULb9{%pv z!AHFC#1S)6ME_GPa&RHo8=<&BF)IcsWVANXG#aoZHkFUuxiAOOas!FS`ylH%ugfuT zBz*7XYT$Lrefqxi>qbU=h}BS~xoofo<~Jshic|N-jeDwETHU6 zB$T|pQFhUzTYyGsC6Ti$O)L$$i#cFd@%( z*98)`)<`4}&k7Sffo$W~sp>yxL5|;?-%2fo%W%3j={uo+{2x>&olKSZqb>5uHfbE`6}dK+d`fvG}Q1=1LNa z77yWGJAF-lJ5X$Dyp9RS3`JUN8&a+2GPSN;i7qQV=E;9?S&u=`uD|Id85!BjffDt5 z!rb|TgKnQ}_ob81X*|0`5_0q0LX6q`Cxl{Pl_pPD{b^BA*Y?C`9jtSg!o<@Fdk#Mz zxJ06&WLC3d_Tgx}awTP}l5-aYGUPwX#m&u)_c+8%f(&a=sFPDk!6K>d(eXWg;LoQ| zpRm@}d7lm=wTX8)97$Id2k0PVY#`f5elPT!XX2ZW<53_gBn#WlN<|6#)UOEsbDGO! zkXibH0dW+On>9par9h0(`=)}_*`rG$ZHJL2_y3-o^Su5Xl9rYxq+fzt0zyLcXgR-e<3{YQYt~ttW!g?MLxZun9__5byOkA8OHZ<7D}I`p ziVe!h;YeuouMRoCJvi`R$?~2!i~Pn^5w+e%IDY;7x!||Gd{(EZkVd8UeeKOGj~1#O zj=|}p4q0cz$bIUiCrD$sp|bG36!w?|5;feJVn2L zn888v-oa~z zCsOT55pI?^G-Z>s&3Rek$Od}ebDNZDFNWicBmZ;EX%3WhiSX}#^@2DvHc7SfTp9T$ z?fbiUtkL`V^p>xVZ^R=Xc^4mf_Vo00hf{K1pXZ0G3-rv*MRr!loqXi8lPia<<{}?w^-XZ(nqr#$dZu4ZG?uX!5`$rx)WVOF2VdS}G%je0%RqyY}xo{em z;N&CO(_y-p$DQ$PU7}~sd@^nc42WGkSh76+L^M^=c#Cb&`ag%mmTaD`!2Y1AYxlu= z2lY2<#e?;mmJ^jEfOaRz zH8%61Q6yjXHV^w=;;i2qd-WGYVfxBKWW5yq&E6V|{P~MmN*>nqhcpY0qt% zikI?pY(ok7W7l#l1DLCRxu$ExS1%g9K(fAx+Knfpu&qY;U@qv0 z-}m=?h^fnKLW3gh@X58vlvgc`aMhUiWI&>R&53{4=s?B@3=Q)fSgu~ZT6MdRTl0x@ zb)ScDmkq*)dWgE394n#Ok3E-;%~1%L+VJ5FEA|!?5ed(C+eC|Rmg_Ly7=hp8L|uU} z3_j6R!&2oXWo3+Je^}*Gl`wfIG4(BSG%x$^MPcess*o6`hOdq{+Aa-N^x~TOJeI3N z{_gysZE`)+DsuAkXHEI-VcX$)cb@xgoM(iDXeo#w*W!$Y2M1%Xpv0;uM5I-#s!{3M z_3N{%jcaOJT3Q8jnwjS*CG30dgg)beP3NatAqrFpouM4ZyPfKM$vwr?rKRmP!VC-y zRn-6845VJQ;7m2AS)xRnbbKh7v;`!Riyy3acHgO6D zMn;?ADr@JaVytJxF#Y6k&+jzz{lk$(jjiawz8NtK>_E0S!f{!iz4M8T2TejJ>&0JN zz9)mDM+CVDt{GM^?SfV8Zs;1mGMwzHbV!i&C|yg|ssPf$I*Qzb4t*sCx zzy)C))4p88fs+tX1fgy8qNbZAa%d+g6&u?q&y2M?^q%|LlV<6TptiIXQ zJ{Sr*Wb#@aTX;F(m_ekf_hj_rO}dOinYxw4(j{5Rm9ko*{d?PK%jS(<(>-!)Z_T~O z!{yfA&;utB^I91RfAD~UKX`P_?uF$fJjcO;PLRsIdoobkpA4D`@=9ujmX`WVhcj8- zVDwkukkl$;8Zm zhx3o;h1x7 zDOCC;QFm_6ed+v}W*HxXPuyNp?yI~PcVVKnUq>+x{a|h9k{-j;XU~*LFt8)YOxw0hr2Yk0aKMskBAp@Jv}_uBPad-uI@pZWyYH@gx5R!-=AVrf zYgW2)h4g(qTP$=Vj{Tjr%c`n`E{!Ya<@c9g^h#1fu=*@KORKVK!-Eb!7Ib|0p}YH? z<$FuF7Y_=3tiNxOJ*6 zG;c{(CzvPSE8Ltj!)j-#3!6PC_QLU?2H-)E(ekA*1qE=+V(721PbKPh@L;N!|3SfSOpmmX$#imIYl*_;Z)fMX@T-gmJOd%)y5RlZp;uh*DV926pnUnp(_$PI$DYorw-`cRbh>A5r)-&-1u2S}XHBYN#wZ?+BXqz3?k& zSGBs4D)BpiJd10~bwA9k@!1gji#L}dse0~e2qvYb5=>NwQ;g zq6&@Vl$3!bqO*5@sF#~JrdDuaS5gAbeShiDPeVdrmB9xO4-d9^N{|=&I7LVBm$}e< z0VozE;VSc!Es8F0Hq=PC5+Ps4#?1VG_gx;Yb!LTY{_LzJKvgR)jk$S_v}KaIUlN0W zQXzBnH2xe{81()1{llIQlG{$pKb`8Swtc~)r<1REu1&CAH^-eoYodl&69eGAo_X4B zF*C0ZS~@!3_p8T?KwWFHB6p)-rVfE(#OnHn_Hcg(&5QPFaia>8aF8~vXWz%&q2zKb zVo(h!bdbLLgM^ArHVmxD#Xu(IJLW>lr~=hy22I~oQS%sJ{ya(QN+cmr*5K#a!=1^_ z_i?OH2F`-GFy9crG23bT@gc8qoeP`q)?&Ctldtu71J1bSCh7YGjs)#2SuSX!{nb13 zefVq5`=WrKhL&)t{5(AP<_(?>13E(rsW?bF%l(ldT?>o&cd<-7Vq(69(Q_SGCIa`J0ps#@lJIfMa#R!6pWN0-hMTpeikLpp=>SyESs=U`M#{4(CKYaPpd3^BY zIJdr@Sw=>txVTtJPmeY`=;$7Joe>On>A6Ld+wXb3G2D>(E(kFj{W(Vra$d^_Qf~H| zZpgwINGN{~7>yoVN(vvjb4!f4n~#S-Aw|6|nJRId9R4fF1LC;4CaGsGp`IiR>UDz+2z*r%}m;9y#&P$h2v{q;cxc&&>8YH|@QH zNQgpFCrsYh{EgJ*?b<6iBR7KI+JKyQd-uSrdaA9Ai z=wqfzkH_v{Tq4H**#s5{;J^yl7T|5j^v+-1nMvvCq+K@JNl{O;Qi*l;d{1;3MgD|BwqakWFfCWE7Ee zxNNW8MXl=>f$N}_=62-BAgki{eN%#DEczs5%^$K1)`s5pu-^AfEwQe5Hcmrtq2q&f zYCXF5MPYj7(RGUusD69?>pt=*o&ZJH(Eg1!0DErP7C^;TIo}WG3leO)Go-Xza8`xXbu8Nb7K|b{Y!YLh^F{_nk-P% z`OiJf%71oC zIm}x0Da&&x~ECga^78#aDp5Dsf0}hHJQ;6c6 z!7I-CS4p^N$ih)ify_bEcRR)Ww7$9^;4t6q^;!`}&!iJVkSo&`eawkQVMONQ+MpE@>K)h?Kw(Zod<9Tw|?Nx`l zogJ@mmx_yv=+hL6R@|}}2?!m=FK$s*HY}c*BWVAXJ()QEP%sQKhS2D_MO;~B1KG!$ z4@Y0eH+?a@c5Mn^XkxXo@bB;TIadq~_avBTX}=W+#K4RK_ETAmnHr%c9U`(aG~C!} zIc5VNv|ij93+;%c&iUtYv;I{;>ee9LOS?@W>^@T=5-+OeUIRp&{&w9Gr2<3wvVgl9x*3@I*PdxkhTTN(sQyj3c zl$wd{YGLxyQX8}r2?{C;GnQSq1)1Zqj0YbwP=@a&H>zLf!Pc~z`<~GXqLY0nP)%G} zH?z7$2{t(9GaFaGJ>sONtBdqYf}^2D0`krZzRa&h#`Uy(1z8>mWu>Ln^I#4x(IVvn z^df;h!{Cy?!ifo`PC?Omp0HrM8z>vKO}H2l$9e&{Q+`bi9S|yL{BaFf z8p!5X45q;)-NWXbrDbJjt=q%+bna`c;A=u=46vXpe53pnN6g{hyRc}Lu)&(p`JEUQ zO-$JE#b2G28-Un_`Q!P0`E3knCHaGI6mspmfsok@cHK>zx!I# z4j$4WhAw%A$jZ?`|0)O}FwImN!ci~-hz>fE`Db&p8uXVtWA#b@KE(-imHpH8R^m~0 z6Tal8wRhUU78}6&Y+8dck0l-G0Go~cD~qg9z{!GwDA_`+Mr)k`eggXeZU9#)gHSo@ zLkc=eantk_w}D&B?!o>2{TrWzo?CrLN3093|M0adZsOes)feJs4loaqV*9=w9 zrN4cA))tkr?o2kbK}hK_Xyz!eAyzkxVke8djHXPM4ZvVOTqs)Y)g7m5vc%fDEVd)M zGJS)b;=9WP$iRi`(;a7_g3cXnEe-LcYufzykW^$os_;>}e{pSb+qeVl{X+r0-e9^{ zQmeSsw}-&GUy_yZQtn=EHr(eq0BV3ipcq70w=QkXKw?0X!8ftauJIIW879letSlUgF3(T?Y@&-y%<>$62m-rZpWFCuk8Jp%*K49);t z%g@ip%hM&vDEvllR+2U_bpFmomr|+MC38>a?@>;^C|MVJhQ;BefQv2SE<%q5yac>R z4HU7{bRpKvTFsp$>gMdKdVos*>JVs4H!>O|b&@>sd8PR++!_Wl^Ak;SmGv`ZD1Ju^ zfZtjZaqhN8@S&_9qim)_M$ciYolH=XLQBa{b;=S-r;(k}WWT2h6YID_2icvhVm=6+ zEP0|Sqe2H3l{^~JmV>)ycR%vZkJgF(*Qo-|dI*h#~au$X(AyS@zU zq^BUtJYYq#1OGUDetZ_c<@j)I1H_pr@0NYG^R5#Q0QU2+C&-O+qBo$5%o8Ac`0?o` zAs1v?Y3Zkvl_HF>7z7#t(4!aG+baV%mRJT~=3F;7r&QI`1${>S^w(mkk-)6O@RE{F zeJ47oVkOX!@UI!ZOS24&9(8SDgQ-dzJRBtMr1Utk5w=+jILz4|#OvzmO@}GU2}_;$ib|_-YSsRGcQv!+PZCp|Qj%mLL_nJXHZwD0 zb4u2eWVFuJd%|^pdj(Zv)#6yfp_|Se?XPtLM#UgdFM2lh)245#xJk08!sOe#q@+Yy zlEt}Zt+Kn4EgIYV!d^!+OZG%Ezm8g+%eeTzq8NezsUpzo7YE|#xjJ?d2A@#gF6f$> zE#E0>3neb_UYnR7tYC%qj<2c*%pWBKA9>R_f%^0p>0Ab>SKPkm6w+FL<3(@5W$HQd z?y=V%K#!@JBQSz?$xy$@O7(t-FB4O&3J{T>&kX~HNhq}_upy#46(#ii4IPlbj$*w6 zmhf}?+pzn@%*@!m&AC~SKrWk@u%KswyfwI=eq5O8f`^n_G_j=GfoP5XfS|G*(i%a@ zy1r19gNFd0{3Z|_p^|qCziK@HBn1(wJSlPNt~~_(?Bz>IVY7M=^f|muH3WfW{MAR7 z?G-y<7xxXzjATYVL9*>(3Xf#>C6T!G844%9xc92r?TiTPjtJ$e(I8OUz;2o4yo5oW zj0U9v%_HwIcVe%#iMUUnt^&2;cT+3q^R*NO1mV$Gk^%h8^XM?1{UTY*WCExdC{=|i zgqrlJ_Yj!XF5|LqHhbiD*N%@|KR=P7|8jBX6a=()^CsKr~VzUhlhh9sADNh7>t)BozUM zQl_sI9j$1R5wrUs&=Wm=eQx8=@xT99uLOM)gj6zeay?_?C{%(=P&|@Gre4owquM^| zJ`fgK4p&^!bO|0|oB}J@0@Y@g_YsFA4V^sNu0zGNgvP8l7Gi~3nGrtn6UFb04Gq-= z&))oyI2$i*?ahH=do=L$3e=SK7>eG#DJ~{Kxi9dSjkokV0KMg5MCG&cYDgTK#~YyW zC~N%jF*%Ft`+4V)u;0Hu!Htm|fy^+xMfqJeXkA5J>IVE0BYA;<&Ep(JEt^jbSq3%r z&(*`tft$fs*QPB-U~z-bEfYX^%Lj2w;LI7|V4*Z<7l7XBRPzh8@`O=+6e7oM7;I9| zsYn;FqJklc(*esr5hWfn_hv)2vc<(kzDxaRw6(XZjNO~d^4b1wkIu9}EK?>4kz1|D z|02IhflPru8{9eD2J~yA_Y(E=MkhxnWX9CaekO$j5I;EducB1~H1X+vcJ@0^a0SG~ zI-&L<1KFDAp`@q_W+itl_wt6_W>7L{#7Vv~Uv52w?0(`VSGZl~tSx=Y%OupGG2)cW zU4o7X$`0t+;?5($H^bd$-&-#aS4;b>bAIjbr=^O71He_b@1h_DyF9bd^-7pa08|1M z7*+G0rf9c}4kWJtBvw<4pdXNskXZU=R%L~0-l}lL1i$EpR+#wcQFulMi@l@^7-|GBM5!PHB&jV&w3dIgW{Q$f>X!r+-~sCeDxHg442+^?QK-DgCg)YY^G5yj zOjzkaFg;Xf5NOeHfeOh3HaSM53WyX+Y)VUK0HwUO&j}zhG@Rb>fuRae756qmCQkMQ z{9t-K)`*t_oJ>@aONU`DIX<{fHg8T55lYtcchCZYAd|;OJ6ThsZa*S_;mvQT3tBT1 z(M4llq$Tg&vmCd(NqQUZV$ypi(jOA?&8dMuJuo_14w>Vf11*ZV}r;8Xd_NB->~}Gjc9;K(C;O_`A}A{ z?U%r95GmVXMp?Ylxd_v$PQ@cy2+|J7126?-6OBB))diYtg@n=Sr$<6bX=wl~urhK_ zF|8mHO>OQy(c_cU@`yO8!FH=loC3r&Taa5GUvOmyF&`AG#aDMnxOyzoA~3&ic9wjT z>?VEfRY%;IskA6S(m6U9VJ*$y^u12#%ozj`Yx+&+(!6);$IqYEP)UI<`yB1forNGn z1?z;M10Ga*_uu=OHvHOyUtxC&f6QytxqdF&ZykngWPoCYK$xp`om8+-N2VfJU0UxG zlJ`EhR2=hNszCJ^0eDY~rgh|%lY76`g>PjJJ86|ACGOfO8cohEm7rLI-Yw_73NO5H z@o7IH5#&Y1`?bKGMxai?1|G*phy1VNP@Jn!i{xOuNL~b0YEw3rB#h>DukF~vc;c~? z6XWXZIriTxqfFHD>j)%)A51qb)_yAXk7)4MrbHJeO^NTcS|=&(=~T z%G7n_H^My5!LV+A=s8EW&kX6cYu7j#W0kM|E8)6BwYLK84{2t(`6bN-kn80e8&}Faym2++MLYY{HTKI3gLr^dTe5QSF6NA7uApJii z@l@NqBP%)rQ56#Yr{;cAf)8$bpwL4U7u>} zSsAc%TEyvJEzmLEgZl%^bO)3v~zGguSyk^QxloY{*fxc{=nLT0oi3rHCd^HmERO+DQ4>>a8mwbRMK8K(-G5W(=}xa@FfS< zab7f<6%KW^g*^wiS_)tPd>NXr26d|Ska@C7t0p4Q()zx};ecI3zY}WY{EuqFT?(1LlYg`>R+c)xDBvIFDiiGVGwl81^hF2p%yX7yuz0Z zO6$6B6X2;JF#TD#DW#%E4W*@vPa_QEOto)0+N0*#ISc1j@u%1Sc&LHmdXxt}Z#j~M zI)(x=&=qF(=5j8Bo;>QS$F}SRFMkgxRFM;8;kKpUHdNZeV4V4^4Z(!ZEG5H<6Vus# ztICFkCtT{Mi6~Bz~>rztS_01O`S z?<)w;(kx=We$^*IC8D}bcXdIou&HfMaOjmv>ehxzjpsu`0SY$wBJBP1f zG`+Y(3Xz4qPKA5jbDJ`wowFN~`v<@>=GK%rrw%F{ObTSjdMryud%n(Xf+Gt-!pf(2 z3qTZn)^m?Q{)-0Pj#Tb;marf%XrN%5;2@xA!!1FIL6thzb(#=p$8TYTRvmO4__*-< z@^-bUIBWbL&Szoy0=qEaULBbBI=VW(O`8+2eG>e++Z_ynL14xjtkwT^rEXFbXa3x* z+9urLMk<2{vuhcQosAnjOX&a1mmyCy`I54;SMTKX_g!OinKQxh(_QVCd}xT7vFH9ZlzHX7tn2-**@+EAM?-rK`3gE^!Gc& zaPZ&G=@EriL1so&dNvD_XafiTU;Kv+|Jy&pVZ7_vih7t?L`1s;odx!bpN32)W`Nxd#Y>+XP=9 z5);DT9>g?M2y(MsQBGFfJ!NIg&7IDy<;J?#@Fmep!FdmK$MiIDCgrJ~8Pebp2eK8Y z6X>hUX;I^oJ_w%2<@vNrqr;$v~yGroPVbg4yt{Led5&K0cnJ zh|@_?)Me2XQKuFs^Hq;umjW%5al_F+Og9VG$l2K8Pu@MUCOP;s!~Os2XGb498K2MH z-HA6dpFK-Uv!y?CW@)=#Qtst&%=_-ihVXD@p;f<_nNNs>_aA$Q-W(;J?@t!q4d`EA zbb1}m?J_$zcklB7lPr~h-A{?qs;a7v25xC-1J_|$_|3w_1J=u1Oe@FxLmf3-NjaB( z?B4zn-_mk(GRr_Zch`Em~2X!{RELDL|haKg~Q$z&6 zN#wA5_{<8C>eN3z*QirH!**r6kP4Xxzhuqm#io4Un4VYI#`#(PIM%=8gpu)139reOW(7j4ma9a^UHWEA7ZwtkzK@{QRbmKive14z<7XOCb&w}ji?03Xrt@&!z>1Qb?ln|rhfe|jo=ms*j zgY~0g-0+<2?Cr?gSqDx|P7i%grjs;6Rk=A48BUt#svgK@rNy_Ydx$ThL^*CJ9UGo| zqo{84?w9~sro;5d@ytzROO&TrMjo+1bP+~8Dq8t(-csYNIJ(RcavccqTi^Bb*oR!w z(&LE#R=0E`S(6a5U!_|_?9brO&9gPWjqvTdOAx6Jv5)f5L{usDI?K^J-ba+NS!K9Y zmw9-SGs`ZBxc>2F$G&J;yd~@~)yC~_hhvI!2aj!X?%2%;d7_TFLK4<$ho>4!elCad z+>I|02j=WziX^0@O05FHPTi6NRQQw9Qt2vpIcYj^OfN+`-Wn*<+a(QLC--;frT045 zRE;!jc-AMg5#Lc!dCY3a&c5#=rzU9NcjQw2WaK?xY`Y106P*N0?DB@Y975t>Y^KeE zn?dgHrdg~%cDOxYFtD|?mAyae$}VT%ivk-%9QT})rQ@RMQZUz2ZA zNGB+f<1Fru!6Lm{76vir+?n9Zs>)&?Jj9X!TX)-o0L&m&hkE z`w1B@b^QchQSU~Mt;=hLT6mR{)uDqQ3BlL_>vPf{-3|A}|tACa0C5v}DijkZB z6NEvo;RI8h9G;55{{1lhw0Wk(kGu9^ueX&D17tqdiqxnA)`O)oCj5b-uWy5zt}btd z^+1tncbeotR@rOJ{CexzTqf@WAs$MRF4ZB%I@ZxM)ZY{hQ{|w5&ii|->#g6!u@~j3 z^*3koRm8$`U8r?iqlXQ7c#J=)cBLty^-A;3tF98GR;G7{tkiwXYP3qd1=Yg0^!3wH z>S!;)}1-Ow0pvKaW;BeHb0p9Xgf8yfA}q z=H}Mcg?`q3AuYe$8|VjIV+cIJV|BDTrYj)E7Kad#rMmy-gnWL$&N=ceveAgzAx-yhOWrU)M&AH7mXUze9DZ?NWymdS%f+2|+A3ZBo16JeKWiTOe}1H=i(W&xzTy0#JmC~m`}b?8 zpNlD$R;FyiMFu9*<+viZ!>oe-(EDvkNr}egypojO{FE2jnLd084~1t_c*$3sN>ges&6!$Sq({yEP!h!_&ao6* zjUCLscV;guR_Xyx1<^X6e*n_3JX&2|W<9{SGVt;eaiGVw;{@I}lZmbSt&UoLTFO50 z=vRz7N1}SA1XXAe{m)a4d`0^KdnDEa``Da!?l;fBUyJMBtpi=&H?|$3+Kj_<#-c6{ zDK1=9dT2k~_%&7ha+tKQ7c$Or9D)9W>wz*B8S)ad=p*-{@?EOKVLmF{VI~qB!-+!rt`Lo z{+ADRkRY6RaSNFcJA5%K^5(x>$e4D-dozi*{rP|Wgo1?7wb|JnY5%*Qs~dzf8WiI= z=WF;7D(tshRV^*|(foY5EH#|?{8D1B{FE6#^tMV^%9s*hvnV>>b~;k9^2h9EUxLCL z{NbV}x%K6GUtAoG)9&h6-pGp7DxJpEM%AKY^_MSS?!T+3P=E6MpNPfXgRZe!w|u_D zrK(OvPMSO{w|TjF*N4rT84|2;ojhp-cQv ziYoUHi^D$~XH}$+oC`aQBuzzm!)8mE5}YJvgKuWu=1_?Fa=6*apUvNRxan??_5ir%y?1pnzxentkd!anDmfRis|JaI_@xF#DeQ^7B=$c#Ofu7cY zi(amJHdC)enHFHPb}dTnzqcJW%cLn9iDj6boppo-s+&u7(+~Unf@>{Jz$kEY=7owC zm+Du`?&mmFB_*m=YYhia<=CGeHQ`ZuyTL=v`*Z44xr3{n=B9qVw!1AaPhdLqjeN;D z<$iDQz|se3P3v94;}h>kZ1XW51z~b>&b&F6Ei10mwQCKnOT~>W?mI(|{WyqkR$C^s zGxamKEGXR3!(ejrtn%`#I?BA;KKtibD&U{W@2%pFq>`s5qGSoqvAn6M7_qQ>a9;7j zllKd9-M_THTI$5m`2&i{$jh^@V$pbO7sw`~M*HXJm}mD@&MA2{w$5w!drkjyJGP?W z`r4s;DW5NW_sxnJu%9I0#v5Nsz*(50?98f*EljqMbmX zonU=V!oQ=#=UPb$p>B+2a>-&8cckl4Ic`bO(lgFe`5J{SFoLL}KIGN;?ko=_N&87b zbux!)|9icoEtBDqahw;rFHYWpHkH~E)j#$k zWAs#00A7-$*Nsq0)|iV*$!sjKts0dhB7{O7qbPdpN*V-oDx8O?uLxo zOO7;?ckHL(c{WUX)r69BWU25aj{i(sj5kP{YTsV!FMOVm5W2i<<6f^{_h%~VPb=%O z>iFxsm-uK&WaBs`{!9dE)w*864L~|NJE@8BCw323_^5@tsAOSQDzxWhS($2w7A++S zTGHrL+D1>dhM9bPdUoBj-n9q*s@nVY+9)|^?5=|IH7yq&D&h?JDEjdBX$7CvFR!kb z+E3o(q&ZbJwkkGymz^Ekdk)W@oKrE7x0B(94MUpursDl1fywZ>`I@iD{WrlvN?prC z<;X5lMt+S4@m_DA^ zM;z-B$`_Y{J7BF=Yu5;o!)ex&rr!&_`4V;jW{E>?x-|H}Z@=}&sUrN$vF_yPXupu1 z*e`;cex=Ddk0CU`UgYV~!R~a;Qqe7dHu+?2x@D%PI2CXD`uavYVbJCMwvp>W3-vkR zQeoA%n9H$VSRDW_dbvkx`^Up1aW_5*7Rs-ZyQ3Uwm4?l@h#@m4JG+=H;Q5jkJ9G1k z3B1~Y@2m&d`T4u`lbRN@EW60>J74P)q}nQ~T@7rXE+sPdlwi64>e`32@?>DbF|4pw z1$ukfc=z8t*p&GaLVCs+HbDV@OpDi?Kc1}QLQ;76y!%yzHK=p8 z<;UBHMhu~nOF^89Jub{19v@fDMy6cu;PcyzVZcilGByIN$q5#m8>(k{PpHl}Rxxv>rjF z;8r8={e?Fcy*cEF;ql>~R*4}FU-b;lmlV;{O0RFobJ7^4JLhS_V+F{nbospe-Y$ue zwf?~z{V>yh-+6eU{|{M)qu&L^2k}P^|X*RPj%9I&iN#<&1vCT9_{He6x5e(jq5`h@JkQv)h|;4vn1UsJ0lL(ds9+`e1X zV%FsdhdX0QtWMu9K12HmQSV(7ia*74;BQ|s(r1vrB<3x}iZ3f8!le9}%BD*$EOuoZOLnZ&sR`#7vWTEKb!Olw5w=9L} zoe?_)50C02-$?A>l^Wa1bD>5PLyyxxKs$8k*M4lY@IBjoZ#MDyt5=qlH`87EwX2}m zzP)|O<&`XZIalX^QkDvqSipH+^(n(u+=n^$OM?o5uyWD>k>tJ|%^0Hi;^NTd>&mHO zbihA89_^0D^6AyE(ULT;xZa||w@4;z6<7|)3pE<#!s(y04JRj)Q-0?8d6JVxp8D0R zSD!jMZo0bOU=*?nZVn>iU?4NznEG((tgnln0(7VMcH=SdZIjU|2Shd7&(hJ_WRqgF zM!NbWbvp^mtsueI=@`FmHTJ$HLo4wd)Fb6Hm=Pck{8?|M1WNU^prBy7M$S{LOzL3j zLzKhk3yFr`u=3~-y76Q<7>4dSpZ(v>Sox?D^Df4NwU7OrdDb;W92^{Ymo*BSKsSih zE;l#Y+nh}jvZi-k9gTp0o_~I)3ECsA{LA?G^Gp;R;^HI6F+@SK7RjM9Z2tBlWZDT1 z+kKi@0ED1ngZzOZ480o{Tu~tikBB}eY&=wE#(n9MEc{G|k_$?`>2z9+7uT zpGXKQwO*+l4YUv>(HnreTHc)6aF2iG3ymdyH_q&=R5~SG9!r+-~7FNH* ztLEKl(JYdlYz$=Vl9J4m_Jco_6FWm9BT3+FA6Q}E6_?}Qpzf1=j|{L?Q?A3^<~axS z2$IK2?Q{R?daW7z$bC_(u<@L*Z5zl35qLxthG>Z|mvt_8h6Ttp*#?k@+_V_3xP<-2 z4dd+E_3JP`)G_b)PhF%r1&aXF?w>brZqdr;=6SYd-_8&DG`+z_A0>;y2wHx}zi{Eg zGqbbW+S=i_v$(HZ`Or!!{S+3KRnluGxM=Cp5Q$C5vF%um(blgnA*s0-@l`{ECwXof zCGni60I(`de~iBB`P;(O)YNd~{S&CWJNNFjR#^6;I0}ZiNl%6>!*z2qeAy;|89i@Q zSb^!B*3|d7P}F$rX*2Sk{K}*E!A1-WSB>#QDVQT+98FCbr}*p)RV@|OmYB3t@M@Rg zv&0fTe53p!_|)lV@$m$*RQ7Nbp?+a&&%rgcpB(s|P{JL!FTQ=V{{0@m(T7Mni=na$ zES~e{>!3YrRXb*nxrsc#W7r%>Fj(cl@l|w=32owYDNYnfhGlQgpMl2XkVkg)bj)JT zO~dc3C%5)gb#x-lyOJmCcYn495|B&&bUsX7ygj;j5WvAN5+Rr^3g9 z76A+0I)1z(%p_uuG#gSei@UbL>B+QA_Ic|tTwys_>&B0+rBQ2WW=RPZY+S4OT3ry_ z=41p{nhdn@U)|}kQTz=IfM}YbP*pWFLamFc2~{LE@FiGOI+$e&?zKe7;ZjQd$r$_4 zT%$e$`!@6I7p_e7WjdNZg8b49g;*A?Qey&uCjyQ$cibgdp0Y?X0+48jcHq!?rP2`4 zhgQ9(P{W@o(ovTIJ?JAXAmK*A{?>c#PA$Ai59RG#KR80K73TBGeuMD`5(!{RRUnjI zHT^^dD2k{vk-t4w`Z!$Ez=zK7v@cfdqn$2!f$tk=me4fOLE< zSprQ3o%`KV2fVg53m4_ssoSO<4%R?Y1q9C)$u6iAG`p*Z(B@M0#M{nRE&mnHff#UH-tY6z=Uw*8+Zi3lw_~N5%vYd-Nt$gs! z^YBknr~)?E<-vdfeJ^qtP9M$~v>onkeJgwH zdophkK?@)ZqhK!EC5_`8(sTm?8Y_J`NhzRoI_q|H%jRrnrX}O|@81Dz!EC`V9@AG$H5~+2ix=ps!k&Qen(3NgVj!4H#4b@55`Z}nJBU{GLTq_O=9-v#F3Ga z2vS{LeaUS~*}29LIVJ!-jhHY<3*axHA-?+G4`^v=WiWj&YnN@4FVf04Lo0TG#vwz6 zuWR2-fNsaKEmeQ>VhbsMoBSEQ;237{sa_Rnd1d98F&9pn2sW5fC@4TCCc{`mM^-*g zGzV=!;ZJ2J>bJlWohJ@F60RUTt8-DP(DYG! zKCqp>__Cako&Xo8K);^xvSv|%gQ)G&$`+=t=>iDc&0F#%y z%!3b}3z4FH9~grJfGdvc*G~@(4ed1D2T5N#F;_~9s~*}PTBvOir>QBz9Dwzscwv69 zl*2#$pj;tKEd`($%uV>_hy3D($btgiPeA`i>-%M{=3nlCT9|OHg(*_vG^gxkVAA!m z7b{N+Q+T9U(s`Z=FtR_4aVS=t+`}RelVBvIcM~bbtwX7_Om7SZ*+{a$xtqZAS|0&d zU|E}4P7N+t9_k*Qnflfg`JEzF7|NW|#xp+mFSw z3-F5InE2!1_0)U0)y86rmbkgOWs3FdGeBHPefDjkS&X{t)2F5sQ78KWJvXD}!P5ER zcb5a3*)$4uLP|~Ar8TFF9yDQ z7gifjeDQ;1y*EE|0p4to%+(lhK}RfugnP+YNXKxP*2pQOREsQ8*YOmrQUKuSOsGz1 z5g6rvfW1LiLA&bmSnZi~@6A)TbsM(@ZAS;wPPJGGpt@5}t(zT+5bh=NeIOSe^#`Cb z4V>wABA?zmd^QGPw8KktnoGG2s_=Xy`#ul?(D(Wcu%0c5H*Nn!IQM4n`f zg2a_SJufHl8>C&s86-J`>mohFhmW8w3V6BA5Dmb!wm0d%kpQRA;k*-|m|zCu!6Ml_ zG21eEOe`fmJr*!1I^h1mDy;*@n0#&5(0q$hG8lUIBut!-Ff?>8{Lm)C&mWz!rTbhd zuhy0NFs?t|^O-x-q+t66=1t3k!u43=beI012j?HLS|+wQ2D8LzZ6fYD|% z-oOmkSH?SywsK`<3ZO$_(3+c8TunL?uAn;x%wG&1nVT00Tp$xPPQacBkIFyo(dWW| zsSN3z`v_m5Gz!3r`+Q~?C`e%_?rjUFhS@CwN2p~|!1MRKQP}v*T45#{_)3@Diwb6pNcyNFGx>1P_K zCOiY5Z8~_`03sH51VtRwWP}?NL6q!VTPLyxIbZ9$lk zO)!H&T%hxgB#4k4M2!H;WYCu=AK21~T($wjdL;1*FeZ=zB|qWi+C-F6$iW4D`utf| zLnC1fH^tjO{DU!ipCuk!<~CzBbY~2_ud;Zr%bGrZ%t1>s3D?sEcr6_G%T<$)pcH~P zMQ>(i=332{ND4hq((`u-zumsK6pA5gT~}`M(%<_`Pit+M@vbbPkMinXS#i-4s3GKm zLgYHIBc8jfPr_;}1g(naH30j8*`w?5feu6yP*vedRA~v&YBMfn07ii?>yPD55_91Z zRJvtpdFg&{1<@NiT3R-cQnr@iCD9r$R(YLMN)~Gcb5F>t>kbngf6-H*I&-xuH8Ldn)ett>-FhNEP z#Q3-{J`f(tWT4XloQk=*xlJ!GJ$!bDQ}w|EU1;bZUFxaO!_kS3|KLG$63Rt8!X=_?rd5$jrG)=yE z_wL<1iGiAK9SM#rSGx37vH$#o4{AWO+JFnNw;|24g0p5ZHwu%uBX?Z2))EiBtsfbe zCP~ILd+Kkx>Kypx^ICr-X%#>(PI}d`8a=NLQ*tj~zMMc+y*J9KgGT|mX&{n?xa`@$ z`G*sPGHho(=o6Bv>guM&duex_gh9NAlZY9b#4B-|??38a(>N2Z%I)0N%;Dkj4McMp zHr3gT$MptK1pXaC4?qu#p4E{Zu1WRoQA`tM@6)<2g^nE5z?S4zPB6QlF2zhoM|Y{7 zh9%WEZ%sUAcO!Wxt3U2D)GUgNXyr>2&nj#9us)Nh{jy=JuuXT#y5_`UM7zFVaU^R= z3}nTGD~|}Z6IL8Z-@3ObJBv;7QVHF$tp+z<0pLG0V8C(jZO5$K{O-K7?D6MFR&3HQ)iuh!pvQ85Q|y;X8XqK&pVxR_>J4KEYT>=-~YYv2c#Etp>&J9Es2-T%Pxm?pnbTY#a>Bvvw1c-;Fm9wAxDfpHBq zWN0XG2tNWxtiGQ0uw#+E%yZic#12a7Ln^PG<>rYHNk7!Hv@|h zXwYrA6i8lVa7Rk!4Nh;!#BtKn(Pe@@vt9pc2I;4D0W}ZQ5P+P(?!g{v1z#EmC9&1&ITr8Zy*Z(xKRZCDut0-VG4c8K-!7S4Inq6nvgR|R z@Z~_W9Sr{Yr8*CQWR#r?#&Qpq7~uiG zT=cMxfVEa3Yii8c$6r=>bSZk?G_rjf)ptQuijKV;8A#1>`^Sa`tVcE>p`rTw8ts$3 ze9INjC67J>w*trTyn99bpSM2>kb(M=QBbg)>!LW|!X1g*D!|t17*rVcxo|*kJ7oJ= z?t{(J=7ngF81kmiQCeUORgN6xcW$~%?2HzaYCXN&_RZm{(rMTRK+y1CAlsmiHxApC zD=Wbr))w16f=YlQR4&|cW(OC_h{4sZ{B+^1erqkt2w(H$i=(!}wDJyzA~fw6g_L>) zYz74Y=1#+IonV573(PG14mT7~kTmYSMGoo|QTyK)1NmI~a2*c?!k~~*=j9DIZ@cRh z6ySN^$`9)gWPY6Haj^lU8=f(61j4u@K~=iNOMlSU91pj{(<^vhkp{*S1dclPf2MfO z4k9+m7p3;+IiRmk0Sp57Wv?$0kE~S&90;I#?ysVi!{7CU7%{kmoa=|VmzaIN@0NCg znvM>MQg2VS)8pC;vGa*q<2WG80PsdYQ-Od@e(5n&VcH|E&`4|v3(bX6#`|yw$-;K} zLF1!zF?CPlSR!E#BFz4V4pl?XIF+W68y9 z{x>Zdp+mRiu3<~?DQQ&}!IPc;>Vo$UIZw0qup`41M0i}Kecuj`BP zCU_v5QIvW-753h7ZtUAzUAal^qU=e`x=U5*4esd_*@xOQXE*xAneSM0?aX-04 zme}?n=;=7QVlLUdoj_MYjo>~oCO(ZF9UV;Ldc7N7xUy7iig8D=;a2U7Cgxok#sn0E zlwvIXIKx(Bg$;f;{u&?Le0(44Jhos0f=l>&{#(_``w_(q33g@gUE;opaa_63eqIhY*I^83kx{kTkb8i(yK zd2}c_N6ma1Pk@>_6}(LuHY$IhX#Xg_Kvh8EKvgq(R(Um$;Y4Q7{>Q_F+~YVQcVxUi z(X5Ku&h4)Km28bt-(kF&@NlaZctp!ox+5 zo&qHon&ih^wX7KTpTH07+eYCs`mQ3UsnvqGI7wdijL;2$6ab~{6$6xF77ieq@`yLP1NqL-8u1GPF zJh6xs-9AZHW_siw5w7g-;%~;`H^!twhl}2Jw^I6~E=-uZ@VU}19 zmRQY&(74o8y=>op^-vdaDq>(dtt+mYLmIt;Kp{PS4KSl^FJU zIn214mJ*&DKrK%VPZ}UI5#EsfnP?>INMBDWF~qv&$(UQkcp->i+0OG2{sKMXicWi!g?*oC_g$Ds zIb>RLYZb^lELsu+3jtVRDQW~AtD7<1#1E{t_tja6xm6v zH{rQjINq%)4P1fJvWK=i5pqVqNrBZT7zPX>$SDj$RcEIgy77c@XLT&fUBWh<*LJw# zl(_416C96>JRZKrLq}*OZPOb(v)YwcG_3g$CJA>c$Y#*W&)3AjYXI9(qb;=^6GJJ) zV1?yrefLQM^lR{bBC%{t6eA;-h;h+$0!0`#1T+p;czAe}znzc>siPI%*hKQGxPFHb zH8X&U0J<8A#fc}fj&j+P-1EI`sCDI?jG6x(-%$ZFd|Vtjr$`B2gv$sCF_s$()8+Y{ zwuS<|2M+>41vp#Wu+IZ8l>a5>+1-MB2N36LMfoPA7LCBDMBTcp5VkfoH#df~5HPsB zJh6+17sY{5n`-|RZ0bCm$j;p$Lp`bt*`Q@l5yK_~m0ue7y6glVe`SK>1&dK(JH`l5 z?-nX@&S%9!N(EIjQPPb}KvTR8s2*i#XuYDo-(0$141BOa3@I4QVP9V)U*m@ z`}_DP`YSzUX7_%tjkA{Vwn9_q_uC_dMrKkx4B=#URD;gTgH{Zo32tNq6H+h{V=!Pp|Mc0_LzNX+1bKaZmivDLj6Jz(91?po zFA#r#>c>Y1e_ced8$_Ocy@Zx@OtYX8ATTxBzY;#k6{sBs?u$wHHLz(>2MN{h0W@4s zzVRdyldmy3Y+Wo5VU?@y>xQsM452u^f~CGkp1+rePN#~w+yo4I71pxN_^Pyu9Ffbz=rXm>{5) zv3Sf-OKh~Ac8AdT1_Y+202O}($O|R5tl_{_svNq%z4W;9<+wvTbJbj$7aElSkq!)1 zGH|ih>UUXCpmlh(=GP9s*gBYDkVZLAMLZ#WvPTK2@~039;($O8#HBt0BEnHm>yh02 z#DN|aIIAJ3)QIBwXyKpX3%zf^EH#ANXApJ#XRJot@;m3K_f}Vuhyy#w?O_1(kz5-W za(rA@W@uA8r!tF{fW4w;eR&rS1M1LI15w%b+<;}w1YrlF6obH(zypQvgYyp9Pr#yw z4K1^S-L*;;Vn;{Eo_E%ob;tWl;6*^^weBxy#%Ssh6b~#7zPQL`3>Za>Fh8UcbZd|u zu0Q_THdt!10U|#znA+L?wcWq@0sufgSqhY7Od?dMi3X(=0%ME_#J&(tMR11Xq1PG# zBt825unrP*?yzjA`2@oo&SEWPb|0?Imf~%f2RDG7qjoq1^#s%Wjy=%%?GDst9nyKzz=Q(2=k8Tc_(>ETk0%=VilRC$ zOgd&t$=~P@K!s?lJ|39#Kx-yJeY**|+P6kOKPW3yzX7=}kc|z72s&cG*Y{5+>eFr< zw{ImEIan@t_;~g)Y9tLd_=xNBodFyL@DorlMdip7KQ|DjITc;4H$liJM__XlR`7T` zuK_wmMZSZ2)Y(EM9PlZD>VZ>n9@3@YjI9Iv#{1(TFapJfgP_hB2qmH5iK9WXnj#Z8 zIy({HN%`v#1WhvF%UbjV=`PGn@lwHTH)L+p1W6WtN(DU|70W=V>Mu5kMJ?3sm7#Jj z2qfvw%+6+3RWZQP##23u6f{J~O71YgF@`Auu?|$88HEx@`4(7Wy4l^ueFFoF*Nj4H z;9TE|<3y_+Dk_AH*a8%FvQ~d+K@f$2xJr4WnqH}S0P2=QuP=eHm-AA8*D47v5{YeE z+kLZqpP{jBkp;p$tWcmt<&V1|NQT}8AtlSxAR!PtK>c&`o!xA{_g&8q?`udenRdiYb z)EH3WV<5|92=P6JYo^5L-h*Y*DyZ~Nb~bqb&{bgLWrGMORs8l(!~G{+H4y;&8a)D_ zyrZDce#k75dH1)?OGfv+TXN2{8oNZT0_**c>?Xn6xCs;BDztE<3B19TpzDaZNN}qW z409E{cnKdJMMa2<1$NGsv06ipRZ{PzP>%uzQ+uI&-~T-*T`B}-A+w+!$Wnobe>ctm~|$g$tJX?K?@SM{Y4bj*C;^~F_Gf*wY2z}pw$mzrDQ=_=)X{t z7NIxKLvz(mK$Cqi#A)@52O9XR&H5K{@zq270SLiF;f@T1A|KlBP4=n+%^stC2YQ}5 zMxOn7?xs&^16MSoP#~uwc+>CdgWmz0)#Ol&gJ>c&3aCm%{k`jBQ&R*n|C$nkws*)g zVsPt=mfWWzxYnUr4*LWt^~wRMtZ`k5I#mpvX3$d>r2P~h}mm;v^PMozTeS<#_yph22YvmU&b z*10WN5E7_V)YP6!8WQ_6@W3S$--PJMbLi;q5;4G&8KE|BLud;%I3SJ00cr&x zOwh1eQR6E@4sc9hbB11#WwI)!k0m#Un*>#%P=;4gL5mLiNV?02y6YoAEGYhjCSj6Z zqP6{gpQ#0oT`MGKP@niIlPC?S)fk<0j_1VCw$V=LeY8D*MlsNw9mnO%q{%r$MC)PrW;zA6aX1HXT{y%@w{G!xd9EHpn-$q%U*%1;3@8Fw!i;H9^5o$uavS!tK+6an}w@0N-JPa*^8 zSsCw}AA*McH%S9z{o-w>R zWB$k6)97LMJKjo1(?AFU9Ve`Px*3K9WP{NLCw|ypkqUu}kC16W^WT${et+=5MT!A^ zzcX#t=x3b=+A>fG3xW*``W_ueC#TFM&-fK}3>{FWrGesh@b1=ED#x*C=A+!49Gxe- z2Y+#^@7}CyB^KU@29i$}2o2Db%y)^1{?1SmI95wypa6!#&ucN5I8NBOpQ{6xBma(e zh+5<3lC^(M44CVB{n#K7h9QUnH`UarHHvg2ppP4l)wlp*qW15wr30N*1}p@WZ$jfl zU52~WAXg#iEt;B{;p8%@Rsb*XT36v=`BJE%oZcOVDxffMphHMim++a0*He}lF`#y$ ztgLKw_f;}HbWEZc{Xi<;&t)_4On)EQQo|ii5YM3K3CS6Qp<@osMqtB1gY*g|x(D87 z{!2|CaWCMdp!yE&x-AcWJ09~K2d@{4wuug~(|9ORM6Q6GN2*) z2UnVPxiIL-rc(i)!#19W5|K6HT6KqSpvIuLA}hfEyh87bR7~pkiQ3Uq1LYEgVj~#oqN5JnDLmI zIj%%ZeM<8Ca!+lcCn}zvVlasb<<;Q*q-hWIg6G@p>518~255xDs9CJ)BBgVA+Qa&B zlg%yOey4%}r@l@l7FD+jM|rgZ#}Q8nOlz^wpRTpt>2AN{>j`{%k!ai-ARG!rzlyI( zfX;XsmTl(3%0tfU*L%}U_MJJ2am&ifpQokSb~DI+{g(_wZtbBfO9h6zp+TTDAT$Ti zou{F<)TQ{4WVhgQ^uKg?>xsS79(Hm78nsSIPM;OT_J-d-i30QbCI$m=>~KNFuLWFJ z6ji{OeZQQ_{&w9>DWqHGT{}I9NMcX4NP~FwYG{*ljDSX=388g()5ioHZuxX6A1acN zs(-G4K89*7^A$!)As2~p!A3FXABG_Z=nbSEqT+#0Onvx#l6xeoWYNKBwqyip3KkI< z!dHo{`x5)}Stz<(4j~8mHS`LwP3Pg#eFq)cK>;$aV}qRyPOQOSeeDgo-au?pL=$}b z?&Y1M3)pG21FJabl=H2Tm4H6d)$R{7z+(D9I<(Bb`}~S6QUs3_-O-2i&owX!|gl?B%A2lldiR02G^5+3MxUn0dWZaCJt;`qh}V*|Ehgp3XmM2 zFTY(%LW1j;0Z8l;>Gj{j=27@HLVyHMF^(xUkolayi(dQFv)Ao`o=*Um203$Le?u;} z?&&CKD2E`Q(Z#sF-P8Kl8&3eQmD-IV&8OWZ?UWU^2@2w`u>?Df)Im3IjG)W4Pk&(<$STGm)0T;;d73fx%^_!J}LJWFY9OtX#oKvEr zqOwTL69QKoB*E+~c>mP5W0)dt1 zH6sb6x~BBdA8&U9YzK`f4ff~o));VJj#@u`E9ftUs|v?j;BueAKd(DJA`d0=adLg> z4m_4#jTTT0tP8LBakngmIl;s~MKT?esT^oYKX_rXyK>)K&RH;rjW|c!qq+@!Irh7f zx`L@-U4=7+;6RlB|9}2J)^#3NO930@_mWcIhM&SlNSZpx&HTRvLOJo;3a2L&caL&7jj4X@I|<7q6Uqf|$a)#aG(seDigFWNJ~@h(5CL?z mKdGVG%m4rU?{zqqrq#W(h96{%5C3NiL{VN@uIQ#=;Qs)$&$AK$ literal 0 HcmV?d00001 diff --git a/images/tx-map-1.png b/images/tx-map-1.png new file mode 100644 index 0000000000000000000000000000000000000000..42f3d3e8b06729e49f5a35551b55c9c996be9cfe GIT binary patch literal 18220 zcmd^ncR1Dk|NoIn3r%}8M48#Li*QQF&Mw)RIhhByhP$i~8b(6)O4hMcWbYAiNHUI9 zI5xlMOW*JJb6?-@b^Wg2_~$pSi`+QQd7szo`FcJd>wQ1bP*bKpz;pnE!BAsW6g4rJ zT~!ziMdrS}@RQD8N3<{)r3I|wC2jYZnL#gi?XmLZ?N$T39+sm=cO8F5C@7tot-trk zzs^ZhL%!>Pwjn7|W@2DF@wfJ=`cL2HdU0b{g#sLB8R_g~@3p!OHVW2C?1D?-9f|US zFBo~Z(-=w&riy#F8GNVz2y+O&WE}RRz+lWy?79HoWM0O=wfpJptAcNG4^S|`7u{3; z2mDc_N(q$)f1*$^`e(Lr zX<^%}+g!!^EKlS;Rg7oOjYK7nndOTiqt@i`=F@t$pEK>l0#6@(IiF4G_4PX#W5;n>>o-Z&w$UD4QICdjC44u(q_YiEGmA;s zt}DwKb({(Jsa#ke36F{GrIb&3A!h%I=RE%;1GX}9Q5k!UgEh5q-Ycn}d`Vqp?Lm^c zaxl}_Oc^_7I^U-AT}jPj>Od7q-43RL87sE1#hV3>i01c8H}+w(;Z zIq-`10wP)AaoPilpN?bQu3pvF)>i#uneUh{uq!tQmTOGr*QaBTo<4nA{ZiHPWj|S% z_-xTHN%eG?L`g}>ssncOzRA`$);2pem0{r9w~hPu_Vzi%ZGGX!XKE>|*apk|xPB8q zCMsICjqoHTEc;gv4|gd{AA1Dnb?&IEXH$H)x3)C~4mO!~k@susYF^UR*7U`O%&k9a zXlM|)D#`P@xd-dwxgJRCmo04Dl^V{0C+Ej!MJ!rixs(&zGn44B&9;rcrV%3iY@v=i z13~kZ7WrRa2-ZI3y>lJokdj(ReX^&m?Sh8Aa5bNl0F|HGk;OJ+_mM}<;U>{tdYX?o z)Jxaqgu-cB#uq{@gWHePhUUm^q5ILAcuxx*OB}{?l zA_r4w-2+OeSa)f*Cv~IQ9Ht$1uo0?Qs%xI^U*B6ipyM;pW)Zc0uGf-BxiVi0b$m5h zvz}4tj!I(EHIA|0s~hUQ*~U_L#;?nsniLK<`Gwyu8>tC!j1{tYYE{FfA-2~{-JUA> zhpnw`A+}*=BbJ^S6PvEheKCN|)7lvdD2tDe&!%9;(dCKa>9KVmU3>e(FK_3qd`RL8 zr)jdxuTYet^TS80a!o^XD`lC0u9 zYNHozumRYqGimQDDz^T9_wJo~n!TyEdC{s_4mG9Nhw+!aNz815e zN+~>Ht*d-G%$(yaM>#BSP}2HYywK4nMj3_o+u&_6(_uLyIQx8;EPFC{ohsnl|K7U& z^qENwY-QAlsn1tu|>AO>w1+N+B$aHon}N#A~i<6yoi)0%g%-D%($9_|~X|FzdiV0h<{?_RV)A#o5ckJPj zmX;hh7aXWye4M7dnSbC@T+=Jj#;mNY;6A4hXCzIbO`^__w`pdYyJ_Z&J~<+=DTRe% zLUuj8cK6=UG+TiftV zJJ0gx*`{w>U`(I@?1I{1e`U|xjG-?!LHp@L_L3jZP^~}sk54Ol5?gN9$nnIAB+C0f z<6VjFrhPuSa{v0gpC^PV(t6%iydX7y>7Os7U%A=G=EsU{k0t&^`}9AakZQeVZKjTl z;Vp<|V(inqE7!;V@1MGka{p^XbXe_~DrYPjNA-7HDqB)7$I|M>wsdr|(c=gyYF3jr zp@EWvS}FO9AL_2e&Zbe;3)bo{bI>r0@&4XeXdOSx$~k!pn}YSUnP^Mcy4NbB*BAXN zWb{RgJAYc|0x5S>BVZ;#axA@utPmSlxaqAgNLj`nUY|5d$iBGPrhvy%v3O1-RFDWi zA5;h@wghDS*O%

DfQ}R&BZKl2k22U13gwLcp37`_`>+6XL3|LIBN@oJwri8D*vW zJ*zQE^lm=AU&79u>6$FZ_4%a2%d!@-PkA$tTzkl!%oQ&vhG-{UCEdrzu1T7WFO#FS zQs{dod1YptZ=`rlxkkm2i&HygaFW;5y^Ojh<0ShYVZL2_8qVbAlM?ceAIB!A$na0O zs{hAAg)Hr>imeGdKDZhyN$&dZJYmlnj2oK*D-Y?vzSh4#DQm`&{}lwJ*dXKQvLM}h zo-QziBc-GSoy)oPY3}Cc=8*oD+K!P7@$SjY@syPA8?;_=X$q`U8Ud1BlP!``rs~8w zV=vYL%3S!{)l&+Oe-t?q9ZY;y$Gmyzyogr%^Knn zIG?%@*7eN|*ZZ*)lzV?LGcz|g3RK2~DkaX9s@d7u4K3q^orbG63hf6DNL6aV%O%j@ zQq6T>&cvywbb8$M*1ecPIe#mF^=B}H;M=w6$__;T7rfK$NTZ+8&IXrELx_fbD|<5(*-S+oC)PM%(@#N}&COG{yYQBrZrZceJRJJ+9$F5Ad* z#5Zn#ZS~Pz!Qf;UGY?h404w=b%X|%b;HCp%@|~{{eyO{Aj7>{j+tf6Nxbah*F#W!f zoS|lH981SL9Myczaet ztz57+(qiUtA=lrx;r+?Ri$A(tt#~?Y(?fXv67kVepJXk=#gIh%fx@(cg6{h914d&ix||gp96K%&BP3<9(-a zA73<>aP4~^rlOcldfa;Lu+al~1MbKVP9vAE$IBX@IB{YwU5h*N2VvH$XZ7Uh{;6q} z=wnY5$>Nx6Z7_^vT28VCEDUXSRL0 zx47v7f8$L*-@aj98`M70p4cd(3Y5f3cbuI>d4U`}D$y|JvbL1toAvG;XO@26cjF>P zVM|p;CEzc)ZoAFA%`U||;&26pcfY<(Pv^$k^U(qp)8~0wFxPF_I`UPqHk2CD;%5rNrBCjSd>(sqi-a20EoN2EPRLb}vCJ3*|OE=~b z2c!Jd^_N0d;0m88UWNq$R-&h%@L-KRvtD64V;|MWP@^h@!Axi;9q=}*zL7NPYA_z> zm93j&k~P_xLR#uI?R`XVlA0JQYf$vfrExtwy4kY3t1IcQSO$E!N@l^wT`}ftrBi~; zK-46u;CeqfvlJ8-UJZu{pQd>F6mdCHg+s)9#mRoC%p+%+Hp;;6?%ggw3Q7_8c{3ed z-SqeGHAO{5nJ$?5ar5xtKJMq5Q1@MnNGi;40nRrqU~n>5{psho=@}WgZ_ag-NfBzA zc6J#;FM}*wV$w=y3D;<)=j9n(mN_K!v){hGtY?ZZm@QjSGj?sia+Tw#LAhta@71yv zNfPg%@Af7t`o+ag^+w!aIr$*)%rf?!ZAcAPJZ(_ol5A^dw}gJZAYDHH@t{H8?MJnt z>^a`D0>ouvzFHe`psz1=iPTFPen1<=u{j?g*9A+IV;(A_OWfXCUJ48KR{VNbx83@K zAsag^>!9^tRkHgno$i&y^kf;Ppc7G1VN%OL%`R)CF0<5S(z-&octl)Obh1uvEAMum zegFxcrjn#rxfU6RC*Oo-;XRyR2kTHqzw3f*?wf*B5%t#d!_}TEBLO;ET8ZAWIUWl? z(}0u^)@MtXJ=OMl(ih4CADY9l%wVZ_hXy5QP%L)qr{k9xvXdWMMamiL&;#bB0;npUwm z-D2&2FTvV#N1seY89KBtS8n46q4|d=S&O8zZwyntl5l?OP_b%heE+M(t!)9GOBmz8 zZ7a-OdCU;4muJF0nvSU^`e$)u{~v_x+j%eGqbJ)q!_j+`nJ^Y*=sJ~_GWG7YL&rz} zJAc}Yd`bB)Y4utLm;;wX<+h4lN{m({65CS^3=CYmb@Xuc_YRn~o(@y#izh~Ibu-_= zOkCYPyqTLK-*e(rR?2QU^B|*Moom+u9bgcMii^XhvN}~!g!h}Y>1G?H0b?;l#}>;K zyC`6{m#cVR&j#P|15fKl*LsR7k{cSX4!Sh*jaXm^CR$n%-b6hSCTayIr?rLQaryb5 z-j2O9lWyigYfGdQZSJLPrqW&tzifD$$|Xi>@DUjqIl`-yr>`ycS|?3g6Ng(eF=f~_ zV|w_0rD`}7BzypQAbV~P|0XXHrmk>AH%b9t_LA8J5p9bS&4QVs&jRmHoKhl_HybCRAGUrK*yqp**#&>b~94 zd!&|c=k<-eznpM5?#}6#s_0Y$$`GnO2fe>|W)|nRT_W7uOl=Ya2U*9|ls)7;41-|t zAr0lm*8mly5oe6>u)E1KCW^gjO4=2@?@!A^MBG)|iO{yNB^zaO${UGr4OceiM%UAz+h;ZFV06M2Y}LUt?fp{7a=4@>bJ|GUVjLHcL~<@I@+eRl(_Wmt-0+U z;a2HH#nVSxIH>*tiOZJMleIRbSD6k!)`DJvE&|tq<(dq?#@`M^rNCiOa?rK&I@&8b z0h3IC216LiiKB}cU-{~wA1?&WMQppy@#*Kv%K`f4z*eq&77zi|4E1QPc<=W{z1;(j zm09qgngs;~Xaa`FZMlnziA{CunRZ90%ciMtyxrPdCjkKNhOI}h*WJ^@9j0OpZ`5<4 zS$qlJOZ_r_XTZ_=%v182l<9NDxxYnY^m?51&EVkRk-+x+R@t3eOH>Z+nM{e#UR@X` zy|T+*jkdBFpa+=6BzV&0}aS4bY1MuLQHn7(mzcXkFjS$D*U7WAOgYlNPyc z?@c)5y--_8%nrquj&Z8Cm3b^^^U_`1zgL5^nt9wjeW1fip^afu4;-{ zSqa)z(xnG`)AI7dwzn~a-Cj}n!z^E%*Ctc!nqP@}!V_{7G=Bt9O$U%us0{f9!ZJMB z#h2s8)3muKx7O!+Q*R`4V9}cFrC~`0AYYQ5AvIg90B?y&+C5jyafl^5^O*_<9Cs!r zCfCiSUeZ)XP7j>KvsgGjdeUsY>OQ}ZHNOy42p73OtxwG+tq&4oIEipez{Tnw3mPMp zTT3|zY@OiIbuAuRkPc>*x}PKJ&-T4jP3n41#acQv2!v`k7gOY*Ux-pwV`LOz-T*v; z2E>7r*m?u~;`;UL(Ab^}Dz#gS#9X4W3i)$cPjI(Piz*C?1Z zP=x_0Cqq8p{w=LOP-uU!E~@^{ouC`gNYk{Z!f|2`LPenGeXwYxg8?3par=kMMHp+O z2A-U6=A_H>A75NehW4HajTo*D_~t{qgS1Q{DsU|Gty-f`9neH)ie0jUd`JFr}+QIH?u->EkbXgUrGl$~r{`1q1Ie6o*{R$3!j z6N?bIU>!?hFthknh}5hG9$y~k{(b-1qx%g`VqEuI`Ym5_n%9N7T(R2hI0g79Y*a#W zW({r~zO`8waL9ILDyR`V6ayg#Y0|XtE$IsleWM0K1|ul;4{jS25={c_^JkNKa2kuoxy@vB_NK z&HUrRN;pzh(d;juT87WJ1=Pl9&>Cvd;%Lkib&Gsceq-}wXS%J#b% zi*LxR_;O=W*)2h9u&EC}3)}Ug<>ELCa599#px3zt^rQ}Ndxd7(9 zG2NWflN^t^x7b^`r30q~q%|Wu7K|h_g**EmsqOv8I46MlMROSYZZ3`3QU}rt^n9@C zL>nu!x!AeZXu9>5&#+L%*6?apS{hc<@P*GrLV$=D`L40^=Mx5%KINyw{%(;NJ%qJq zm-)HiaV7CabG)1>v^OTf+Ygn37!uIoLwy5AW6i)G+=H{7{zNIm+{ber$=7f&pC0+< zZ!%SQ83anK$j}8&t^;1L+>okPJ>r*rg5|mA*6KJZw}z&ZJTrjX_*IwTNUV6Olz26z zQ*yR=RQtvapfTMY9jEJ@Meu8`GAqLmn8Y1o_=|`AomSs7JC@xzNY4-0p#y-s&T2(Y z4ULp40twL-i)TNNIwO1mu1>Z8o;Bd;@8B3u$Zd_vxk8^wFD%prKEJU|)pmAY)%v-< z^P$Y*YU1CV9&n&FEb{>vj(TJi@6EUM5nOhI1YCM{wytb^FTf>am0<0u9+m-DApqMi zfaPSxb=@HRd}a4BLM6tzmT{^#Cmz_-V_Np?BBGCB(U4~b^rH_hV^^Vy`C~R?WxVc7 zJa(5J8d+|Mxnf`Wc<%XmEfI%r5xYGr2wRbO_FXkC(}>ty<`YN(^`vLMPgJG-ArGe0#}TaznbJ^k`wjt zXo!>=>YVUsxU?WaCZRijBXrTzqYJP4knbAM_G=PiA|ey-8~L^PqqP7n>F7lA6DHm| zMO}=jpMc_|j+U`=aL`pypd6u>k3NN&<1$y3h+uqJI(%jW;l^*p&a4h|>lNYkKT4;j zWto}0KS_8lTEqB}EX#cNPDyTKgjVXCn7(Hwe(=rblWkuGI7)Lyq@dusySr_GslF04 ze~fTdtlN;soQJQuYVps!x%H9#vfe~m)4wTP1xHf?V% z!3j)HO$AY;7Z_iS`lJ5%hgP77h4+(hNZp^_w~QtVsARY7t~lXyrxcwSF|H?e&HEhi zf0IO$z}Ht_Bu8yM|M6MtxKxwF-Ym+QIp*Cx!}3Q#E}_)&A1JIGjGLO>^0Mm3Qxj2@ z!PTVzqAs}mRcOqmqCC|9Kj{5^`3PmsOMBwM=SCd`g zJX<$BKMxnmI!nJ#EwapOP{x=GxAoc;)5pBaiOW6b>($l;aqF7N ztdECY^IM;1qTb8ow?8F9Xe5R)9&z;9dq>uN0-W#BoqIFBpXN?*-DqY9W?10~CWy9) z;TW5dxbt_#^4|?SUPd);jx2RIBx8Fb^-R)WGE4vhg?<1t=hg(Puw@Y7w8YB^RjL=- zYTznm*d`8O*!S)>D|4(?ehV{9^84Rs5Ds^h98AEUk$7PVP-SjP$DwsW8XEB6{Q>*% z`^~yJrj->nGw@V3Y0v&*dpdt`xaKKb3gCKhC9j7kfliE09AHgEkr7>J90Ta|W!Y#i zp9IAh)9tn1T!9NK3%28(e$U+YFQ!VaukrrzdzoU}Hi&qRX9d6~jG0HAEom+!i8>`zlXC`p<)|Tf4u)N0bCOmnM9+16Y z9%SOXiDNWh{M{&E2aQZ}eL5eYw%R@XXv?=-66)^7;1K&~nAH0O@$(m6GiB zIGpSk_kLoiufQT*_3Nvc37Q#GDf{i`J^h$(K9(KMF-|iE)1D6Be-#7el$DdKW~y2@ zLSG%GS_=kHOc;x?>hLtHhgBoLe z{)Gl`Stb!{jgkN@-JZQ>tqbT9g4yLvh+E{Mr535VFUy-Qv>A2I#zk6|DU$g#BlPT+ z)vvxXi`{L53wB){i;nhE!SHsrwY_2AUa1>nQ$iO^>CodIvn``vq9fJ;5A$)3}G?MOn=gl*uq- z{NImeNUTa@FoRVL$F`;=)EJd_`7xSdFob7ux^7x&M|I-Ih#1IwLymb zI)jkN zOUy+{fI4G@>>xpqg<;iitu&3f*jig_+`E^L7zrX6hJ|S4A56Ksg& zDS&CeNiM4FPQpfXRr>nk;c~iAJA$EssB$*R76zW=#G41ena^So_@I$l)IdFTtwFEi z?bD|RVx2zjCoB(n6_{1;!b7|0{r)*n)OA7wbudk#m(NEfZ0+s4FHx~3y>_g)xx>BD za)No2yfZ}awOj-e()ENZE){tX21O3Bvdbl{lk+vSz0Xc5xXu*xaz|dpdb%<1ZF`Nv zJ`;CfTf#rsc5{2gr9f;T10-?#BcpYp(c>Nl1-6kK=OgM}Ur;~_Vu!EB&Uq^nH)q|t zzkSO@yccO;_ow?32n0zP=v1EMuU0rXh<30E24K{J0t4#^%bsK`T!oJHSF89eq-=nA z+bXwR)*`cP1dMnpGry$+op@L%1Y8k%<9za9tgY1fFbfFn9APSmI=pTMwM%Gv`Fctx zya^DU!#QAn_LaU?;drjXaVMz#&7}umqd@V10+(I(`znyS2_VYtp+1Xez!ta+ks&aU zTm}nQv)-udhl45#Z47Xcgwq=XLqqr@z@Rk1ERleN`VtK&-q`TD^}!WYiow90W1_-K z7lC>l@7)_tEGac(9odxKU`rw4JU#tm+>n{r#n;V`shSzh5nlqNrK6|U$dCx(jvgr3 zRd3ltgVjwg8W{-*mn!B+pXp7zzLng=)liF1K*R6Ny;Xx|7uMdMMc(lW#IN2&?4e3F z_Wt!5RXdm3^P~$&YB3TwvPo0l0|lbG?zb5pwv}n^1ce3^teS2%fO>lmF`Vqh)qEW+ zu zy~FoaA!Qu{R{^XK&Z*DlnhnfG$%Q6iRFr6jd4iO@Gppd|&^n(52}&+?X^DcEjd%X$yaV`}^pzx0d^v14X6(GadE=_g661ED-F8+QX%e2x2ESHpcA3~5II7u<;r`nQH zXw8)Zh^5my@F5bA#2e=3iE0Iy#fNdthFwEuY_Zu*POp0_1x8iJV z?s{O)V#q*1^okTJ{aXdAXJ*ONK_ zn=H3HGfr@*v*1{)FJd2d`x z;ZKh^!05ED2cu3MoP{$80&zBBiW?1J&@RBQYqwrBPLXohc7um0*sqiPF+)B^4^8|0 z(Mgh31RJKGfa|k9IyHLzKhQ6H~h3p-2*JX;~%`?zl|EKebd0X0FvPlgL$IuM5 zt*rdIc@RSY6-)ZbQ&PVSl`S6QU}JOR%9TfO^1X=y%TAa@7|4KZfj+{=#gLi`D*2*) zA02^s-@AA3rLvYu&)#9EeI$$n>?_^^3Z@K0B5pj=OCRHT(L4yA$ppWogUDx2Ir-Jo z&!^YfF@qnSS&-5Sg0#T0MngkC@=n>jrUh9c2!uc&uvmABU2XQ>MAVo;d-(1`yT|Ve zDAG`;$bQ1lhJk$r^lvoqo_jF>&ce{pNZ8oh>+JZ% zDYSt976F(oO?E01S6kc~WS+l&FNUFlXXiKyLoV#^C3Oh#OpFByavwi{V9M9>y?{ae z&iboYiaQQvg05NKlz3j?A7~?2K9^=5O&*9Dl>O)5VPvXG|B)T_+cQBi^v_5suRQHM z|35-9W)z-&ZvV`Z9&Dp5JNS=?slFfEu<<{Vr&YTaF?0V6q|&{iatE&tR^m@iHTVCJ zOF&VOH~?2ZU?wgqA%k9F=m>>AC}rR*Fa<|>or6m@=A59|>Z_A|2T#RGK_P=6UB~97iuyec_$gp?$o>j|R1Qq$6(mo= z-Z6?cUy|CHajF24+JBEV?yo9@JPT^K$Snhg2J{h~S&O4(dmRS}I*`We0N*MZ)LD-> zz1f5%?itE?$elFE#K649P(i0p@s?Ge6M#QCz8hVGJ})P6d2C&lqBw%l{Ns2JS?m~( zoS_P51ZY8^8~Ya1n8?NpETqCxU310J4#ZpWP@=7#wy?mcaYi5v1QrEd+`$2IC<-;- zy=AeJRW64_#wFT$F1b~#C(7~gn*ZzPD0hkJYi!sFI(tDlc!xUXMn~>c9T_gPlM?8a znZUnZ>Kzqio=X|bhnCi7qYFS1$X1y9^Gf%BN#`gaGaEb%h|+arS1~_Pga!yMsr!It zT9Rg3S2?9p^uIl+pA48`prY{79em&bA`2L0fH%&bKU4$O2<#)Ep>Pn`b#B~9fOPAH z-9@w=bD~;hMT|eoja!=TE$0fswfhaVGMs5$KyFcv_ZSa?R{%M>K(|I}F?hyNfK+{! zW(M>C$M0+~gghpJv~;cf8bx>wqAW11<2t~`=_+zGg+K$1a9y?Pui30)K-i8xDdQ1Y zuV7arfO~*FV7GS}q}tsh{FWA&on`QHk4u3GV+Y|KKwi+@VQ2vL1PM8O+@s-+5EAnj zC)IropuRF&q!&~HPeMzaL^%{N3$j6khAyhjebzh(hy<*FbSo%Vx1PZorsw470j7qg z3^?U&dn$A(Fzq1X15=72m4}-fy-7fr$(=Tk2~ZDHd3gBSqtn}KoUrrkYCu^cjDUe5 zbdS7zP+??lAX2ksGJ*#DsGug~;|dP0}&)T{V?0{jlS zj*{`X9oZNbuQ7_R6KM`sEi9ma!Z|{S73iE?7Z`Uhg{^EqKHTpKcGYuL&L!x_K=>!B zC~3Puk;MU+wH<4SL>%TLU626u=N)7Zx;cnKPKAuIb^VNHs5B=wLB@j%Sb`jsi9p%B ze~{oBaeLGBkADui4zO{Mj|b=+K?jsv5hr?UfyRN9D3-eR^C>ZJA04EJhXF>~oN@H+ zL@pzedDd#!x85MveRF-e7Z7G9)FZ;`;)AXcD9eEqc~5ZZ7Q3|6cbEe@)o_KzUNZ&g zZHe6bsT%A4{Rtuu5NYD%Gb+{q9T}uSoj%ULT0WzrKM@I=2(xB;YZDoyiJ&FeH1LPuxdsVB6(NfVw4t+DaNs}CfC%IC zv-l6x6R22u8v^JDIj`W*)G{E{rttVs7)Nugl-^E>$*$j}W|h>2GK2#N*%UuOxQKP} z8GKNAu$NlX+}u2%`&^qxW-J9NU^qSt(jX^Xe{tawEb8{$_NH9<+EfNYYXAV#V3A;D zl`Gc==R`nDLz5HG`gA2k6>dEP%&?zS_~FC3=tkf}P{oh_y2uoqo}7FI4lrDwo{{q- zHHnek$g}G;x)%(m8;AT%K!dMjyb2M*>oshCP(h2m9#h3WA}cOFq@NuW3Nz5!hVzfO)M5nOf*+5Bbl17^W!u?rB@N>Xhz=qT8B8POWbQ1iXSeLOhlqK_#|P9w6Oc-V7LIaM!ZQ)YDNSFevmH$ zKo!1d8yaRv&6R0|i-2YawFzPe=tB@eBV+?jhH(N(7#ui&88GNxH#gvnfhwIl4h*~t z?&R1Urjly|MpSeE?_LwH>nSlVPltTg?KgXUH>24+ejEW4N!532A%4f7^rNI{gJ$*t zxN!?h?Q?Q2PkJ2mXm?4QBSWo~Y zszfcD7!Z|5j0kz+)qChCzTInu{W8ck`^#s2fM^TO+gj-M3T-ST2hy{$bnti?isC?t zS_V>24-CH+h-v7RSe6% zAdMyk>ftb#AUG2*i~o4G$^R7`4T#jh_TN%>c7nnJ6NILB%N`!Y84*Uh?~sy?*l*L_ zp|Ym1>e=sLkl#iCONLpmGQe(kXzG6B`nykdqBu@$?ZM^Q+P4A^uP|3g`i_4BxU-L&FpwX>~ka z4-_^qHd*TOwgwNwo|^^1QCl0A+fD=5&U&;q7$hj5xZe~=I4Eqf*WHlc)tyav9vMj? z@lq9bHP-ug{aTZiY+`@E0pyfQvLpH00f_E{eFekCbFp37#&-fxiXyVBQ&Z0&Zqfju z_Hs&?!o4u{mSB_^LV3|#OQ67LSZ0%s`jq~?qv|@A{dx@cnC9%r^T+}UiD!*tsHC*H zujCwo)#wfqM6CwQ#zj!scbE(QJNWBy^?3mRTU_bn0j{yfpYCte zRv_^TTqjn0_EaSGKN&!kGYj+%6eU9fa<@#?{}=q>f0{)-dG3Xg`Ad*<1Ay>E@E564 zeRe-Q5fvLqRdefOY&7t53;(J~3ALBX9b!?T_-S(pbX45I(dI5utjrVlN4!h~XDr6M2`PabO3E9D5yo*9Tl^6Eibaz3cC2-uv0qj>0O&##w-b zB6j{bZ3jl6$^}1JXGiXD5F4Rul7*-z4C?0=hh!eX$!ObAxp*L%=fQ?5%$3PJ2;k?q z2b{lKKb;1DXI^IBJ?s*akdphmoht$hfCc8_O(;xF@I%4CD+z!G?B`(iFE#-e1i(E* zH>;y7O$&5JP$C;-c%jf;DgP6H_-8LtMbmS_=J%?1N<4oFk1ctxZVnhwdlu1MCj%tn;_^oLMU6(Xq@1{P&f|1v}lZitj&3* zV1SY>-aOYRFUV9u5tM>Q1OQ_a7y}5;U9i5QU|RwD5|61Dt^Kl$hhO4~b9P*VaO86v zyVRd0fCE|Jxnv97ekTdJ1o8(7d1D2=CK=k?C*r31mhk}4;rH;elaSQWy>{(j%4Pm# zSUHSmK7cTkWtr(OKx}iCK;j4J&>SaY7{R5ko1pP*RKiQzteGJZC?qz5bMm>C8f4m$ zMGlTP$L0vF@3XmexTPfkC4C~Vo<*P$AQK9(fjkPhL)2+lUIx_5S0XmyaUMSzVc;7O z*KEcvIn8+a0Sdp2?f~qsz?VXkj)!y8_Sye1%M-=Lf*kyH_SG-SFkF*Sa0(p6P^t_d zNEyfD99Zz3pnj2I$w1zBO_M)5zk;@}fo>m~ zg7Oz7LXNepL;(@3-Z7rIAh#2&1PMiu!cp7`#&=IoPi}lscDC9tcOz)!m%hUOjXF2S zT-2hK+sH+(9z^a@fS0gI9$0EqptXS@5~A>Mixkh!NsxCNkeQ#|D&4VGAcBD?#s}y& zC||U_Mcn3rtOqO+d}{|m7{cn$*Ek3rr$KfA<=r3>^ae2LPNsb1F*C>cn42wkgdm|1 z2tXMbZr6@dRY!VZ#;PPy)k?vQ6rpucnkNd`IgaiJ@%@@Dsh1Uk4?fUYCjLGX(grgQ z_ajVs>V1k>02!2CINdv^#zY*F6 zhL!=K#>jsrJtMmVW%JPS^6k}ydxZ&{&+Z6Kesij!PWF~1E`K~I;5`ceWDY?|!QGWT zGJqT2*nvu;!m)_Li!f(H_)DjS0475Z`LZ+cVCMbt41lr1L2o(0jG!}e7j&E9b>Z|t z)jlrTzY7P7YTIjYt^z;*aXr9eZ-Q1H3z~LPcE#G%1J*hlk=o+$CN_3O0ShSdf9s;@ zIvGC*{5z-o8ptmdL-L1JlMC-Z8tlb52$|-b-ftQ7z-Q#-ZmQlrBYK(vFNcN| z87cQ3%H4`^{IjbUe?Vix6q^-_zo@460f}xZ1dTBxtmOFQSD!tML0vvyve&=xSb$kfW)V?R`te zJ?10}g!(V+wC3ynLxWF_aoNHw3s2f}kZ!{NAb%TVE6%6Q_!R~66I4JEiQquh;t8w< z2igMZF|$M4rzgimAw7!jgh4#K>7{Uuh7m8FC`!ISsYBcdVw>Ip55Bk6HdsAiGs9ps zXsVkWA?zg^k4!W87jkbfDRQ-6?yzvv3Zw83u9KRm9ilAk7Nij;(JclLBtn4=xE>d2TPstTiOq(XnU@U55jbFg}5pyua2z~;x?kzZ6~2jk<0>V2pHe2 zx-q%2krXd*sH>>!Lh5j9aHoTvggDnu>{kRb3{DsG-)ts;$pJSA;1}EBN`-2Xrta=u zN=`8@geQR6{3fNZGxP5HSfhXZKAr zXI!33B%dnWw74W@RNA@4A_G@y0j8l-HSWAFZ$mnwrOS*e;gW_-7 zt#Jt&7ii+CVe+co4nn;IVglm!Ac*Q2<8=B6Z6>gdV3hOH4UAfVNC39-q3SuDaqhR9 ze@t``PimY$*d<&50o4WMv$!q@XO#c@sm;9lr3p!v&u^@Mh2T)3mxNCa2|z!PHL%|M zmK&L>ye!9rFYiE#^W?5Lv!ML~j@t{BgcjT&P4p3;DH;^cP%h9hd{wW0Y09bvbWx{req9ETh~uVlqVoTjf3L9 zSqG?=tnPF=2>8!LR?$!g$mAfEHr^jDM}$HWkrGH9H$;E(!thW!fki&!crM*A+7+^of zQ3F)A?q37bG0%J9%u=VA*#16Qz0R4V z9zszbamok4%bK_h>(*=PJ4pOs6QOnPc#KMtv^w0=_^+bbcz+10tLiBDA`lyf{>hA8 zLd8(cU>*~zl{eUo^mf$*4JU~8uW(|UcEM?MJyOS@71h?OAQ8Scy)mQ(x0`l6eryKk zjQ^GwCTdhdhTpn>%MqTpEi#j~YU*Zw=s=A|H~Wp dZ|2{|cK*#*x80SD;B;Ux*ehy^*_X}y{~O2Bi5CC> literal 0 HcmV?d00001 diff --git a/images/tx-weight-map.png b/images/tx-weight-map.png new file mode 100644 index 0000000000000000000000000000000000000000..45f0d6609cae95c9e15936ba567c46b8bd3acfb7 GIT binary patch literal 14542 zcmd^mc{r4P`}c*4x|Q~%q(y~7M6xSMgX~Mjo+QRn7_tniJKbfgk=*uu84Q)iGP0CV z#FS-hp-q^v6vo6D-t+Q%-s5_VXozSeZS}TJU`3nzOkY1#tkAH z5CqwXxp2-DLHOWX9&>?paERlvIgcQx<1y#XnBPp993+I;x}>hGu<>43k6=1&B%g#v zRz?;ZA9t)a*25fQOMCK2Zs65$)H(A=uST24P2$O(8`e4DS(Iwt+qhdD9lUm0ygMvM z((H<4^b<^v)m%IhSJn1Dk;>*Y1ee6IPz8(8FA~`TkHMEybY3z=&2gG)iq(Zo=Z$ zz+mdv+mrXe5piT6Ko7{K|ECY@-3P<5i7NQQbi@3%j5BvU^!4@4ne#|}$(+}KTKPR> zT~a`Q375jU)p7}Uk-XswZ}$S5LD9I* zC*oG3O1?qj^W5Cr!|q;QSAzu{V>`cvHw_1bwdwUAlr-%rzb=ajF4A2otzJHZ_dH~C z43FcVI`VtJf=;{Z~%@VJ^1gjSyi>``46< z#s_YH8S#lGtII4qO0GONw~@r<3s)b`*I-E++3}w|qPJL;v+{WEVGe=1OIgn}l3IRO zNM9tsqfvM0dEGjM4R8DU5va~u~so(L6p~ArDyV)p&XH8t2HyuhPVlCoe8^@OO28r0ECQ+8yHAg`paC*sxfv ze3!DmX7P3DdN|+W`4dKHm4oq+U7gPUp&h3IK?c&xm+6#o~~K3 zF|E!K^6M#T<*83AZayXZP{Dw>zTs)thYvq7nDmybWj5lIvg3xBT^AN*F(c;=nw*Mg z+aIpp8nydmmQR&Ogpk;B1hw3)w6G|B-~j2kq~!Q<%+bSJ?_Xr7%xF?=Wtzn)q$160 z)d~7Pe3Xx2?yTD=@^CghWj&&Pj-hw!*A@Ay1nPO-nL#`v{MU2hy!6hr`&k{SJ?>)SRy9Zl%xM3darVakK%qLcq?sof_PZ}_MJ^C z5>GCOOYPD+asS-Gy_%sfHG}6p9P9?_!ye92b7+@vHJ6|L-iDFH9L2P3k8B)>mJ3EB z>|+2$tW)7hYPj?c4_Kdz%Iil0I-lw3hk!uBRO(8Jem*$Qst`-|sd&)$`nB zJ2%5zid&uYijlOh>L~=)8v=V!$q{}1Jed5Z7|}gs>$1F)>9qWA#fC#-5l)MZyBv+hEzV8O*>za-=y=`i!pr;;-;51Sf4g>d%kIrD*?rJI!*FB35ybq*_3oY?T?Tc{ z(8G(#r$mcO4rGxBSv;yee}vmC_WsydK{vFtI;uI&3B`5@;#245t?{B<_k_84k5kp2 z^Aml1{$qRU>pMSv@(>>nsN>j4j3anFgC8T(@$uu0hm?5t)t+-={8NE-yz(oEw|d-j=Mir=15<$u&2(Ur}=YgH(LO zVQx`QaF;so{&6q79qXBW2i=r3cL=j`z|BM>UABn%{c}!EE~8&2ExzrllF)a)182y4 zo~nxaeK-@p;J9+wjapv4rS}ZKsCfgOr@ozKKkyRWND#pC-YR7xshF zV}FvN65yz{iNGg(GtV#;>*eMq=iD4KNQGP$X4=y=^@3XNyphqr)4!l-dZ3s4(#%e2 zJ*SNNV@0)7*6)V~qF!~g)fJfv%J)ng4J@~n*+ZN47>P+}6237b8?J6ao9yE_krid; z|40=?OnWZ+z&_rsaP6UJL4zt{{0qj`vcAqkh-YG4YM`2pEg7BvKncw(+Nv}!5ra~8@6%g!WLs_Q z8c@#;`_~)JZN|7yFK?LeDh?|+OxNt%$`o^dx4@#Y5J&OGH-j=Jd;aBv{rJHRA_Y7C zaq@k5>i4-t-PH=e_w2ua7;8Xx@sA%r7=vGul9M+ox~pdAu`}x^iT(AYal)9lXWpsn z?m=RUHp!%oDM=raDfG&DVa?ExUhb&a@$nUEU7@ZW9b3j_cNK8Silm;PrbXRoR&3Hq z#rv#S?26q=F`2O97oZ``Gv@Rmjmj_+-efu?R+k}zrENRcQL^8I8#iKuIVn* z4HvP>Sg~7>3u&X)m|Hm}43(`WTTHXd_4(T-!my{%R zWm{&Q_dMEtutpU<={cN4euCbVQe4xsIJ%v;J|-&X65GnX%io18%Ow%I*7^VQu`O^- zcr8ou91N_afR(FBiS4g1`RAi@^y=cA{`22Gh!^1b+}qfMZ90!66I#y`qvX!p1w>}g zYq%2#q0<%g^yN+NT?HoD=cAKUDN~{MZATUb!lSbaDrp*=?caV?MmK-+uj9@ii*UNs z?_I|&sL}O&^VgQfNzJ-|qG(~cEaAvTkK;SbI1^l%(%>-HF3(&_r*^uC zOl~te5?A9sIXSs3w*2#61X^9gckA74ZRKA8};Qv{K=wzeNsX34PtfB#L@Un2Gl{r;g; zr(8+*?B7PAP{vEDr#e!UeG4gcy5%4|vc`Sf4{K$IkC&!n{4@j!AAFB3 zx~W#8G;~v2|H*NTwEfGQn$8BWq2io7Z`n@Y*U2@-G+zGrMDOsPHD?YB?w+hXXv{3J z#<@g&d?Ibr)z|0tpfPK5V#56RPG(to;Oy0Sy~AaArscrUkjyZf(>Q$QAM56uf0b-; z@X^zES33N}qWtEMJNEE}%QgLdLNHp~qSn%$i3@a>k4HAIxur%k6OL%Y7M&0renzi( zx&C&BD^f82-)YAomTvglAemZB@f!dYBX2=+d=)W7xYRO zQz%}%h}N3$)WXu#WQu?O^jzT5o$@YW9(Tsp2ttX<(wy9+_V=Q5sWGp&pE_Qhru zSdq=8NM&Va#I8@DiX$S{jrb^A<1CKv43@6ua=cd5RW%R_vF)mb#P;uj_N)wyon31G zz(D-FE9MRkvKR)0hg7_&+CHn`;A#~Wl|o%suBh%-`0g=n^f1OqV;dbwR49j0WmeGNAGlxN5L#FO10KJ3S! zXCH}sG#c359t2M!nVZTd0zZH-=@zv-5@)h`&4b3v#GLFH6+Pb{?;lNb?RCBtPfwmcR1XR1Mpn@Z)6q$Lv^*!armxwV<+?S^e>>Nf08zOfM-_vD3Wl%k9F zNO#}ILW?4Wu;q}$Ti4t9ygMB9{gLk6(kzWxmd-7fsr<~F8oD@69nVXCY?wd7(HJ<3 zv>!y4qNPNq;tW+V#1|n8J~}2j5)aUCFdY+pWv~e!OPT?g;&+=H`-rU#se-+ut9x&L zFu=hsXgpVC>1PAw+Q)=_q(}Jfy^6>A?I9B@76rz7agE7SOVrTkt4&3Ql{|mRpiZG56cPgOH%+AgZ zFP^zo;(1^3DbM~KUz)mAeyV>GY==-75wr4JOebVKmy3z=Iz?8c^o>fNGODL*ZCam5 zn>jllI{F9S^_@JQy}xs6vm`p?n)hat%<|noX6bYX7HBTKGg5GA*^XY?EEe`sjn>%| zy$5~ARR4ZAcQ-eagO7|M3?a8Fs?WYZsRFCi-PM)TX{2el=ak2XmiS{7$5*_A{sW%G zoVukE*&r^fXGcV)7r;?F-!?^bL)nKexLiy*Z2|#d3bTECKYBxWdu0OCX1IeEw(Kiy zQ*Kc4$tMz)gJfR#>nMM{OZ=V9+m0G`K_$z+zwM|cGd^Y^Uz6(w3+mghtXn(H1ZbbS z_5Pnxa@}`iM|`SO8lTnH+W)#~3ye%u#r)YNgC=41pY?pyA4#~meq5>BJK|v#W^q~9 z&``;K0r#H?d|H#wSOe=@MxMhvOXjC!J$bTIePwBuNR4@&exqqOWPn)B<;pyR#H=dc z(H1r#zSU(A;y4MQsrdLEW-v?;3g`)=%t+0n} zSG)WAtZORI(0mg`_U!5Y_%RdGh&66UWMknWfq0WYsZ=WC?b#~Zl4TFr_UK5`m*?^q zS*2m*#>idz#3?FM1_+3e?!Le)c$FhaWrXywp>Y*&W8i3N{^DYg`pnxy=zbE%jHU&b zK*}Q!YUC56;LE2f#jASqR4Q=&?zq2>9c672QMe#mGe`VEOE1Nh)>t|$v{)%Pz5bI? zwKmt36!d4YvBb6CKfgd;fCT=a`P&S^!KU1UR4yI&?k%>+Tq@V6>SY6_1$kO+UNYoN zj)$x>8eg<*9`p8|lLRJcVI%?n`4+!>TaqH&0uuOb zp?0=ztYwug9rjZ$goOKKKLuNPJ+r^Re{QbRsHmhQMp6q&X%wh8bc`~2cB$(_rZ#JV z7G@8%8g!H-wZP{hA|izeQ&8sfN~jDeOb5D7_Nvu-f4v=@4f^?tU(vZqkT9w`{E^XJ zga$bfDTij!09*XRnLF#o|2h=&;kiqzU!O~YvORtlG3uNkQ$Y z14zb^Vv1C}9*7hhZfo^7#_9FfXK2^p01^k8rN5?l0lt zwqoG^I}UdUK_J079wkj&Fg*Qb zja~30g_x6!w2;!7V*jsOIp5-WNSsi8T~vh>H^DKGt~A0h>#-rE5B* zrl#s0iR+e(OB=P2y_aHeMA5Zm@|Sh|dVd?4=K7*St_WIum0p;a=` zpksmmvjT6u;Z<^XMICpN!HyqSf-Q42<@#-S|3B?p?>Q9!8x$SNpV_w~-szW7$k%O) zZ;oo1kkQmQ3?(I4ni-g;Mq{#Sf8Bi9~)pgs~%1$Fu(h#$>yNuGz6^is!&7jNL%B=RmndMKGW-z|bm`f|(%Lrtu<3Wfa7v zMLYk)A&o~DP4Ugqi)bk4IoEJ@@W~*c!d4!wFekDF0I7qIK1-=1Pa`)2)aB|y+BD2ugG_|H zU(18csroJRIQIOf!ul7(dIpshGIEP;xsVbR>NU;k4Gl!RPd5Er;YIwPr4csMd^y6E zWjq<9c1NP+U{ff1w58?F^Z}@8{B{F&du;PCWoJYt#5wGc+x30jn|g0iEP+Qj3Hz{Z zklwq+6v&DI4-yUX=xroP*Wk~C75pLl(l}Yk z+fq1!;zi%rJo{2K23u^&RYNT5Mv?ZBeR$YTsUvRm47KbaE?R=Cv+$rq*9jXcs zQmySGQ#cwpqgLAg>nQjwB_`{UId-KG%7{L1=UqK){+}HlX3#gneX8$K$`@p zjP;}77boh05=g~gi6UtLelOMfX|I>tVThx(hsYvf>fk{k!k?q$AT1{voWFba3?Lgo z`ZZ5Tf8J_&TR;D0zrbzLCrV8dKYi65n9M3lIgQQevqY+QLNY`Ijpf>^Iw{RCMY1d{B+83|quxYyoRDQ0Gl! zKgb&M7D+^Y_Mo>sp=FI52~5i~N-sf880u`hDyu_ZcKoR3!u^ukMfX&n7RebkBRUpM zUZy1X(Q0D}30RYaRup-mSooAjZ^qe7V>|k+8W8GSQ%T^2IC3!s-X4HM_o*CH$&uMW zxEw`U-E63!fFz(MkjdnhEAks|hnpadyHOOde@J`av7}}m8!f78sWco?)~>hphx4EKDwCsrcyps@3{q1vx=z*w921sf0_zq=9?jckw9;f~0Leaua;FDxZY z;#x+0f_@~r`oTYU*p0y9x`7DfL&-E8O$|sx7Xe%@l&8T&`Y2<(W07KqI(txS@?@&M zZ*?iNuKD@;50%jr->&})fWOf!N<3{X+-q@qy)Y8aQ(RJF2qmS@!xEyddtn*W5cma9E1{SIXY)`e%tdt4_1y7jvTQ`v=HbdnvUpL zaC{iSkaaFUyR=a>{?Xl*V2HcBP6bx>fjYCJv>uSii%LUAjwPLNx(zm>IR2tD@6*{W z=*|n5Iy!>dTM*Gl(?gz%Td0nsM+hg>%OEjxhV}A?*aWg|mFfL+SwWQa{Q?S?-v|Vz zS*cS|*HIGq9h7GBDzGLfo`AK42g5B)&ulgi^B$=IqI-lk>$k#XGrz|fJ)u|{X>wnn z+zzmj-a$wg8_dGdaYV@h$OH(|`C!K}zkauTH_+}-NR>vIx8^Rh>w4h#3a|vQ5T5-C zgFda&tAGt+q>w_f00ctEc6WD^%%#R>(^p=$tFvu4?m1;Z^lMY>xi;RBi=tlq(ywM* zdy4XZq1n~_VsIq8sp&jqa7smmzA3Aw_IIN!BQAX@C++6f^>zeSH@ctggT@c9J(FQ( zsH}sEEe@@*n}weW!0ZVc*G^lhviB%?bww);6#zv__3OX{eZ7BF!EfvXV=m=ejH)3T z8v8H{m+qk2fwUdfoQ`cvJgJ*D>NZHl*W_&(grKAX#m2WQk6v3|TIhas3-H;6 zKXx8BhWxKo`)eaa-o+#Z3~{czG}HpjMr>VZjkp_&(T#oTcxxz#DJ>c_mPuWjX~j=G zYc8~v*@lGMp|VvyVww2*q~Dma^rfd6Jvaz$z+VZ<^S#dKiIxtU-ydp=V<7aY6VF=< zS@*<3A)W}o8^q|EE3=wb%=m3lgke+xupqOSLILd73_*k*E2+$)`SbKDuFk^s_+$d> zW%1R`Yid;b;P%skw#qa6bRGfXS@wXs1h51W2Y89aAsP+@bD(fR^69Rv&ovD9o|vpgkY*8F7w+>opds10~a(4Gm9&vb;y+Q{vOfMMZI=fs0K_ zwV7z$2P*6&EVVO|6;zj2S2RP&H5;C#=po~MGAb+eCC%vgeiyy@_KPv1%`*`w%mY7% zQCjd^_yPUwb1A)N`#~gl-G5m6(3)4Eh$^;Z4a6~EtZJ}tnFr}zD5iAp=?zR9Xs%Bc zLLfL{#UL5LYtY+xJ`1dt`o|Z<;p04P+YKxMJgx@BsX#A?}pD0d!eh^{E!oSbZG*1irVa9`Nc z4b)Oo`ThBhg-k-ads82(wc6kO zvNkpFN8;jQPn|vU2TYZt(ls2ebFyOC{vTMxC(91fnqDsPLF2($Z1W2K<18o1xQ>glqqQdAN;L%AiNdJ*QiW z!Nh)kPHz!5V_wZz7qmQ3UAyV@9z<&8CqUmOVXzWJDqxBx+)DzMY%Lcmgc^(ibTpAk z(yn}3B=ZiJ1iL)GO{cZcKtL6q*xe>D)e7++L!G05Qb3uILLu|+Ji0kuqG#)K|qFs zOA7dI)i*G45~f#Lz`MH^8E~(GNDBxSl-b~5Ri1jec;w-`D=A{!8~+kSCqA3=hJ$un z8qfd9i3}=kd%*JHDLyokPTxiUNB(`s>R-kE|9zJa&`c0;vz9JY zyuZJmsiI&`ryJl104f;M?K*{}rH~)B71zuOZk<*z{poc`aN5%KyA$mk`a)y;#T0;t zkV9P43FT0|yLx*I;7+LlLxC#XxlTM_T~vgCT)NobQ=3N%oiC%Z=r(w$LMSE$^wCj9 z(#ifjAMgJeAM4xBPqZP;W3PfG8+A&(%`DVdeXJs9QF~&yNaPpH_?(0%vHV# zl_5Uv@qU>JAj|GX;|^32I^{i7{Nu+}E^TEg7SbLndD93}zV7bs9jHnI= zy{pePoeVOjj)}Rbr`Ad%n&Y%IO+bvf`O{I`&`J~Vk^IO0l)$phNl2*8fi@^ zvXx7@x|$&9V~(cgpyCm%8qB;=*katOy@0BCrD0s$AWVaZMo1-U z;{hE)C2T6Ve}0WSti}MP()oncG9ZF1HM!$PtX}6>QfB5Ez=yf$OF=n5t1Cu$VOa`Y zcwUufP!j`X2Te^)421)8-YAPh=J=X~0Vtv5LwE0uKkWlYb^yvm6}2Qe=Ll4eLV=Bb zf{ewpOXk86i_Kw6y6O<1@=b4rvtQle2iO2O8oeAc4KXJc7N{Q{RCI_RG6I@>fIy%o z)7T=j)GE{XAs|JyUw;B?Ka5Gz46BV%o4J4%BoXNNSryoVKuZM|sq{<3Jsc1(5oMno zFoJ^Zq6N6SR`g)N+&`x|P&d()3!Tdr8%OIX3k34jc;=;$4VuV+uUJm12%8^+g^8wOmX+{=mL+=jsOn(Zs$U_V1eJVs;a6Y z$Zg!OyXrnHEzE-C2hLZ zy6N=1{Pa*P1eyU)zxD|<$$c<_9VW5;MUQ>3+mH8&)ahCdnsp$efrk{5NTi^1q0r|C zWEJ=LvhK5hbq_)Kw$fRJenu)LpfBhhNANGC&R{P65^ygR<9JcFpuSWG$;x$uLo! zs7G+)Ta#p}p;fw=&)Wn2<(|nX@jrJk(_v+?2jw3-Wo*$G7xjHFM_u@l%!1q@m1@X@ zg4m-xnsNx(IrwPYrBO{Z^SxME<}g!y+f6{Y2Dx4U2^RRTqVY8_4eW*^27hOOX^4fG z0>0TKj0&In4vR!_NhqIj@2+*^U{rqm?Ti94TbX?HOw_50k^|wC3i~XcHVV!uh~|Yf z->MY2Us6(%0%(;Cbv~e9Kor19Bss?@=LH#_0kd<}=3MMZs5P&d50gnSlTXZa&n z|K?6M2}4LTFqHUhxNHeikc)CkwneDZ%wS$rQcKz=X;v1hl#VMcLRv#WSyv zU9^#xku57*XtR&ouDV2hk!azVkB0!B1x*j+w5>pVYInt0bP z%{O&dsj(aQ0zpi2g@S8)3RcO@ z=*mEU|9j{fc~lE03lSfi_S_Xt8RX&7+Gy=;(2vD^|Lot}hZsZE0!JA9_3dlg!}e;W z7gJEz9;|bSs8!AJ>&knMx$T434-Q?tunTAnICCH&Mgm$S!LV##OiT`up>*K?*juYoWOAKj{)f zBk`ZE+uB9tK|X;eCwH}?CLc6Js@&Ct7i*F5WvFeA6$3j&!78Aw)RpoeCpN>NCbq^O zV#a4rtE=`y?plqWCA+XtPI_=fPf)EZt>?csU=;L6IMA`HDxJcWx0|7uLm59I7|gY$ zJ-QX(-dauB0?&Bhi{25+XRFI@=POYr+jWRJu)$Gzt!a<_b3^nWgA?hEJ#tP z3rZ}UB!`e+@peFW?gNqIo60}X?yBtW)ur9S}dbvP4{eLUt zJn>b~5d?}FMs?pK@71;m6XA&Nm_W!RN8(7ex?p9Ck7q^7bQG1=7NST3CI)q}>#QnNIQnr^)dTVBvD|s^RlyZN<^@vL2s-8$`Q6SpN{2QrJP<-=qH9{;mx3@I*zEx8 zz6ga$;K*qqGtm7d*OsDeh89Zvw`e8zsZUktjpxYT1pPz0FS6+30zK({t_}~v6@lRPPXtP2jf3`qXWI8FZDm$fe$Y6e z(GEILNX8P-3B}|S`yCDd4%Ta$1L`cOMzBe`W6GyF0AtXp2g~;o_jj|VrHzdZt59<~ zuQYr9?%B*mPFY_u6pj4O?z&81EO5_MLrCK8fPnz#-Cz}-2WJi8?&d-24MzjhUY~e8 z8VHR<0=#R_^n^R-HfVVCo`Adn<|63u#{{*(@x2JPKWeN)7lE1)w6Aoc`uHkkK!x`c zf;-mS0yCL%{mW|x4)u1y1IjBeKgAu>)nwpV2Qb~ISlc6+jUTkI&||}Gz0Sr zGMv(&U)Jl3JNnA3QZo@S{_SM$Fd^PttAyd z#~EI+hd&5-ghHHF**e>F?u4r%>{U!*+My30Kbm;D=2}*LHIj;F;H^7q?OU&wp~@;6 zMxubb(4K|WMv?2U)-Jx@RhwZ-ItM#y4mXjDOen->Gf!T9{{j5$_zU9V7+`E&4-aS; zmO2Cs;=vps+wXfJAAc0M?!wFnmf{}2FKFxly7STRQJq}k0V*huqkRBik>fisN8LbU zg?R^0Itl(3=7>>RF>nDCzYA$DJzWMcXT_%_9D#lY5DQXj7o2h&qcZZ?48-rh+*LV2 z(gM5?|LTil+2~o2Rw-c8q+Wl$9ys@EFr+=Bt0-Ahs;c^I!KEL${Ot615T=)scR7Uo z`V0x8f4@Kq=Xf}~VU-pEDGTe!yO=x|?H%G=v2VP@HlS_>&ncgrQf7xuPEXhmmDp6Y ze}eWIk~cIHaYUT^$&@s48PE=U$*0X>ZI3}qN!A4?;rWFSPW6hVxjl5}1v!N87br{( zrOo=^BzJ6)-5Cil4U%|C78( zcxs8y)=5?MQopCe_oq42y_uo;Q2j>d>!t@oy=ndP(_F7o3q!$mh@(-1ML1e^@2%Ofuub@}*C zGqrsQa_2!*qFM(FI!B53ojZ77n2q5$Wtjdvu=X5kfqm5m# z?784AOFlTbC23d;M^>YqM8O>B4;Kv4%gdW>q~iVN`&5wnhYaxdu!_POWsj-j9Op7{s>tjRbN WZMmSotpZ*i!RQ#CD>>_U`+otu)>3Bx literal 0 HcmV?d00001 diff --git a/images/witness-byte-map.png b/images/witness-byte-map.png new file mode 100644 index 0000000000000000000000000000000000000000..1095cba398172c6c90a7dde180939c2ccb337ed2 GIT binary patch literal 9355 zcmdsdc|4U}+x8Zrga(nyP?-yvWekOl$SiY_X$u)MYmnTOY*SKXr%l`lnb~HW zWX?Qq(|hjwd7t6?zW4Y2@%;6^Z@+#nuIpNBoolW0Jdfiz*A;wUU5WbS#ghmGf*PrO zM+<>CRtvxHQ~VV4-%kNo#0JN)n{bJjM}V0D+LX2Mhto-t3vf}tf*?g8YPreG;ScdZ#3{IBoDLvC zAjawbJ2YC|BOnMW_wL=}idBnSTXQzj*N<6Pm?XJb#`HU`zL>JMt8sJYwmSLv?)r>( zhs>URNl%SJnADnbXG{~B`ASx1<_S0K^aYC|%jUCrxw#HWD9wBK-YyUEUqLAKAND87 zPv07t*_-C_PAb5~VP)Qop_SQwbf>Fg*sj~YN_&WQSM}0IKlo}HjAT1o!XI{~cKlH& zx3RXmy}y0<1~x7EAk~T2OQV}FCbt>!4!ecw6hObz&iIk)LoYGDo@;p}!z-ZFVbm`2 zDCrQ1)KDhe+neNMkKM{6y&d*J)*s8s%`?ZsCe1bHfyOCI$nCCpXRY-o&#+1J&lSbR z#ogaqK#ad>OOnNZy!r42|C}(=t;Nhb@x3d0ZDN~cYj2+$Ev5hUy^v6CVCG?WclQ}y zUf!B;ovU*pXg#D#RCIJ=S9kZ?Qju-XGpe(&?y^wQt))+ViLa$Euz8#m-C>UmGVbtio((7ef|&nk^U4}ceV7i?sVTra$KgdZf$94 zk8zb#Rc&QPTICNgkO;?2=>j*%_c6{b0fGzPsHq*K<0`(-$fJ#Z5pG)ovEXx%yi(< zhL%A$TPE5$I2=Z$tyFogJFic-xvUPIN)BQ>d*Tw=^WA|a8TtzrhZ#9JHzL(DSkO9* zG(j~IPk;Wo9V*}-6={b;?M0=9Aql7(^sN^ybWBavX>TINzduW~*3UCt3}ccMJ^NOX zN^CsNMtEK+RZ~ODpj#BbJ)=T+lU5A>nsQC6CG@qm&&{`5P~2RRUi*Gc?lhUzpKs1k zqjMu8TPy`-eYOUzm5OAiEYOY0gd`_%pVdEu&v_U>n+UwZF!tP801*^f!_BU%tGkI! z)7h)peN39HbX?9nD?8i8sMO(JX>l=oRLxl0qXGj9@yiaHSn5x=Vp^X>Z}tXwQr&9$OUrwqxG zE2le>mKR6Ld!+V$7ba=?9gnk!G+WpXX~FyFt7{o+eLYy^ozhS9Yzox1i61(V>uZQt zAw;Ax4mn;6g~iyK=pwnGW@l&jqM|}V+r*?AwSdEzX=2-W1`nrBPB~&n!PDa{B9o~7 zG>k(K8v%7JU5y{`$gD2xCDT{z2dQhk$>$gOk>D-v{n5NeYFEQAZ1@LAijW$2%A7Oa zZ?zh$@>G9vM3KA=euY`A`1o+B$kuNLqg+l;GHbi%=xJQm?mCqI_4|cXR?7JAf$HSu z+_J3b<}_}8{?eDeaV)p-JjRX^{<%(z6NY5tHVg9-g-349#i;j%BnB-VKa`!P^Oyhw zf=~VW!E@TAd@9IOsBAzk@tlfx{7UUWhK z*JJ32^A?hNF|2mt(cilVBX(COy%3`4tN-Qw=ryBjq)LDM%QzWLwErGLmQg^$(1t)( zVLLlIq!}ndnys!e=QwjWVJx#pn=tIDnc*?N5qaot+B=sZ@jkQ|SI+X2=*SFaJ_6Su zI*QR&s$OpUJF626rq8Z;vx&SFDB<*r?wvbwyCB>9aQ}Wr-uz9!FFp9ij@u2VoWx+b zNzX(~ZZ3_g1Qz`6w`ZdCNX?HgLizt3MmoJFfx*oy;~$p1RL?1HEDl?pYzi9I@Q+XH zA7&Bp+uvE4=#3S95{EaPu|)Eh%G!Z<$+(d_GBwiv=h)V)xVg+#p$jq}NS0n(3O?9r zy?$eEXRE0_DWjb==l`AG-v_3VI33`vsIH~3cg=0&zgUOAzxQsPvR1lY`Hv!5t)>Kt zzu*0b+5Z?oJPa}7a>FhD|1;#fo_~w!>|<9AI6ck>LetoRUaW?p}bAqcx!ik`I(Ti`b0ESA# ztbctEkM$Vy?Ehw%E!mRn2#O>ZwT#0lGK?H}$f=b`Du8h6mnK?E-g zHDxXL?WIv&A*&x>p8X8wtkC6*RnzmGx^9;FZ2UPzg|0Q^R9&>n5KHEN+7JD1HS_kH zc$n;$&m>YE9B$Xh_QufiG#Yw;*PeOVK=e%6!_}}@8(~A=Z^s#`oY$H;ORWkAb7njf z1*YF0UHpo>Xc79v#)k4>x5JBu-O-scC^s&fEu2yY+i;GVG!Vk0`*b zHpjiVqQ~D}9G{4~t}oF?JMrt(O3s5qXMaLZQt!yfzB&NX8et(X%p=28Ft)c%44-p7 zx9n367Hf+2e@v&EONp@Ilttyne(}!|IXl*iTxQfC7d|LN z_45sPb|&BFay6jPq^zZ;rdG-5;fQD+$i*%{l*oBt^OwsI#}g`BFhEUtCXSZ7WWdIE zKP=KXC7MfNZV@Ul;WS`?I!_Z6LQ>}Yp6hI|GWrGUdjUnkAGf|Lk6T-T)QinO=>lD;FI&Hq%eCl;!dHw4YFH=;0#%@ZOxO zVd6~lg=-z_8^0nnvPw$y8pS0YKnWn+#jERIhOd+Cm>U`yZEg)aE`0vz(A}OO**7$l zMId+qRhgTSJt}AR{B?$?5NZ*35MvsmAEN{mW%nm&MI1)Ncd>b0sY=;JMLG(vPifwu z@A2Pn^0)c%LBQAd3sGhq%iTt>)NcDuIp6XK%45gn@;mN1li7f{ z8M{mMr<`TsgX40^PbV9>&jx?LP}tFgW>@{?8FV<=I_1oB{d&*JM7^$-)+aRj?A@#3 zKXU}ZCNB!1T9bSn58X-bST(zrNN$OPjUJIFL&C7Df%Ol;(uAjtj6qVQm&u;LreVs$ z?@x<)?M}src&=G`CT6s>sJy)(AU~L+{V@-E+u%O7B6qu9xe{NSWp$mEv-0 zzUT_Yi5Iui)6)%W{Hh(WyH?OIu=JL7DU3mZJgh7aKfg5x=(6OP&SPDH@;h&vCMybpG}2a00MciY6oZ+D9D zC#Ot`Znj?L*RNm8Dldak@A!^6F`VQ*4G3Pb(XA?C-F_KD(r&ghB`YUKM^`t>p?VXi zFi)~2rGdd<1RG~vlJ?@ShQEMyB}KMb5#7hpXY!I4+$**p6l9NRuCGX; z0mGEuAx4f{gys~(<`ddIur8f5z6P{TDe9-m2;XS^l3V#}jPtOBEFXOT!8Sf`sx@Ze zhfqiF-f~Ue+S*#`Qy%DJfR?0;3TFsgQBoqxYlby`^5jXw%}Z|;qna&sw6#-(I;7SW zP>dEtL%O>^L1@ES9l*xu3dh_~Xw9jP>p|;!+F7wo`KD>t9PFoLG;o zP$;KsRUB*$N2#RK>=+`E%|YbmD2xwYpC_t2kiqmznE(DHp)1Uf%_0;Q%%O5ol+nVq z=bl(*LBXm`0(pQbcmmzYz^xMrgZ3o@3ua{##p|!dm44n=Sp4>m6k*&Ll}{BoIQGXM zCxLnv4m6sFY62BHT&OuzH9MHsryb~9G%wc5jBIIX=>_Zg{dZd{_Sah7#yn>-)6?%_ zmxUxrPhAZ})g?-MTZU>1UmUf*zFF5V+3|xOi|Z>+&dy8M;)eeXldGh5ZhFs5@7@h$ zb7SIj zJ|EWPw%MnTnrwV~QPlp!3s&(ztP#njbPmzJgt-h6w|SieulY>EFHYIahxM;*ch{yG zOxXM(&KH_FlWy>pa%Jv_WL~p$r}-GDm*pzKi>z30mlW~ZuqiGn;fZNwI;|`etG4Qy zs`!>iX2u)8XS#~o>&G7%>g*V&xTh%UcN`CR{+e-|&vl6eJNZs>%l7$qt3m?6Rvx=* z^krvhi%l8~3x-LN$>`q+MJ=Cbd!P*RsF ze|4G~N2)4c`JE7Y-tG?q7Q(&+R};^vs5tSbp8#~yt|+`#)+#v8!yLwPbD_ezgE=ZP z@=H!m&IQPjMtuVV2KJ@O91$l2<-vjXF6#qP0PP;Bl3wJ#XlUZnCK4ySxz$@k3PV*_Ken|PW_NdML2_CgDps{l@-3m~H_hoc^}cuh{CP5S^V73Z z+7b}pOfEkJF5YrZOY|ey`p!t=HAO$_LjB`#e?}J77AF!X<@wcpc?=UPWIew#8P*TH zMHpIv=I4%S<&J2!0f{cL*{i+j;lJ%su{-@y*UXF`+3@&WYin!q(@8~Q{%H8)JX*ra zKYc&P6})PxdfU`@g39c^t!?IKwb)PoN8A2@SK1lseFFs+ZgnR(ZNTD&3XhSeK{CK9 z7P^#J`o3tUZZz=wY1Zsd@#~tHU@XF<^&lC3#eIEF8$c2QdrfC$4xZ`0IFyb?qxnkZ z5A#E6W<0a9va|pwu7ycy#fv~ah1Rj2n13q2gIoxf!@cgIubE=L+EV} z2%CRp^~WuAyrxwKXkp0Rz8k45eGLp|Id`t6>@8Jld=!1s9m0?0LSaBPyLCu!+pPX< zh?DWH5Oo;&0-|gd!oBlHtdOpuVOAg&15cC+V2lkcWyMMzl^gDX_1xE1KJC+FYrbZK z_Ig^_8L?Qk`T6WTJqwFehnfTTgXN>cJg}SSVvwx1$GraBsVJY2kK^o?igY3Eqh3vj~s=hzahvk9$N|G;^&95LBvwU z0w08Uf*)ayFft>Pp~m6T*>?TpC9AX^+flcElZ%q>Igl?Be*V7qe8!W|n<0~qjNlNU zI(5oC5McmtNX#@9n>ZubZ;iQ#sgDrj^}yS{+Txb+8I) zc+`+D;rvTEy~maai#?z3^^{^ac?0FI0AlxL>o5E+?BFAx6>1k(&^k2Kh0Go1^XnRM z0}j_^j|vB9M?A~L5Er;8Ybi8mF-Dc{nCZ5Ur5Y?NuqVY1qZPFABzz;|YlTS%YK2y9 z-SDs&)t}2(qXAxzZvLftixyE`e<2lz(}VGh9Ln#C;e84rTA@V7(e^<=VSCgg$)Res z@lhTT!odEF5WWg!i^k9{c!MpoY+emQ6^RTMj1B!dm?PCOJfjFTtRklgc_QclVb6%> zGco)1it<5=5L&g2iWZ%c0jSTRJXx-^WBS*0PbIHb99M z;8~~)N_fP4!J(0uBkjHQrM&z>nCxL0RF{hV4hS!Ek7-iYu(Puh2?RZ_VH(jzG^AEv ziP{e&w|x{tLD9-p4kIr$^y?ThbKM8%Ly zSp|ek9}dTX-`niW;Yv_v$g@qkuRP&o zkT`Q5MHg*qO7bWjuez-*RyUY*|PNV(uQaPC7_&12odr z*9VI23e(C0E>A1965w1O-!6OPqpPDshj$>mc@qdHE2Zn;;~3le*VGa-@h+}V<>WaV zJi9xS)DQJVw?18c$hq8fC+9L`4>IQ$7DOP74gjLMfMuq@%s~e)fRyToBt;Cw^$uAx zAVEV_o`q1%ah;0NSJ8S(ek-DR7UD3MhzSdMHKyAmE@95)#sXwwkT4^f>4sUsC-^FV z3nus$=N8#N?hA$Eh~zsQ8u9#C;25_EH8UAwpZe zyy|T!=6=HF!e-tPAqBq3Ow(C^Vz+HZ zvlD(>%U(xH!19TJ4(4+_MIP|H&H$Bwnud~z6%YnFiG*BZkZPBx82CandTcL&7?KSE zkXB~^oIgW@E4=PD614JgGtBk;>)d(L3nN2$4DO((r@>wAAZc8ZeH3b&kMlyu#|2+| z$aH6dw+*ZXfSAP@IqLGo^!#d$AZAxsv+F=~gwrls08i01HO>9#P=N&G9{Tz?gv}Nz zKNkfp-^d)yX=Fo%G`R*r0yw67X3G&ZUp3{)7jr!qH@@e$iVr*-mA^?HDBqB`XqKA4 zV4PAT2A;LxhTHW_2wQNPSLMm|>e&_ffgru`owC-1>o*zaRE(S|+t~`RHN@Aoo1$Yx znQ8cqm0;}8HZ~{`_i<;$Yx$VCxCj+i)v{`rY5q1pIZ>GHf5~F2Joop}$cwr*+v5~_ zehEqaeNUN?2QRD15#(n-GjD6pHt>$DY>mI9<@wmgbMY-P_STb*s=z;sJG>H1kQqG} zWqiui#V5#!&`U&rQ?EJp1ot6ZB0V8`i`xRu7PQC+85~)4hEUe-ap#nJ4nHZi1-?K8 zdM-Miv8SUr+-FG0v!pS6*MA%;UOn@deuRSIW-TeL4ahb^9RoI*7(GP)5P4Wf<~yfq zrlp`jDnwKX)vvbkk_9-h?h8o$>v}nzsbMl%z<$7Ldi>UKk!=Kr+J|Jx<*LH6R&9My zK2SL&?gNo5HEf;0Z%3(TY!>JF-eWL!dak0P(u>12)~)^3Gq992Ep7-z+oh56J$ui1 z^^B<2DOaGGHZ$!BEQT3Q*NlZP>H;r%!Fr!3N=x`+AA~U-O%R9*${J!9ZxADaph(1sRVblut-(&-lOZcV?pJMSKNePfq?=`6m`T4Pn+3EFKiA9LaiWE=+d zVB$5GZkTWWJkfKSQAA8E8^Gi3+qV@HuP<%jj}Gt^({U&o&-IfQKS<=n=uV#T19442 zNE4U3wcK@1t9q^Fy2;W`3D8z*7MZHDKN+EWa++f+ekTjR78s~q61DGqO?_!&f4xH$ z4MHckVx9+Jg@^K(9+VCc7XpY*_6n3yyTrl`B6-;Jk&bBvmZ0G99G>4kl0zJx1_e~6 z`z6vb+1ZaCk3mq*j=Rb=9m%s@4**&-MaGRV#wE2x<>K}@!f{jitP{W?p4Ezlxw_Z>K zO-enb@zk}z$izmRUIIx;eKK5fe$R^*sHtQ1X0)mQf!o0pzrUu1#pIde<2J%sL@K>p zbL6-BtgIO{>INt~UEi0CvTTY(}|??*>$CM)H;okau+(-_8**Kg)u zZPav*CP?JbpOn&vJCmbXaKzeqzGJ-?N<+`2a_4$7wl^m>7_CY3m-h$@W=DVNV&diy z2*eHbx(iysZ-0_yd-LH2H_Up1ybvJDUbOWyJpy6gS%}N3sxsC$^K~<0QAu(ZMKC}O z3cvjr6SXXPGzlHNj4#%MWzM5b)hMqfC#v;pCzt(dfWKG3Q66E(hCu%>rET%#e3}&~ z!EClU`W1$SeRe$a&*R?!(pi$F+X!M8e>*m&Nv0?x{ny3;%;Plwa(FzB@CuOpm-FNQ zEgg(+Z<1_K;D&xecB(bE#6$_auDW(CAN(&=;Ey|3eSNuFp2diLe)p6(;Jch!|t%W&`Bg7X0to->fhT3NE!s##n@p)C#8;f2WFp@Z;il}AEya?F3$@Cvo~blS=~m` zz-dqS`zs1i7bU;9?3nVle*2*Ap6|rgx3*JI7#v6{95i=gtErDvW}^$fBkVeRpVzQR z`Dl&*=o3J>llVw~5UwXjpmAv5i?f}^8GNjLfD%Flq5f15!Fl!sQ6mhOV9FS_SmO_l zL;hfhKUE8lonj(L$~sAXpuA1LUDs|Y=#hadhIB z6U3%Hr0{5**c;p+HvLQik7|j%!Hxe0hWMGW+%_x3Ev*Z@e}H-%%D6HEb954hxtt4r z1xh7Lhld@hhkkqKDyfXfMGLlO#Z=8e`4kd=8L(gJC9JbK)Eu+&@@Tyit=VF+GKouH zaZs*Y2a*L48eB<$_bSFM5$bGbp<-w)yBGV!!C?#)+H8oz*e1y{eaR_?x`^n z&%)fYmDI2=>Y>H%w}Y?_g6I|zN-O_L^S1&>RRvhXS{Y;7TEWIsLjkjdBO`b-SDYn4 zMBLh+iu_3#_^h~=`W9k2=skShGJcvUVPG&0qWnsK{-+ literal 0 HcmV?d00001