Bitcoin Transactions

Transaction Outputs

  • 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.

  • “received” bitcoin, what we mean is that the wallet has detected on the blockchain an UTXO that can be spent with one of the keys controlled by that wallet.

  • A transaction output can have an arbitrary (integer) value denominated as a multiple of satoshis

NOTE: 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

UTXOs

  • UTXO are tracked by every full-node Bitcoin client in the UTXO set
  • The cryptographic puzzle is also known as a locking script, a witness script, or a scriptPubKey.
  • Each output is defined by a value and a cryptographic puzzle.

Serialization

  • 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.

Transaction Inputs

  • 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.

  • 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.

  • The third part is a sequence number

  • 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

  • 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.

Fees

  • Most transactions include transaction fees, which compensate the bitcoin miners for securing the network. Fees also serve as a security mechanism themselves, by making it economically infeasible for attackers to flood the network with transactions.

  • fee relay policies are set by the minrelaytxfee option.

  • The current default minrelaytxfee is 0.00001 bitcoin or a hundredth of a millibitcoin per kilobyte. Therefore, by default, transactions with a fee less than 0.00001 bitcoin are treated as free and are only relayed if there is space in the mempool; otherwise, they are dropped

  • Most services offer users the option of choosing high, medium, or low priority fees. High priority means users pay higher fees but the transaction is likely to be included in the next block. Medium and low priority means users pay lower transaction fees but the transactions may take much longer to confirm.

  • Transaction fees are implied, as the excess of inputs minus outputs:

  • the fee is independent of the transaction’s bitcoin value.

Transaction Scripts

  • Script, the bitcoin scripting language is a Forth-like reverse-polish notation stack-based execution language

  • Both the locking script placed on an UTXO and the unlocking script are written in this scripting language.

  • Script is a very simple language that was designed to be limited in scope and executable on a range of hardware, perhaps as simple as an embedded device

  • most transactions processed through the Bitcoin network have the form “Payment to Bob’s Bitcoin address” and are based on a script called a Pay-to-Public-Key-Hash script

  • Bitcoin transaction validation is not based on a static pattern, but instead is achieved through the execution of a scripting language.

Turing incompleteness

  • The bitcoin transaction script language contains many operators, but is deliberately limited in one important way—there are no loops or complex flow control capabilities other than conditional flow control

Stateless verification

  • The bitcoin transaction script language is stateless, in that there is no state prior to execution of the script, or state saved after execution of the script.

Construction

  • all the information needed to execute a script is contained within the script.

  • Bitcoin’s transaction validation engine relies on two types of scripts to validate transactions: a locking script and an unlocking script.

  • A locking script is a spending condition placed on an output: it specifies the conditions that must be met to spend the output in the future.

  • An unlocking script is a script that “solves,” or satisfies, the conditions placed on an output by a locking script and allows the output to be spent.

  • Unlocking scripts are part of every transaction input. Most of the time they contain a digital signature produced by the user’s wallet from his or her private key

  • Every bitcoin validating node will validate transactions by executing the locking and unlocking scripts together.

  • The validation software will copy the unlocking script, retrieve the UTXO referenced by the input, and copy the locking script from that UTXO. The unlocking and locking script are then executed in sequence. The input is valid if the unlocking script satisfies the locking script conditions

Script Execution

  • A stack allows two operations: push and pop.

  • The scripting language executes the script by processing each item from left to right. Numbers (data constants) are pushed onto the stack. Operators push or pop one or more parameters from the stack, act on them, and might push a result onto the stack. For example, OP_ADD will pop two items from the stack, add them, and push the resulting sum onto the stack.

  • Conditional operators evaluate a condition, producing a boolean result of TRUE or FALSE. For example, OP_EQUAL pops two items from the stack and pushes TRUE (TRUE is represented by the number 1) if they are equal or FALSE (represented by zero) if they are not equal. Bitcoin transaction scripts usually contain a conditional operator, so that they can produce the TRUE result that signifies a valid transaction.

  • Although most locking scripts refer to a public key hash (essentially, a Bitcoin address), thereby requiring proof of ownership to spend the funds, the script does not have to be that complex.

  • Transactions are valid if the top result on the stack is TRUE , any other nonzero value, not OP_0, or if the stack is empty after script execution. Transactions are invalid if the top value on the stack is FALSE (a zero-length empty value) or if script execution is halted explicitly by an operator, such as OP_VERIFY, OP_RETURN, or a conditional terminator such as OP_ENDIF

  • the unlocking script is executed, using the stack execution engine

  • If the unlocking script is executed without errors (e.g., it has no “dangling” pointers left over), the main stack is copied and the locking script is executed

Pay-To-Public-Key-Hash(P2PKH)

<sig> <pubk> DUP HASH160 <pubkhash> EQUALVERIFY CHECKSIG

  • The vast majority of transactions processed on the Bitcoin network spend outputs locked with a Pay-to-Public-Key-Hash or “P2PKH” script.

  • These outputs contain a locking script that locks the output to a public key hash, more commonly known as a Bitcoin address.

  • An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key

  • this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script. In other words, the result will be TRUE if the unlocking script has a valid signature from the cafe’s private key that corresponds to the public key hash set as an encumbrance.

Digital Signatures

  • ECDSA is the algorithm used for digital signatures based on elliptic curve private/public key pairs,

  • ECDSA is used by the script functions OP_CHECKSIG, OP_CHECKSIGVERIFY, OP_CHECKMULTISIG, and OP_CHECKMULTISIGVERIFY.

  • the signature proves that the owner of the private key, who is by implication the owner of the funds, has authorized the spending of those funds

  • the proof of authorization is undeniable

  • the signature proves that the transaction (or specific parts of the transaction) have not and cannot be modified by anyone after it has been signed.

  • Note that each transaction input is signed independently

This is critical, as neither the signatures nor the inputs have to belong to or be applied by the same “owners.”

  • Each transaction input and any signature it may contain is completely independent of any other input or signature. Multiple parties can collaborate to construct transactions and sign only one input each.
A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or documents
A valid digital signature gives a recipient reason to believe that the message was created by a known sender (authentication), that the sender cannot deny having sent the message (nonrepudiation), and that the message was not altered in transit (integrity)

Math

  • The function Fsig produces a signature Sig that is composed of two values, commonly referred to as R and S:

  • Sig = (R, S)

  • they are serialized into a byte-stream using an international standard encoding scheme called the Distinguished Encoding Rules

  • The important numbers are R and S;

  • The signature verification algorithm takes the message (a hash of the transaction or parts of it), the signer’s public key and the signature (R and S values), and returns TRUE if the signature is valid for this message and public key.

  • In the simplest form, the signature applies to the entire transaction, thereby committing all the inputs, outputs, and other transaction fields

  • However, a signature can commit to only a subset of the data in a transaction, which is useful for a number of scenarios as we will see in this section.

  • Bitcoin signatures have a way of indicating which part of a transaction’s data is included in the hash signed by the private key using a SIGHASH flag

SIGHASH

  • The SIGHASH flag is a single byte that is appended to the signature

  • Every signature has a SIGHASH flag and the flag can be different from input to input.

  • a transaction that contains several inputs may have signatures with different SIGHASH flags that commit different parts of the transaction in each of the inputs

  • Many of the SIGHASH flag types only make sense if you think of multiple participants collaborating outside the Bitcoin network and updating a partially signed transaction.

  • There are three SIGHASH flags: ALL, NONE, and SINGLE

Notes from bitcoinbook/ch06