> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# 比特币入门

> 什么是比特币？什么是比特币区块？什么是比特币交易？LI.FI 意图如何证明比特币履行？本页包含理解 LI.FI 意图如何与 BTC 交互所需的所有信息。

比特币被视为原始区块链或加密货币。虽然比特币网络的最后一次核心升级是在 2010 年，但已经对核心协议进行了几次较小的升级。其中最重要的是 [Segwit](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) 和 [Taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)。

### 比特币区块

比特币区块可以被认为是证明几个交易有效性的容器。它以 `0xD9B4BEF9` 开头，然后继续描述网络的新状态，包括列出所有新包含的交易。比特币区块还描述了区块头。区块头是新添加状态的独立描述。如果您只关心区块中所有交易的子集，则区块头是区块本身的更有效描述。

为了在核心网络的\_噪音\_之外验证交易，区块头是完美的。中本聪将区块头设计为自描述的；也就是说，如果您有一个区块头列表，则可以验证新区块头是否属于该列表。区块头为 80 字节，由以下组成：

`Version(4B) | PrevBlock(32B) | MerkleRoot(32B) | Time(4B) | Bits(4B) | Nonce(4B)`

> [https://en.bitcoin.it/wiki/Block\_hashing\_algorithm](https://en.bitcoin.it/wiki/Block_hashing_algorithm)

通过检查比特币哈希的哈希是否相对于指定的 `Bits` 足够\_低\_，可以将标头验证为正确挖掘。通过检查 `PrevBlock` 是否与列表中的前导交易的哈希相同，可以验证它扩展了您的列表。最后，必须检查 `Bits` 以确保它遵循难度规则。

您会注意到这些检查不会断言其中包含的交易的任何有效性。执行的检查可以被视为验证比特币区块所需的最少工作量。这种技术非常恰当地称为简化支付验证。

### 比特币交易

本节尚未编写。

#### 交易输出

交易输出包含用比特币脚本编写的支出条件。传统交易在输出本身中包含支出条件的全部内容，而 Segwit 交易将支出条件放在见证中，并仅在输出中存储其哈希。比特币区块链本身没有地址的概念；相反，输出脚本已标准化为 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`。比特币地址有 2 个目的：

1. 识别需要使用哪个输出脚本。
2. 识别需要填充哪些可变元素。

##### UTXO 类型表

下表列举了从 1 到 5 的 5 种交易类型。

<table>
  <thead>
    <tr>
      <th>版本</th>
      <th>名称</th>
      <th>编码方案</th>
      <th>前缀</th>
      <th>哈希长度</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>0</td>
      <td>未知</td>
      <td>忽略</td>

      <td />

      <td />
    </tr>

    <tr>
      <td>1</td>
      <td>P2PKH</td>
      <td>Base58Check(00+PKH)</td>
      <td>1\*</td>
      <td>20</td>
    </tr>

    <tr>
      <td>2</td>
      <td>P2SH</td>
      <td>Base58Check(05+SH)</td>
      <td>3\*</td>
      <td>20</td>
    </tr>

    <tr>
      <td>3</td>
      <td>P2WPKH</td>
      <td>Bech32</td>
      <td>bc1q\*\*</td>
      <td>20</td>
    </tr>

    <tr>
      <td>4</td>
      <td>P2WSH</td>
      <td>Bech32</td>
      <td>bc1q\*\*</td>
      <td>32</td>
    </tr>

    <tr>
      <td>5</td>
      <td>P2TR</td>
      <td>Bech32m</td>
      <td>bc1p\*\*</td>
      <td>32</td>
    </tr>
  </tbody>
</table>

\* 前缀由编码方案确定。
\
\*\* 前缀的一部分——1q/1p——由编码方案确定。

#### 交易输入

交易输入链接到其他交易的输出以及满足的解锁条件。对于 `P2PKH` 交易，这是交易的公钥和签名。

重要的是，所有输入的总和必须大于输出。两者之间的差异是费用，将由矿工索取。

## 证明比特币交易

本节尚未编写。

## 确认

SPV 客户端在 1 次确认时不安全；需要在其上构建多个区块。这是因为任何人都可以挖掘通过所有 SPV 检查但包含欺诈性交易的交易。因此，SPV 客户端充其量与在其上构建的区块一样好。

此外，使用的 SPV 客户端不验证实际的难度调整。相反，它验证 1/4 法则。因此，每个区块应仅假定持有完全验证的比特币区块的验证能力的 1/4。根据经验，下表可用于将价值映射到确认数。

| 大小              | 确认数 |
| --------------- | --- |
| \$0k - \$20k    | 2   |
| \$20k - \$100k  | 3   |
| \$100k - \$200k | 4   |
| \$200k - \$1m   | 5   |
| \$1m+           | 6   |

请注意，从 5 次确认开始，您将获得完整的比特币安全性，因为 2 个比特币区块将始终将链重组到适当的难度（假设少数链没有用 51% 的挖矿能力进行挖矿）。