What are Bitcoin Transactions?

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.

An actual transaction looks very different from a transaction provided by a typical block explorer.

Transaction Outputs

• 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 keep track of all available and spendable outputs called UTXOs (unspent transaction outputs). The UTXO set, which consists of millions of UTXOs, represents the total available funds. It grows when new UTXOs are created and decreases when UTXOs are spent. Each transaction represents a change in the UTXO set, reflecting a state transition
• When we say that a user’s wallet has “received” a bitcoin, what we mean is that the wallet has detected a 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.

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.

If you have a 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.Why is it done this way?

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.

Transaction outputs consists of two parts:

• An amount of bitcoin, denominated in satoshis, the smallest bitcoin unit.
• A cryptographic puzzle that determines the conditions required to spend the output. It is also known as a locking script, a witness script, or a scriptPubKey.

As you can see, the transaction contains two outputs. Each output is defined by a value and a cryptographic puzzle.

When transactions are transmitted over the network or exchanged between applications, they areserialized.

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.

The process of converting back to POJO is called deserialization or transaction parsing.

Transaction Inputs

Transaction inputs identify which UTXO will be consumed and provide proof of ownership through an unlocking script.

• The first part is a reference to a UTXO using the transaction hash and sequence number.
• The second part is an unlocking script created by the wallet to meet the spending conditions specified in the UTXO.

The input contains four elements:

1. A transaction ID, refers to the unique identifier of the transaction that holds the unspent output (UTXO) being spent.
2. An output index (vout) specifies which specific UTXO from the transaction is being referenced for spending.
3. A scriptSig, which satisfied the conditions placed on the UTXO, unlocking it for spending.
4. A sequence number, it represents a value that determines the order and priority of transactions if they are not immediately included in a block.

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.

Transaction 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.
• Transaction fees are calculated based on the size of the transaction in kilobytes, not the value of the transaction in bitcoin.
• Transaction fees are not mandatory, and transactions without fees might be processed eventually; however, including transaction fees encourages priority processing.

Fees = Sum(Input) - Sum(Output). That means you must account for all inputs, if necessary by creating change, or you will end up giving the miners a very big tip.

For e.g., if you consume a 20-bitcoin UTXO to make a 1-bitcoin payment, you must include a 19-bitcoin change output back to your wallet. Otherwise, the 19-bitcoin “leftover” will be counted as a transaction fee and will be collected by the miner who mines your transaction in a block.

Transaction Scripts

• 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. This ensures that the language is not Turing Complete, meaning that scripts have limited complexity and predictable execution times.
• The transaction script language is stateless, in that there is no state prior to execution of the script, or state saved after execution of the script. All the information to execute the 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. You’ll see the locking script referred to as a witness script or more generally as a cryptographic puzzle.
• 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.

A simple script, 2 3 OP_ADD 5 OP_EQUAL demonstrates the arithmetic addition operator OP_ADD, adding two numbers and putting the result on the stack, followed by the conditional operator OP_EQUAL, which checks the resulting sum is equal to 5.

Any combination of locking and unlocking scripts that results in a TRUE value is valid.

For e.g., one can use the part of the arithmetic example (above) as the locking script:

3 OP_ADD 5 OP_EQUAL

combined with an unlocking script:

2

The validation software combines the locking and unlocking scripts and the resulting script is

2 3 OP_ADD 5 OP_EQUAL

When the above script is executed the result is OP_TRUE, making the transaction valid.

Not only is this valid transaction output locking script, but the resulting UTXO could be spent by anyone with the arithmetic skills to know that the number 2 satisfies the output.

In the original bitcoin client, the unlocking and locking scripts were concatenated and executed in sequence. For security reasons, this was changed in 2010, because of a vulnerability that allowed a malformed unlocking script to push data onto the stack and corrupt the locking script.

In the current implementation, the scripts are executed separately with the stack transferred between the two executions. (How will this prevent the exploit, since the stack is common?)

First, the unlocking script is executed, using the stack execution engine. If the unlocking script is executed without errors, the main stack is copied and the locking script is executed.

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

Let's consider an example: Alice makes a payment of 0.015 bitcoin to the cafe's bitcoin address. The transaction output is locked with a script that requires the following conditions to be met:

OP_DUP OP_HASH160 <Cafe Public Key Hash (their address)> OP_EQUALVERIFY OP_CHECKSIG

To satisfy this locking script, an unlocking script is needed, which takes the form:

<Cafe Signature> <Cafe Public Key>

When these two scripts are combined, they form a validation script:

<Cafe Signature> <Cafe Public Key> OP_DUP OP_HASH160 <Cafe Public Key Hash (their address)> OP_EQUALVERIFY OP_CHECKSIG

When this combined script is executed, it will result in TRUE only if the unlocking script fulfills the conditions set by the locking script. In simpler terms, the result will be TRUE if the unlocking script contains a valid signature from the cafe's private key that corresponds to the specified public key hash.

1. Value <sig> is pushed to the top of the stack
2. Value <PubK> is pushed to the top of the stack, on top of <sig>
3. The DUP operator duplicates the top item in the stack, the resulting value is pushed to the top of the stack.
4. The HasH160 operator hashes the top item in the stack with RIPEMD160(SHA256(PubK)) the resulting value (PubKHash) is pushed to the top of the stack.
5. The value PubKHash from the script is pushed on the top of PubKHash calculated previously from the HASH160 of the PubK.
6. The EQUALVERIFY operator compares the PubKHash encumbering the transaction with the PubKHash calculated from the user’s PubK. If they match, both are removed and execution continues.
7. The CHECKSIG operator checks that the signature <sig>matches the public key <PubK> and pushes TRUE to the top of the stack if true.

Digital Signature (ECDSA)

How can digital signatures present proof of ownership of a private key without revealing a private key?

The digital signature algorithm used in bitcoin is the Elliptic Curve Digital Signature Algorithm, or ECDSA.

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

A digital signature serves three purposes in bitcoin.

1. A signature in a transaction proves that the owner of the private key, who also owns the funds, has given authorization to spend those funds.
2. This proof of authorization is reliable and cannot be denied (nonrepudiation).
3. The signature proves that the transaction has not and cannot be modified by anyone after it has been signed.

A digital signature is a mathematical scheme that consists of two parts:

1. First part is an algorithm for creating a signature, using a private key, from a message.
2. Second part is an algorithm that allows anyone to verify the signature, given also the message and public key.

The signature generation algorithm uses a random key k, as the basis for an ephemeral private/public key pair. The value of k is not important, as long as it is random. If the same value k is used in the signing algorithm on two different transactions, the private key can be calculated and exposed to the world.

One should use an industry-standard algorithm for deterministic initialization of k defined in RFC 6979.