Bitcoin Transactions in Blockchain

Bitcoin Transactions

Transactions are at the core of the bitcoin ecosystem. Transactions can be as simple as just sending some bitcoins to a bitcoin address, or it can be quite complex depending on the requirements.

 

Each transaction is composed of at least one input and output. Inputs can be thought of as coins being spent that have been created in a previous transaction and outputs as coins being created.

 

If a transaction is to send coins to some other user (a bitcoin address), then it needs to be signed by the sender with their private key and a reference is also required to the previous transaction in order to show the origin of the coins.

 

Coins are, in fact, unspent transaction outputs represented in Satoshis.

 

Transactions are not encrypted and are publicly visible in the blockchain.

 

Blocks are made up of transactions and these can be viewed using any online blockchain explorer.

 

The Transaction Life Cycle

The following steps describe the transaction life cycle:

 

1. A user/sender sends a transaction using wallet software or some other interface.
2. The wallet software signs the transaction using the sender’s private key.
3. The transaction is broadcasted to the Bitcoin network using a flooding algorithm.
4. Mining nodes (miners) who are listening for the transactions verify and include this transaction in the next block to be mined. Just before the transactions are placed in the block they are placed in a special memory buffer called transaction pool.
5. Mining starts, which is a process by which the blockchain is secured and new coins are generated as a reward for the miners who spend appropriate computational resources.
6. Once a miner solves the PoW problem it broadcasts the newly mined block to the network.
7. The nodes verify the block and propagate the block further, and confirmations start to generate.
8. Finally, the confirmations start to appear in the receiver’s wallet and after approximately three confirmations, the transaction is considered finalized and confirmed.

 

Transaction Fee

Transaction fees are charged by the miners. The fee charged is dependent upon the size and weight of the transaction.

 

Transaction fees are calculated by subtracting the sum of the inputs and the sum of the outputs.

 

A simple formula can be used:

 

The fees are used as an incentive for miners to encourage them to include a user transaction in the block the miners are creating.

 

All transactions end up in the memory pool, from where miners pick up transactions based on their priority to include them in the proposed block.

 

There are different rules based on which fee is calculated for various types of actions, such as sending transactions, inclusion in blocks, and relaying by nodes.

 

Fees are not fixed by the Bitcoin protocol and are not mandatory; even a transaction with no fee will be processed in due course but may take a very long time.

 

Transaction time is dependent on transaction fees and network activity.

 

If the network is very busy then naturally transactions will take longer to process and if you pay a higher fee then your transaction is more likely to be picked by miners first due to the additional incentive of the higher fee.

 

Transaction Pools

Also known as memory pools, these pools are basically created in local memory (computer RAM) by nodes in order to maintain a temporary list of transactions that are not yet confirmed in a block.

 

Transactions are included in a block after passing verification and based on their priority.

 

The Transaction Data Structure

A transaction at a high level contains metadata, inputs, and outputs. Transactions are combined to create a block.

 

The transaction data structure is shown in the following table:

Field	Size	Description
Version number	4 bytes	Used to specify rules to be used by the miners and nodes for transaction processing.
Input counter	1-9 bytes	The number (positive integer) of inputs included in the transaction.
List of inputs	Variable	Each input is composed of several fields, including Previous Tx hash, Previous Txout-index, Txin-script length, Txin-script, and optional sequence number. The first transaction in a block is also called a coinbase transaction. It specifies one or more transaction inputs.
Output counter	1-9 bytes	A positive integer representing the number of outputs.
List of outputs	Variable	Outputs included in the transaction.
Lock time	4 bytes	This field defines the earliest time when a transaction becomes valid. It is either a Unix timestamp or block height.

 

Metadata

This part of the transaction contains some values such as the size of the transaction, the number of inputs and outputs, the hash of the transaction, and a lock_time field. Every transaction has a prefix specifying the version number.

 

Inputs

Generally, each input spends a previous output. Each output is considered as Unspent Transaction Output (UTXO) until an input consumes it.

 

UTXO is an unspent transaction output that can be spent as an input to a new transaction.

 

Transaction input data structure is shown in the following table:

 

Outputs

Outputs have three fields, and they contain instructions for sending bitcoins.

 

The first field contains the amount of Satoshis whereas the second field contains the size of the locking script.

 

Finally, the third field contains a locking script that holds the conditions that need to be met in order for the output to be spent.

 

Transaction output data structure is shown here:

 

Verification

Bitcoin uses a simple stack-based language called script to describe how bitcoins can be spent and transferred.

 

It is not Turing complete and has no loops to avoid any undesirable effects of long-running/hung scripts on the Bitcoin network.

 

Scripts use various opcodes or instructions to define their operation.

 

The various categories of the scripting opcodes are constants, flow control, stack, bitwise logic, splice, arithmetic, cryptography, and lock time.

 

A transaction script is evaluated by combining ScriptSig and ScriptPubKey.

 

ScriptSig is the unlocking script, whereas ScriptPubKey is the locking script.

 

This is how a transaction to be spent is evaluated:

1. First, it is unlocked and then it is spent.
2. ScriptSig is provided by the user who wishes to unlock the transaction.
3. ScriptPubkey is part of the transaction output and specifies the conditions that need to be fulfilled in order to spend the output.
4. In other words, outputs are locked by ScriptPubKey that contains the conditions, when met will unlock the output, and coins can then be redeemed.