Bitcoin 区块
一个 Bitcoin 区块可以被看作是一个容器，用于证明若干交易的有效性。它以0xD9B4BEF9 开头，然后继续描述网络的新状态，包括列出所有新纳入的交易。Bitcoin 区块还描述了一个区块头。区块头是对新增状态的自包含描述。如果您只关心一个区块中所有交易的一个子集，那么区块头是对区块本身更高效的描述。
为了在核心网络的_噪声_之外验证交易，区块头是完美的。Satoshi Nakamoto 将区块头设计为自描述的；也就是说，如果您有一个区块头列表，就有可能验证一个新的区块头是否属于该列表。一个区块头为 80 字节，由以下部分组成：
Version(4B) | PrevBlock(32B) | MerkleRoot(32B) | Time(4B) | Bits(4B) | Nonce(4B)
https://en.bitcoin.it/wiki/Block_hashing_algorithm通过检查 Bitcoin 哈希的哈希值是否相对于指定的
Bits 足够_低_，可以验证该区块头是否被正确挖出。通过检查 PrevBlock 是否与您列表中前一个交易的哈希相同，可以验证它是否扩展了您的列表。最后，必须检查 Bits 以确保它遵循难度规则。
您会注意到，这些检查并不断言其中所包含交易的任何有效性。所执行的检查可以被视为验证一个 Bitcoin 区块真实性所需的最少工作量。这项技术非常贴切地被称为简化支付验证（Simplified Payment Validation）。
Bitcoin 交易
本节尚未编写。交易输出
交易输出包含用 Bitcoin Script 编写的花费条件。传统交易在输出本身内包含完整的花费条件，而 Segwit 交易将花费条件放在见证（witness）中，仅在输出中存储其哈希。Bitcoin 区块链本身没有地址的概念；相反，输出脚本已被标准化为 7 种已定义的交易类型，其中 5 种至今仍在普遍使用。通常不再使用的 2 种是 P2PK 和 P2MS。 虽然非标准脚本可能能够由用户的私钥花费，但它们不太可能被其钱包识别。此外，大多数自定义脚本通过 P2SH 实现，以允许钱包向其付款。 每种标准化的交易类型都描述了输出的样子。下面的脚本是一个传统的P2PKH 输出脚本：
OP_DUP | OP_HASH160 | PUSH_20 | {publicKeyHash} | OP_EQUALVERIFY | OP_CHECKSIG
如果您需要向一个 P2PKH 地址付款，输出脚本需要具有上述格式。此外，publicKeyHash 定义了谁是花费者。因此，要完全生成一个输出脚本，您需要目标 publicKeyHash。这就是地址。一个 P2PKH 地址是用 Base58Check 编码的 00 + publicKeyHash。一个 Bitcoin 地址有 2 个用途：
- 标识需要使用哪个输出脚本。
- 标识需要填充哪些可变元素。
UTXO 类型表
下表列举了从 1 到 5 的 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 |
** 前缀的一部分——1q/1p——由编码方案决定。
交易输入
交易输入链接到其他交易的输出，以及已满足的解锁条件。对于P2PKH 交易，这是交易的公钥和签名。
重要的是，所有输入之和必须大于输出。两者之差是手续费，将由矿工领取。
证明 Bitcoin 交易
本节尚未编写。确认数
SPV 客户端在 1 个确认时并不安全；需要在其上构建多个区块。这是因为任何人都可以挖出一个通过所有 SPV 检查但包含欺诈性交易的交易。因此，一个 SPV 客户端最多只能与构建在其上的区块一样可靠。 此外，所使用的 SPV 客户端并不验证实际的难度调整。相反，它验证 1/4 法则。因此，每个区块应仅被假定持有一个完全验证的 Bitcoin 区块 1/4 的验证能力。作为一条经验法则，下表可用于将价值映射到确认数。
请注意，从 5 个确认开始，您将获得完整的 Bitcoin 安全性，因为 2 个 Bitcoin 区块将始终把链重组到正确的难度（假设少数派链没有被 51% 的挖矿算力挖掘）。