> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/blockchain_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/blockchain_guide/06_bitcoin/hot_topics.md).

# 热点问题

## 设计中的权衡

比特币的设计目标在于支持一套安全、开放、分布式的数字货币系统。围绕这一目标，比特币协议的设计中很多地方都体现了权衡（trade-off）的思想。

* 区块容量：更大的区块容量可以带来更高的交易吞吐率，但会增加节点带宽、验证和存储成本，带来中心化风险。SegWit 之后，比特币共识规则使用区块重量上限 4,000,000 weight units，而不是简单的 1 MB 上限。
* 出块间隔时间：更短的出块间隔可以缩短交易确认的时间，但也可能导致分叉增多，降低网络可用性。
* 脚本支持程度：更强大的脚本指令集可以带来更多灵活性，但也会引入更多安全风险。

## 分叉

比特币协议不会一成不变。当需要修复漏洞、扩展功能或调整结构时，比特币需要在全网的配合下进行升级。升级通常涉及更改交易的数据结构或区块的数据结构。

由于分布在全球的节点不可能同时完成升级来遵循新的协议，因此比特币区块链在升级时可能发生分叉（Fork）。对于一次升级，如果把网络中升级了的节点称为新节点，未升级的节点称为旧节点，根据新旧节点相互兼容性上的区别，可分为软分叉（Soft Fork）和硬分叉（Hard Fork）。

* 如果旧节点仍然能够验证接受新节点产生的交易和区块，则称为软分叉。旧节点可能不理解新节点产生的一部分数据，但不会拒绝。网络既向后和向前兼容，因此这类升级可以平稳进行。
* 如果旧节点不接受新节点产生的交易和区块，则称为硬分叉。网络只向后兼容，不向前兼容。这类升级往往引起一段时间内新旧节点所认可的区块不同，分出两条链，直到旧节点升级完成。

尽管通过硬分叉升级区块链协议的难度大于软分叉，但软分叉能做的事情毕竟有限，一些大胆的改动只能通过硬分叉完成。

## 交易延展性

交易延展性（Transaction Malleability）是比特币的一个设计缺陷。简单来讲，是指当交易发起者对交易签名（sign）之后，交易 ID 仍然可能被改变。

下面是一个比特币交易的例子。

```json
{
  "txid": "f200c37aa171e9687452a2c78f2537f134c307087001745edacb58304053db20",
  "version": 1,
  "locktime": 0,
  "vin": [
    {
      "txid": "21f10dbfb0ff49e2853629517fa176dc00d943f203aae3511288a7dd89280ac2",
      "vout": 0,
      "scriptSig": {
        "asm": "304402204f7fb0b1e0d154db27dbdeeeb8db7b7d3b887a33e712870503438d8be2d66a0102204782a2714215dc0d581e1d435b41bc6eced2c213c9ba0f993e7fcf468bb5d311[ALL] 025840d511c4bc6690916270a54a6e9290fab687f512c18eb2df0428fa69a26299",
        "hex": "47304402204f7fb0b1e0d154db27dbdeeeb8db7b7d3b887a33e712870503438d8be2d66a0102204782a2714215dc0d581e1d435b41bc6eced2c213c9ba0f993e7fcf468bb5d3110121025840d511c4bc6690916270a54a6e9290fab687f512c18eb2df0428fa69a26299"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.00167995,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 7c4338dea7964947b3f0954f61ef40502fe8f791 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a9147c4338dea7964947b3f0954f61ef40502fe8f79188ac",
        "type": "pubkeyhash",
        "address": "1CL3KTtkN8KgHAeWMMWfG9CPL3o5FSMU4P"
      }
    }
  ]
}
```

在传统非 SegWit 交易中，发起者对交易的签名（scriptSig）位于交易的输入（vin）当中，属于 txid 承诺的交易序列化内容。交易 ID（txid）由交易序列化数据 Hash 得到，这就造成了一个问题：攻击者（尤其是签名方）可以通过改变 scriptSig 来改变 txid，而交易仍旧保持合法。例如，反转 ECDSA 签名过程中的 S 值，签名仍然合法，交易仍然能够被传播。SegWit 将签名等 witness 数据移出 txid 承诺范围，修复了主要的第三方交易延展性问题。

这种延展性攻击能改变交易 ID，但交易的输入和输出不会被改变，所以攻击者不会直接盗取比特币。这也是为什么这一问题能在比特币网络中存在如此之久，而仍未被根治。

然而，延展性攻击仍然会带来一些问题。比如，在原始交易未被确认之前广播 ID 改变了的交易可能误导相关方对交易状态的判断，甚至发动拒绝服务攻击；多重签名场景下，一个签名者有能力改变交易 ID，给其他签名者的资产带来潜在风险。同时，延展性问题也会阻碍闪电网络等比特币扩展方案的实施。

## 扩容与升级

比特币社区关于扩容的争论由来已久。最终，社区选择了技术升级而非简单扩大区块容量的路线。

### 隔离见证（SegWit）

2017 年 8 月，隔离见证（Segregated Witness，SegWit）作为软分叉正式激活。它将交易中的见证数据与旧式交易序列化分离，修复了主要的第三方交易延展性问题，并通过区块重量机制提高了可承载数据量；实际容量取决于区块中传统数据和 witness 数据的比例，也为闪电网络等链下方案铺平了道路。

### Taproot 升级

2021 年 11 月，比特币网络迎来了自 SegWit 以来最大的升级 —— Taproot。它引入了 **Schnorr 签名** 和 **Merkelized Abstract Syntax Trees (MAST)**。

* **Schnorr 签名**：支持多重签名聚合成一个签名，提高了隐私性和效率。
* **MAST**：允许复杂的智能合约逻辑在链上仅展示执行分支，大幅减少了数据占用并提升隐私。

## 生态创新：铭文与符文

长期以来，比特币被视为“数字黄金”，缺乏像以太坊那样的应用生态。然而，基于 **Taproot** 升级的技术特性，新的协议让比特币网络焕发了生机。

* **Ordinals (铭文)**：2023 年初，Casey Rodarmor 提出了 Ordinals 理论，通过给每一个聪（Satoshi，比特币最小单位）编号并写入数据（Inscribing），实现了在比特币链上发行 NFT。这引发了巨大的关注和争议。
* **Runes (符文)**：2024 年，为了解决早期的 BRC-20 协议带来的大量 UTXO 集膨胀问题，更加高效的原生同质化代币协议 Runes 被推出，进一步丰富了比特币的资产发行能力。

这些创新让比特币不仅仅是储值工具，也开始承载数据和应用价值，同时也显著增加了矿工的手续费收入，增强了网络在减半周期后的安全性。

## 拥抱合规：ETF 时代

随着区块链技术的成熟，主流金融市场开始接纳比特币。

* **现货 ETP/ETF**：2024 年 1 月，美国 SEC 批准若干现货比特币交易所交易产品（ETP）份额上市交易。该批准是对交易所规则变更和产品披露框架的监管决定，不等于 SEC 认可或背书比特币本身，投资者仍需关注比特币及相关产品风险。
* **监管追踪**：虽然比特币地址是匿名的，但通过 **链上分析 (On-chain Analysis)** 技术，结合合规交易所的 KYC 信息，监管机构可以有效地追踪非法资金流向。“完全匿名”在比特币上已不复存在。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://yeasy.gitbook.io/blockchain_guide/06_bitcoin/hot_topics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.