A Brief Introduction to Bitcoin

In this post, we provide a concise introduction to the key technologies that underpin the Bitcoin network. This overview highlights several important implementations within Bitcoin and offers readers the foundational knowledge needed to understand how the network operates. More specifically, we cover how Bitcoin addresses are created, how wallets work, how the network generates and verifies transactions, how proof-of-work powers the blockchain, and new features like SegWit. Interested readers can refer to for more technical details.

Bitcoin Address

In the Bitcoin network, any bitcoin funds are essentially associated with a bitcoin address, which has a corresponding secret password. Bitcoin addresses, much like email addresses, are public information and can be viewed by anyone on the Bitcoin network. This means that anyone can track all transactions associated with a given address or send funds to it. However, in order to spend or transfer the bitcoins held at an address, the owner must use the secret password. Without this secret password, which must be kept secure and never shared, it is impossible to access or move the funds. From the perspective of cryptography, the bitcoin address and its corresponding password are equivalent to a pair of public and private keys. More precisely, we first draw a large random number (either 128-bit or 256-bit) as a private key. Using cryptographic techniques – most commonly elliptic curve cryptography (ECC) – a corresponding public key is then derived from this private key. As is well established, it is computationally infeasible to determine the private key from the public key. The diagram below illustrates the steps by which the Bitcoin network converts a public key into a Bitcoin address used on the network.

Figure 1. A diagram to show how to compute the bitcoin address based on a public key (Image adapted from ).

In Figure 1, there are three key components that are explained in detail below:

SHA256: a hash function that generates a 256-bit hush from any inputs.
RIPEMD-160: another hash function generates a 160-bit hash from any input. The use of double hashing – first applying SHA-256 and then RIPEMD-160 – enhances the security of the resulting hash by reducing the risk of collisions and preventing reversal from the hash back to the original input. At the same time, it shortens the length of a Bitcoin address from 256 bits to 160 bits, thereby greatly saving space in the shared Bitcoin ledger.
Base58check: this module serves two purposes: i) It applies an encoding method known as Base58 to represent data, which improves upon the commonly used Base64 encoding scheme. Unlike Base64, which relies on 64 characters, Base58 uses only 58 unambiguous characters, omitting the six confusing ones (0, O, l, I, +, /) to make it more human-friendly. ii) To provide additional protection against typos and transcription errors, a checksum mechanism is included. The checksum is generated by taking the first four bytes of the double SHA-256 hash of the input data. These bytes are then appended to the input data before applying Base58 encoding. See the following diagram for all steps in Base58check.

The following diagrams further explain the Base58 encoding and decoding processes between a public key hash and its corresponding Bitcoin address:

Convert 25 bytes of a public key hash and its checksum ‘5f26….1e60’ into a Bitcoin address ‘19g6….RBPD’

Convert a bitcoin address back to its corresponding public key hash:

Wallets

If a Bitcoin user relies on the same address for all transactions, this can create security and privacy risks:

Since the private key is required to sign every transaction from that address, repeated use increases the likelihood of the private key being exposed.
Because all addresses and transaction details are publicly visible on the network, consistently using a single address makes it easy to link all transactions to one user. Even if the user’s real-world identity is not directly revealed, this practice still represents a significant violation of privacy.

The solution to these problems is to use each Bitcoin address only once, requiring users to generate a new address for every transaction. As a result, a user may need to manage a large number of addresses, each with its own private key. To simplify this process, the concept of a wallet was introduced. A wallet allows a user to store and manage multiple Bitcoin addresses along with their corresponding private keys, all under the control of that user.

In addition, a wallet can provide several other important functions for users. For instance, it can help initiate transactions from its stored addresses, using the securely held private keys to sign these transactions before broadcasting them to the network. A wallet can also continuously monitor the Bitcoin network to track the funds associated with all of its addresses. Moreover, it should offer reliable backup options or a secure recovery mechanism, enabling users to restore their private keys and addresses in case the wallet is lost or damaged.

If all addresses and private keys in a wallet were generated independently at random, backing them up or restoring them would be extremely cumbersome. Hierarchical Deterministic (HD) wallets solve this problem by using a single random number, known as a seed, to generate as many private key–address pairs as needed. This approach allows the entire wallet to be backed up simply by recording the seed. If necessary, all addresses and private keys can be fully restored by applying the same generation method to that seed.

Hierarchical Deterministic (HD) Wallets

The key idea behind HD wallets is to extend each private key into an extended private key (xprv), which consists of two components: the private key itself and a chain code. Likewise, each public key can be extended into an extended public key (xpub), containing the public key and a corresponding chain code. These chain codes are derived by applying HMAC-SHA512 to input data, producing a 512-bit hash that is then split into two parts: a 256-bit chain code and a 256-bit value used as the private key in an xprv or as the public key in an xpub. The chain codes enable the generation of additional xprvs or xpubs in a hierarchical tree structure, following a specified derivation path.

Deriving a master xprv and xpub: The wallet seed is processed with HMAC-SHA512 to produce a 512-bit hash. This hash is then split into two halves: the left 256 bits form the master private key, while the right 256 bits serve as the chain code. The chain code is subsequently used to derive additional private keys in the next steps.

Deriving hardened private keys for all child nodes: Each node in the tree is identified by a derivation path. For example, the derivation path ‘m/0/1’ indicates the second grandchild of the first child of the root, where m denotes the master private key. Child private keys are derived recursively in a top-down manner according to their respective derivation paths. The diagram below illustrates this process, showing how the ‘hardened’ private key m/1’ can be derived from its parent key m. Note that the corresponding public key for this node, denoted as M/1’, can be derived from the private key m/1’ using the standard cryptographic technique.

The whole process is shown as below:

Alternatively, all child xpubs can be derived directly from their parent xpubs, without accessing the corresponding private keys (xprvs). Since this process never exposes private key information, it can safely be performed on a less secure server, such as a web server.

It is important to note that cryptographic analysis shows this alternative procedure—deriving a child extended public key (xpub) directly by adding it to the parent public key—is mathematically equivalent to the first method, in which the child extended private key (xprv) is first computed by adding it to the parent private key and then converted into the corresponding xpub. This alternative method is preferable because it does not expose the parent private keys.

Mnemonic sentences

In an HD wallet, the long random seed can be encoded into a sequence of human-readable mnemonic words. Recording 12 or 24 simple words is far more convenient and user-friendly than writing down a lengthy and complex hexadecimal seed.

Encoding a seed into a mnemonic sentence: the following diagram shows an example to encode a 128-bit random seed into a mnemonic sentence of 12 English words.

Decoding a mnemonic sentence into a seed: The following diagram shows the inverse process to convert a mnemonic sentence back to the seed. Here, the 4-bit checksum provides only a limited safeguard against typos and transcription errors when recording mnemonic words.

Transactions

On the Bitcoin network, users create transactions to transfer funds from one or more addresses to other addresses. Each transaction specifies the funds being spent (the inputs) and the destinations for those funds (the outputs). An input references a previous transaction by including its transaction ID (txid) – a double SHA-256 hash of the transaction – along with an index that identifies which output of the previous transaction is being used. An output specifies both the amount of bitcoin being sent and the recipient’s Bitcoin address where the funds will be stored.

When a transaction is created, each input must be signed with the private key corresponding to the address, proving that the user legitimately controls the funds. The public key and the generated signature are then included in the transaction so that every node on the network can verify it. The public key is necessary because Bitcoin addresses are derived from public keys through hashing, and the hash function prevents reconstructing the public key directly from the address. Each signature is bound to the entire transaction, meaning the signing algorithm hashes all transaction data (excluding the signatures themselves). Consequently, any modification to the transaction after signing will invalidate the signature, making tampering immediately detectable.

To verify a transaction, two checks must be performed: (i) whether the provided public key corresponds to the source address, and (ii) whether the signature is valid. This verification process is carried out using small scripts, essentially miniature programs. The first component, called the signature script (or scriptSig), contains the signature and the public key. The second component, called the public key script (or scriptPubKey), contains the Bitcoin address – specifically the public key hash (PKH) – along with the instructions for how the verification should be executed.

Both parts are combined to execute on a stack-based virtual machine to verify the transaction.

To create new bitcoin, a special type of transaction called a coinbase transaction is used. Unlike regular transactions, it has no source addresses. Ultimately, all bitcoins in circulation can be traced back to one or more coinbase transactions.

The Blockchain

All new transactions on the network are grouped into a block roughly every 10 minutes. This block is then added to the chain of previous blocks, known as the blockchain. Each block contains cryptographic hash links that ensure the integrity of the entire chain, making the blockchain immutable.

Each block consists of a header and all the transactions included within it.

A block header contains:

The hash of the previous block’s header,
The Merkle root, representing the combined hash of all transactions in the block,
A timestamp indicating when the block was created, and
A hash value demonstrating proof-of-work.

The Merkle Tree:

The Merkle root is the combined hash of all transactions in a block. It is calculated by creating a hierarchy of cryptographic hashes, namely a Merkle tree.

From the above, it is clear that modifying any transaction within a block will alter the Merkle root, which is sufficient to validate the integrity of all transactions in that block. Another important use of the Merkle tree is that lightweight nodes can verify whether a specific transaction is included in a block without downloading the entire block. They can do this using only the block header together with a partial Merkle tree that contains the hashes along the path from the transaction up to the root in the Merkle tree.

Proof of Work

Miners on the network compete to create the next block to be added to the blockchain. The first miner to produce a valid proof-of-work earns the right to add its block to the chain. To generate a valid proof-of-work, the miner must find a block header hash (by varying the value of the nonce) that is less than or equal to the difficulty target specified by the network. The difficulty target is dynamically adjusted by the network to ensure that one new block is added to the blockchain in roughly 10 minutes.

Segregated Witness

Segregated Witness (SegWit) was a major technical upgrade to the Bitcoin protocol introduced in 2015. Its core idea is to separate signature data from transactions and place it into an external structure called the witness. As a result, a transaction’s ID (txid) is no longer tied to its signature data.

SegWit brought several important improvements to Bitcoin. Most notably, it solved the transaction malleability problem, where a txid could be altered by modifying the signature portion of a transaction. In addition, SegWit allows more transactions to fit into each block, since individual transactions become smaller. It also reduces network bandwidth usage, as signature data does not always need to be transmitted across the network.

SegWit was carefully designed to ensure both forward and backward compatibility:

Forward compatibility – Nodes running older software can still validate SegWit transactions without rejecting them.
Backward compatibility – Transactions created by older software remain valid and function correctly with updated programs.

SegWit introduces a new address format encoded with Bech32 instead of Base58Check, for example: bc1qeqzjk7vume5wmrdgz5xyehh54cchdjag6jdmkj. These SegWit addresses can be converted into what is known as a witness program, which is used during transaction verification to ensure compatibility so that both old and new software implementations can process them correctly. Furthermore, SegWit transactions can be included in the same block alongside legacy transactions. If a block contains any SegWit transactions, an additional Merkle tree is constructed from all witness data to produce a combined hash, known as the witness commitment. This witness commitment is stored in the coinbase transaction, allowing updated SegWit-enabled nodes to properly verify blocks that include SegWit transactions.