Bitcoin Primer
Bitcoin is regarded as the original blockchain or cryptocurrency. While the last core upgrade to the Bitcoin network was in 2010, several smaller upgrades have been made adjacent to the core protocol. The most significant of these are Segwit and Taproot.
Bitcoin Blocks
A Bitcoin block can be thought of as a container attesting to the validity of several transactions. It starts with 0xD9B4BEF9 and then continues describing the new state of the network, including listing all newly included transactions. The Bitcoin block also describes a block header. The block header is a self-contained description of the newly added state. If you only care about a subset of all transactions in a block, the block header is a more efficient description of the block itself.
For the purpose of validating transactions outside the noise of the core network, block headers are perfect. Satoshi Nakamoto designed block headers to be self-describing; that is, if you have a list of block headers, it is possible to verify if a new block header belongs to the list. A block header is 80 bytes and consists of:
Version(4B) | PrevBlock(32B) | MerkleRoot(32B) | Time(4B) | Bits(4B) | Nonce(4B)
By checking if the hash of the Bitcoin hash is sufficiently low compared to the specified Bits, the header can be authenticated as correctly mined. By checking if PrevBlock is the same hash as the leading transaction in your list, it can be verified to extend your list. Lastly, Bits must be checked to ensure it follows the difficulty rules.
You will have noticed that these checks do not assert any validity of the included transactions within. The performed checks can be viewed as the least amount of work required to authenticate a Bitcoin block. This technique is very fittingly called Simplified Payment Validation.
Bitcoin Transaction
This section has not been written yet.
Transaction Outputs
Transaction outputs contain the spending conditions written in Bitcoin Script. Legacy transactions contain the entirety of the spending condition within the output itself, while Segwit transactions place the spending condition in the witness and only store the hash of it in the output. The Bitcoin blockchain itself has no concept of addresses; instead, output scripts have been standardized into 7 defined transaction types, with 5 still in general use today. The 2 that are generally not used anymore are P2PK and P2MS.
While non-standard scripts may be spendable by a user’s private key, they are unlikely to be recognized by their wallet. Additionally, most custom scripts are implemented through P2SH to allow wallets to pay into it.
Each standardized transaction type describes what the output looks like. The script below is a legacy P2PKH output script:
OP_DUP | OP_HASH160 | PUSH_20 | {publicKeyHash} | OP_EQUALVERIFY | OP_CHECKSIG
If you need to pay to a P2PKH address, the output script needs to have the above format. Additionally, publicKeyHash defines who the spender is. To fully generate an output script, you thus need the target publicKeyHash. This is what the address is. A P2PKH address is 00 + publicKeyHash encoded with Base58Check. A Bitcoin address has 2 purposes:
- Identify which output script needs to be used.
- Identify which variable elements need to be filled.
UTXO Type Table
The table below enumerates the 5 transaction types from 1 to 5.
| Version | Name | Encoding Scheme | Prefix | Hash Length |
|---|---|---|---|---|
| 0 | Unknown | Ignore | ||
| 1 | P2PKH | Base58Check(00+PKH) | 1* | 20 |
| 2 | P2SH | Base58Check(05+SH) | 3* | 20 |
| 3 | P2WPKH | Bech32 | bc1q** | 20 |
| 4 | P2WSH | Bech32 | bc1q** | 32 |
| 5 | P2TR | Bech32m | bc1p** | 32 |
* Prefix is determined by the encoding scheme.
** Part of the prefix – 1q/1p – is determined by the encoding scheme.
Transaction Inputs
Transaction inputs link to other transactions’ outputs along with the unlock conditions fulfilled. For a P2PKH transaction, this is the public key & signature of the transaction.
Importantly, the sum of all inputs must be greater than the outputs. The difference between the two is the fee and will be claimed by the miner.
Proving Bitcoin Transactions
This section has not been written yet.
Confirmations
SPV clients are not safe at 1 confirmation; it is required that multiple blocks are built on top. This is because anyone can mine a transaction that passes all SPV checks but contains fraudulent transactions. As a result, an SPV client is at best as good as the blocks built on it.
Additionally, the SPV client used does not validate the actual difficulty adjustments. Instead, it verifies the 1/4 law. As a result, each block shall only be assumed to hold 1/4 of the validation power of a fully verified Bitcoin block. As a rule of thumb, the table below can be used to map value to the number of confirmations.
| Size | Conf. |
|---|---|
| $0k - $20k | 2 |
| $20k - $100k | 3 |
| $100k - $200k | 4 |
| $200k - $1m | 5 |
| $1m+ | 6 |
Note that starting from 5 confirmations, you get full Bitcoin security as 2 Bitcoin blocks will always reorg the chain to the proper difficulty (assuming the minority chain isn’t being mined with 51% of the mining power).