Bitcoin Whitepaper

Whitepaper 用来提出问题并介绍解决方案。Bitcoin 的文档从一个日常问题出发：我在网上给别人汇款时，中间一定要有银行或其他管理者吗？2008 年 10 月 31 日，Satoshi 向密码学邮件列表发送了方案，并附上正文链接。他没有承诺 bitcoin 的价格或投资回报，而是在解释：人们能否不把决定支付历史的权力交给一家公司，也能收款？这个问题贯穿整份文档。 [2] [1]

假设发送者签署两笔不同的支付，两笔都花费同一笔钱。一位收款人看到第一笔，另一位看到第二笔。双方都能验证有效的数字签名，也就是付款权限的证明，却不可能都收到这笔钱。网上数据很容易复制，单靠签名解决不了这个问题。因此第 2 节区分了支出权限与哪笔支付能够进入共同历史这两个问题。Bitcoin 在签名之外加入公开记录，让参与者识别哪些资金已经花掉。 [1]

第 3–5 节介绍把支付汇集成区块。每个新区块通过 hash 指向前一个区块；hash 是数据的简短数字指纹。修改旧记录会改变指纹，破坏原有连接。Proof of Work 再加入有成本的计算：生成合格区块需要反复尝试，而验证结果很容易。因此，当分支发生竞争时，起作用的是遵守规则的历史所积累的工作量，而不是创建了多少账户或 IP 地址。文档把它称为最长链。但再多工作量也不能让无效交易变得有效。链条确定事件顺序，而不是每笔支付的精确时间。 [1] [3]

计算机和电力都需要成本。第 6 节因此加入经济激励：被接受区块的创建者可以获得新发行的币和其中支付的手续费。手续费是交易消耗的价值与新输出价值之间的差额，不是凭空多造出来的币。文档还设想了将来只靠手续费提供奖励的情况。但读者也要了解方案的边界：whitepaper 没有给出 2,100 万的确切上限，也没有规定每 210,000 个区块减半。这些规则需要查阅其他 Bitcoin 资料。 [1] [3]

并非每个人都愿意下载并验证全部交易。第 8 节提出 SPV，即简化支付验证。客户端获取区块头，其中包含区块的基本摘要数据，再取得 Merkle 证明：一条连接 hash 的路径，用来证明某笔交易被收录在区块中。这就像确认某条记录出现在一本账簿里，与检查整本账簿是否正确的区别。收录证明本身并不检查所有规则和完整支出历史。Whitepaper 明确承认这个限制：与自行检查交易的 Full Node 相比，简化客户端更容易受到某些攻击。 [1]

银行体系中的许多支付记录不公开。Bitcoin 却需要共同历史，因此必须采用不同的隐私保护方式。第 10 节解释把支付与密钥持有者的身份分开，并建议后续交易使用新的密钥对。它也承认弱点：支付可能被关联起来。一旦某条记录对应的人被识别，其他支付也可能暴露。新地址因此不是神奇的伪装。它能减少部分联系，却不会自动抹掉公开历史中的信息，或交易对方已经掌握的情况。 [1]

第 11 节讨论攻击者追上诚实参与者所生成链条的概率。可以把它想成一场比赛：一方已经领先，但双方都在继续努力。在文中模型里，攻击者的算力份额越小，链条领先越多，追上的机会就越低。计算依赖一些假设和泊松近似，后者是估算一段时间内事件数量的数学简化方法。它不是对所有真实攻击的预测。因此，不能从表格里单独拿出一个数字，就把它当成任何支付都安全的确认次数。 [1]

文档解释的是原始设计。网络和软件此后不断演进，例如 BIP 141 所描述的 SegWit 就不在其中。BIP 是介绍改进提议的文档，不是发布后便自动成为网络规则的决定。因此，理解当前技术问题时，需要区分提议、程序、实际执行的共同规则，以及节点是否转发交易的本地决策。节点可能不转发某笔交易，却在之后包含它的有效区块中接受它。这两种情况并不矛盾。 [4] [3]

先读摘要，理解没有管理者时如何阻止双重支付这个问题。然后跟着看，签名、共同历史和创建区块所需工作分别补上了哪一部分答案。如果数学让你停下来，不必立刻弄懂每个公式：先理解计算针对什么攻击，以及它依赖什么假设，细节可以以后再看。原始邮件记录 Satoshi 何时介绍方案，PDF 则给出完整论证。脱离整体的一句话，并不能证明某个钱包或服务一定安全。 [2] [1]

重点不是背下各节标题，而是理解为什么单个部件都不够：签名证明权限，公开历史帮助识别双重支付，Proof of Work 增加改写顺序的难度。这些部件各有前人的工作，Satoshi 也在参考资料里引用了它们。贡献在于组合方式。如果把 whitepaper 读作一份经过论证、依赖具体假设的方案，它仍然是理解 Bitcoin 思路的好起点。它不是价目表、投资指南，也不是今天所有冠以 Bitcoin 名称的规则和工具的完整规范。 [1]