官方的 MASTR 标志 MASTR
菜单
阅读文章

MASTR · CRYPTO & WEB3

Bitcoin’s early lesson: money rules need independent verification

Keys authorise a spend, nodes decide whether it is valid, and proof of work orders the valid history. None of those jobs should be confused.

起源与历史 · 2009 onward · 3 分钟阅读

章节正文和技术图表为英文,导航支持七种语言。

Can a powerful miner make an invalid payment valid?

Three jobs behind one balance

A wallet balance is a convenient summary of spendable outputs. The private key authorises particular spending conditions; it does not instruct every node to accept any amount the signer chooses. A validating node checks the transaction against the rules and its view of existing outputs. A miner proposes a block ordering transactions and demonstrating work. Keeping these roles separate explains why a large mining share and ownership of somebody else’s coins are different kinds of power.

The ledger is verified state

A node does more than download a list of transfers. It checks that inputs exist and are not already spent, that their spending conditions are satisfied and that outputs do not create unauthorised value. Blocks also have consensus conditions. A block explorer displays a provider’s interpretation of this process. Running a node can reduce dependence on that provider, although the operator still needs appropriate software, connectivity and security. An attractive explorer interface is not another consensus vote.

Authorisation → validation → accepted history
教学示意图:简化机制并注明假设,不构成特定事件的证据。 打开完整图表 ↗

The history contains software failures

Bitcoin Core’s September 2018 disclosure of CVE-2018-17144 describes both denial-of-service and inflation vulnerabilities and the release of fixes. That disclosure is an important historical source because it shows that a monetary rule written in prose is not enough: implementations have to enforce it correctly. It does not establish that arbitrary coins were successfully created and accepted everywhere. Distinguish the existence of a vulnerability, its exploitation and its observable effects.

Inclusion and finality are not the same

A payment appearing in a recent block means it is included in one accepted history. A competing history can replace recent blocks. Additional confirmations make ordinary reversals more costly under the relevant assumptions, but there is no universal confirmation count suitable for every amount and threat model. An application crediting a deposit before settlement is extending trust. Its policy is separate from the network’s validity rules.

A practical reading habit

When a story says that Bitcoin was hacked, ask which component failed: a wallet, an exchange database, a signing device, a mining pool, a node implementation or consensus itself. A stolen exchange account does not demonstrate a failure of Bitcoin signatures. Conversely, a functioning chain does not repair an exchange’s missing customer assets. Historical accuracy requires naming the layer and the evidence, not merely the asset ticker.

示例解析

Suppose a transaction tries to spend an output twice inside one block. The question is whether the node’s implementation rejects that block, not whether the miner has a famous name or substantial hash power. Validity comes before comparison of competing valid chains.

思考问题

  • Name the failed layer.
  • Distinguish a vulnerability from observed exploitation.
  • Separate a deposit credit from final settlement.

一手资料与延伸阅读

  1. Bitcoin developer guide: transactions ↗
  2. Bitcoin Core: CVE-2018-17144 disclosure ↗
  3. Bitcoin white paper ↗

继续探索

学习路径

MASTR

支持独立研究

这里的调查、原始证据和指南均可免费阅读。自愿捐赠帮助支付研究成本,让 MASTR 能够继续提供工具。

打开钱包