How Bitcoin Transactions Work

There are three reasons why I am writing this post. First, because Bitcoin is relatively minimal and easy to understand. It is difficult to understand blockchains, cryptocurrencies, and decentralised consensus if one doesn’t attempt to understand Bitcoin. Second, this post will serve as context for when I comment on the design of decentralised systems and cryptocurrencies in future articles. Third, I wish to compile a concise yet comprehensive introduction to Bitcoin for developers, something I would’ve liked when I was learning about Bitcoin.

Bitcoin is the most basic implementation of blockchain technology at such a large scale. It has survived for more than a decade and has upwards of 12,000 nodes worldwide as of 2022. Blockchains consist of a devious interplay of encryption and hashing. These concepts are simple yet powerful - and are at the foundation of modern cybersecurity.

1. Introduction - Blockchains, Nodes, Miners, and Wallets

Bitcoin is a network. It has interconnected nodes that are constantly communicating with each other.

Each node has a copy of all the Bitcoin transactions that have ever taken place, like a ledger. These transactions are stored in discrete units called blocks. All the blocks are chronologically linked to the previous block. The exact structure of a block is discussed in section 5 of this article.

All nodes have their own copy of the blockchain. Nodes are constantly monitoring the network to check if a miner has discovered a new block, and add that block to their copy of the blockchain. New blocks are difficult and time consuming to discover, but once found, they can be quickly verified.

Miners are special nodes that ‘discover’ these new blocks containing the latest transactions made on the network. Miners also earn a mining reward in addition to transaction fees for finding new blocks. Mining reward is responsible for adding new coins to the currency.

Wallets, as the name suggests, are what we use to store our bitcoins. A wallet is described by its private and public keys. The private key acts as a password to authorize the wallet’s transactions and the public key is used to verify transactions made from that wallet. If someone knows your wallet’s private key they can take all of your bitcoin.

A Bitcoin transaction goes through 3 stages: Signing, Broadcasting, and Confirmation.

2. Signing

The first step of any transaction is called signing. A transaction is described by three things - Sender’s Wallet Address, Receiver’s Wallet Address, & the Transaction Amount. More importantly, this file contains the sender’s wallet signature which proves that they authorized the transaction.

In addition to the amount being sent, a transaction fee is added to the transaction, which is paid by the sender to the miner as a reward for finding the block containing the transaction. The transaction fee generally depends on the network traffic and the size of the transaction.

The transaction file is signed using the sender’s private key. This signature is a mathematical proof that only the holder of the private key could have produced. The nature of the proof itself is beyond the scope of this article. The sender’s public key can then be used by anyone to verify the signature’s authenticity. This is an example of asymmetric cryptography, the signatures are:

• easy to produce with the private key
• easy to verify with the public key
• impossible to forge without the private key

It’s also interesting to note that the transaction will have a unique signature every single time.

3. Broadcasting

This transaction is broadcasted to nodes across the network. Each node verifies whether the file is legit - whether the sender actually has the required funds, and whether the signature checks out. Once verified, the file is passed to other nodes on the network.

When a node receives a transaction file, it is verified and kept in a holding area called the mempool (short for Memory Pool). This is where the valid, but unconfirmed transactions are stored.

Once the file reaches the mempool for all online nodes on the network, we can say the Broadcasting of the transaction is complete. At this stage the transaction has been validated, but it’s not yet confirmed.

If you enter the transaction ID on a blockchain explorer at this stage, the transaction will be unconfirmed.

4. Confirmation

Miners take the files from the mempool, group them together, and form a block of transactions. Each block can only contain a limited number of transactions (in case of bitcoin the maximum blocksize is 1MB). Miners are incentivised to prioritise transactions with the highest transaction fees.

Miners compete among themselves to ‘mine’ the next valid block. To understand mining we need to understand what a block looks like.

5. What does a Block look like?

a. Version

Bitcoin’s rules keep changing and the version number is used to determine which rules are in effect. The version number informs which rules are to be followed for validating blocks on the network. More information about this can be found on the Bitcoin Wiki.

b. Previous Block’s Hash

Block hashes are generated by SHA-256 hashing, which returns a 32 byte hash. This is the hash of the previous block’s 80 byte block header.

c. Merkle Root

Transactions of the block are represented in the form of a Merkle Tree. The Merkle Root is a number that represents all the transactions recorded by the block. Changing the details of even a single transaction will return a completely different Merkle Root.

d. Time Stamp

The 32-bit timestamp denotes the time at which the block header was generated. There are rules in place that dictate the minimum and maximum value this can take. This is done to ensure that the miner is unable to lie about the time at which the block was created. To know more about it check out this article.

e. N-bits

This 32-bit number is used to denote the target difficulty of the block. The target difficulty is the number of leading zeros required in the hash of the block header in order for it to be considered valid. Target difficulty adjusts every 2016 blocks depending on the average time to mine each consecutive block. If blocks come too fast (more mining power joined), difficulty increases. If blocks are slow (miners left), difficulty decreases. The adjustment is proportional, capped at 4x in either direction.

f. Nonce

Nonce is a 32-bit number that is varied by the miner to find a valid block. Because of the nature of hashing, the miner does not know which nonce will return a valid block. The more observant among you might have noticed that the block header is an 80 byte string, whereas the nonce is a 4 byte string. It is not uncommon for all nonces inside the nonce-space to not return a valid hash. Whenever this happens, the miner can change the order of transactions, create a new Merkle Root, and search a new nonce-input space.

g. Transactions

The transactions are stored in an ordered list. Each transaction contains the sender’s address, the receiver’s address, and the transaction amount. The size of a single transaction can vary and mainly depends on the number of inputs and outputs, not the amount itself.

Bitcoin transactions consume unspent outputs (UTXOs) from previous transactions as inputs and create new outputs. Think of it like breaking a large bank note for loose change and obtaining smaller notes and coins. A transaction amount comprising numerous smaller units of these UTXOs will result in a larger transaction size.

The maximum size of a Bitcoin block is capped. A blockchain with large block sizes increases the cost of running nodes, whereas smaller block sizes increase competition among senders to have their transactions included inside the next block, which results in higher transaction fees. Since SegWit (2017), the block size is limited to 4 million weight units, which comes to roughly 2 to 4 MBs.

h. Block Hash

The 80 byte block header is hashed using SHA-256 and the result is used as the block hash. The block hash is also used to verify the validity of the block. A valid block needs to have a block hash with N leading zeros, where N is the current network difficulty.

6. Proof of Work

The reason a valid block header serves as proof of work is because SHA-256 hashing is considered to be irreversible. As mentioned earlier, this implies that to find a valid block header the miner has to expend a lot of computation in order to hash a large number of potential block headers. Once a valid block header is found, it is incredibly fast to verify because calculating a single hash is quite fast.

Once the block is mined, the miner broadcasts the block across the network which the nodes verify and add to their copy of the ledger. The miner also receives a mining reward for their efforts. Now imagine you are one of the miners competing to be the first to find a new block. The moment you or some other miner finds a valid block, all miners are incentivised to abandon their efforts to mine that particular block and instead immediately start mining for the next possible block.

This is enforced using the Longest Chain Rule.

7. Longest Chain Rule

Because the blockchain is essentially a list of chronologically hashed transactions, there can be multiple such blockchains with different but all valid transactions that a node can verify. The Longest Chain Rule is what makes proof of work possible. According to it, the network considers the longest blockchain as the correct one. In other words, the ledger with the most (valid) blocks is considered to be the correct one.

If a hacker wanted to update the blockchain, they would have to produce new valid blocks at a rate faster than all of the remaining network combined. This is called a 51% attack. A hacker needs to consolidate more than half of the network’s mining hashrate in order to modify the ledger at their discretion. As of 2022, estimates suggest that such an attack would cost the attacker upwards of $600,000 USD per hour.

8. Conclusion

We discussed how a Bitcoin transaction works from the sender to its receiver. Because decentralised systems involve an element of game-theoretics, their rules need to account for human behaviour. I have attempted to explain Bitcoin’s rules in this post but there are entire books written about the various design considerations in Decentralised Systems and Blockchains. In future posts I will expand on how effective these rules are and areas where other cryptocurrencies offer better solutions.