It has been a while since Bitcoin exploded in the tech and finance world. Though the concept of Bitcoin itself has become pretty ubiquitous over the past few years, what with more and more people trading bitcoin and the underlying blockchain technology attracting developers by the dozen, there are certain interesting activities that transpire behind the scenes of a standard bitcoin transaction.
Through this article, we will try to demystify how a transaction happens in a bitcoin network, what scripts are generated and executed for the validation of the transaction and what the motivation behind each step of the transaction flow is.
The anatomy of a Bitcoin transaction
Simply put, a transaction enables users to spend bitcoin/satoshis ( the smallest denomination of a bitcoin). It does not just consist of the amount spent but is composed of certain parts for identifying each transaction and scripts for verifying the authenticity of the payment.
A typical transaction consists of :
- Version
- Input
- Outputs
- Locktime
The article will primarily focus on the Input and Output parts of a transaction.
Each transaction has atleast one Input and one Output.
Input : Represents the amount being paid to another user.
Output: An output is created by a transaction and is marked as an Unspent Transaction Output (UTXO), until the time this amount is further spent by the receiver in a subsequent transaction. Any later input transaction that attempts to spend a whole or part of the amount in this UTXO must reference this UTXO to maintain the link. This chain or link ensures no one spends more than they are supposed to.
For eg , if Alice sends 40BTC to Bob, for Bob, the transaction containing 40BTC will be a UTXO until he decides to spend it.
Bitcoin Transaction Flow.
Let us understand the transaction mechanics continuing with the above scenario where Alice wants to send some bitcoin to Bob, which he later spends to Carol.
Step 1: Alice sends 40 BTC to Bob:
To keep things simple, we assume the most common form of Pay to Public Key Hash (P2PKH) transaction type. We will understand this transaction type through the explanation of this transaction flow.
Step 1.1: Key pair Generation by Bob
For Bob to be able to receive any amount from Alice, he needs to generate a public/private key pair. Bitcoin uses the Elliptic Curve Digital Signature Algorithm (ECDSA) to generate this key pair. The public key so generated, is then hashed and the hashed public key is then provided to Alice encoded as a Bitcoin address - which is a base58-encoded string containing an address version number, the hash, and an error-detection checksum to catch typos.
Since Alice will use the hash of Bob's public key to make the transaction, the transaction is called Pay to Public Key Hash (P2PKH) type of transaction.
There are a couple of reasons why the hash of the public key is shared to Alice instead of the public key itself.
The hash shortens and obfuscates the public key, making manual transcription easier.
Public key hashing in P2PKH transactions ensures that public keys aren’t made visible to other users, prior to that pubkey's wallet spending funds. This creates an additional layer of encryption between the user’s private key and the public network, providing increased security.
Step 1.2 Transaction sent by Alice to Bob using hash of Bob’s public key
Once Alice receives the address denoted above, she can decode it to extract the public key hash of Bob. She then creates a standard P2PKH transaction output containing a script called scriptPubKey. The scriptPubkey essentially contains a set of instructions (to be explained in the later section), on executing which the receiver will be able to spend the output amount as long as the user is able to prove he/she is the intended recipient i.e he/she has the control of the private key corresponding to the hashed public key present in the transaction (In this case, it is Bob’s hashed public key).
Alice broadcasts this transaction, containing the amount and the script among other things, to the Bitcoin network and this transaction is now marked as an Unspent Transaction Output (UTXO) for Bob to spend in the future.
Step 2: Bob spends this amount received from Alice
When Bob decides to spend the UTXO, he must create an input which references the transaction Alice created. The input transaction includes the following:
Hash of Alice's transaction called a Transaction Identifier (txid)
The specific output of Alice's transaction indicated by its index number (output index).
A signature script— a newly created script which is a collection of data parameters which satisfy the conditions Alice placed in the previous output’s pubkey script. Signature scripts are also called
scriptSigs. Bob’s signature script will contain the following two pieces of data: a) His full (unhashed) public key b) A signature made by using the ECDSA cryptographic formula to combine certain transaction data with Bob’s private key.
The below figure illustrates this explanation
Figure 1: A transaction input spending a sample output (Source: (developer.bitcoin.org/devguide/transactions..) )
Step 3 : Transaction validation using the input and output scripts:
Once Bob prepares the input transaction as outlined above, he broadcasts it to the network where the transaction is validated by peers as well as potential miners who are accumulating transactions to be place in a new block.
The following figure illustrates the contents of the two scripts
Figure 2: The contents of scriptPubKey and scriptSig
The Bitcoin script instructions are a set of 256 opcodes consisting of a combination of arithmetic operations, if-then conditions, logical operators and cryptographic operations. It is a Forth-like stack-based language which is stateless and not Turing complete.
A Turing Complete language is a language which is capable of performing any computation. The Bitcoin Script, with the absence of loop structures, is purposely kept simplistic and Turing Incomplete as it prevents the possibility of infinite loops which can consume excessive network resources if left unchecked. This also prevents any attacker from attempting a Denial of Service attack by bringing down the network.
Further, the Script is also stateless, which means that there is no state saved prior to or after the script execution. By ensuring all the computation and logic is restricted to the scope of script execution, all the nodes in the network executing the scripts can be assured of identical outcomes which is essential to a Bitcoin network.
The validation is done by executing the signature script scriptSig followed by the script scriptPubKey as follows.
Figure 3: Step-by-step execution of the input script scriptSig followed by the output script scriptPubKey with the stack snapshot at each step.
If the above script execution returns True off the top of the stack, the transaction is considered valid.
In step 5 of the above figure, the OP_EQUALVERIFY operation verifies the hashed public key provided by Alice in the original transaction by comparing it with the hash of the public key provided by Bob. This is to ensure the transaction initiated by Alice was indeed meant for Bob and no one else. It identifies Bob as the recipient of the bitcoin amount sent by Alice
Further, in step 6, we verify whether Bob's signature (created using Bob's private key) corresponds to the public key shared by him. This is to ensure that he is in fact who he claims he is and is the rightful owner of the private key whose public key he has broadcast.
Key Takeaways
More importantly, the question arises - Why go through these complicated sequence of steps to simply transfer some amount from one user to another.
We must remember that Bitcoin is a decentralised, peer-to-peer, open network that all individuals can participate in.
In a traditional centralised notion of a bank, every user has an account uniquely associated with him, which the bank has created after verifying his identity. All transactions are made and recorded against the account. At any point of time, the account balance reflects the amount remaining with the account holder that can be spent in further transactions. Every time the account holder tries to make a transaction, the bank checks if he has sufficient funds to complete the payment.
In direct contrast, in a Bitcoin network, there is no concept of an account or a verifying authority. Any transaction made from one network user to another exists as independent transaction, recorded as a UTXO, locked to the recipient user. As miners in the bitcoin network can pick up various transactions generated at any point in time and store them in a single block, multiple UTXOs against the same user can exist across different blocks in the blockchain. Hence, there needs to be a mechanism in place to ensure every user only spends Bitcoin amount from the amount available for him to spend. This is done by linking the Bitcoin being spent (Input) to some previous received transaction (output/UTXO).
The pair of scripts scriptPubKey and scriptSig can be imagined as a set of locking and unlocking scripts to place conditions under which the amount can be spent. In our example, when Bob receives the amount from Alice, it is locked to his address because of the hashed public key that Alice specifies in her transaction. When Bob decides to spend some or whole of the amount from this received transaction, he needs to generate an unlocking script scriptSig. These two scripts executed together will declare his right to be spending the amount by proving his authenticity and satisfying the conditions placed in the scriptPubKey.
The article is simply the tip of the iceberg when it comes to the types of transactions possible in a Bitcoin network - only meant to introduce the happenings of what happens beneath the hood of a transaction. In reality, there are many more scenarios, possibilties, conditions that can be exist. The below sources which have been cited will enable you to explore the topic in further depth.
Sources: