Bitcoin Primer
Bitcoin is regarded as the origin 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 a validity of several transactions. It starts with 0xD9B4BEF9 and then continues describing the new state of the network, including listing all newly included transaction. The Bitcoin block also describes a block header. The block header is a self-contained description of the newly added state. If you only cared about a subset of all transaction 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 consist 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 to be 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 has to be checked if it follows the difficulty rules.
You will have noticed that these checks do not assert any validity whether the included transactions within are valid. 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 contains the spending conditions written in Bitcoin Script. Legacy transaction contains the entirety of the spending condition within the output itself while Segwit transaction places the spending condition in the witness and only stores 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 privatekey they are unlikely to be recognised by their wallet wallet. Additionally, most custom scripts are implemented through P2SH to allow wallets to pay into it.
Each standardised transaction type describes what the output looks like. The script below is a legacy P2PKH output script:
OP_DUB | 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 needs to be filled
UTXO Type Table
The below table have enumerated 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 publickey & signature of the transaction.
Importantly, the sum of all inputs must be greater than the outputs. The difference between the 2 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 as a fully verified Bitcoin block. As a rule of thumb, the below table can be used to map value to 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).