双重支付

假设汤姆此前收到一个价值 100 000 sat 的输出，sat 是比特币的最小单位。尚未花费的输出叫作 UTXO。他准备向爱丽丝支付 99 000 sat，把 1 000 sat 留作手续费。但他也可以签署另一笔交易，花费同一个 UTXO，却把钱转到别处。两笔交易使用同一个资金来源，因此彼此冲突。这并不像复制文件：比特币节点是负责检查规则的计算机，不会允许同一个输出在一条有效链上被花费两次。如果爱丽丝因第一笔付款交出商品，最终被接受的历史中却留下第二笔，欺诈就成功了。没有新币产生，只是爱丽丝信任了落败的版本。从技术上说，每个输入通过此前交易的标识符 txid 和输出编号来指定一个旧输出，这一对信息叫作 outpoint。 [1] [3] [7]

爱丽丝可能几秒钟就能看到一笔转入，但这不代表交易已经写进区块。Mempool 是单个节点保存未确认交易的本地集合。比特币没有唯一的全球 Mempool，也没有全网统一的交易到达顺序。另一个节点可能先收到冲突版本，甚至还没有见过爱丽丝的版本。first-seen 策略是在转发交易时优先保留最先收到的版本，并不承诺矿工会把它放进区块。因此，钱包截图或单独一个 txid 不能证明付款已经结算。应当关注的是，这笔具体付款在可靠验证的链上处于什么状态。 [2] [5]

也可能是爱丽丝自己发出一笔正常付款，却迟迟等不到确认。Replace-by-Fee（RBF）允许替换未确认交易，通常是换成手续费更高的版本。txid 虽然改变，收款人仍可能收到原来的金额。新版本使用了至少一部分相同资金，因此技术上与原交易冲突，却不意味着有人想骗走收款人的钱。应当看新付款的内容和具体情况，而不是只看 RBF 标签。不过，同一种机制也可以把资金转向其他地方。Bitcoin Core 从版本 28 起默认采用 Full-RBF，不要求原交易事先声明可被替换。替换交易仍须满足节点的手续费和防滥用规则。所以，没有 RBF 信号的未确认付款也不等于不可逆。 [5] [6] [15]

付款进入节点接受的有效区块后，就获得一次确认。后续区块通常会增加替换这段历史的难度，降低欺诈成功的风险。但不存在适用于所有情况的安全确认数。损失一杯咖啡的钱，与交付一辆汽车或放行交易所的大额提款，后果完全不同。常说的六次确认是一种惯例，不是比特币规则。收款人应考虑金额、能否补救、链是否出现异常以及信息来源是否可靠。隔离节点的 Eclipse Attack 可能扭曲节点看到的网络。因此，等待应当配合验证，而不是代替验证。 [2] [10]

节点转向另一条有效分支称为重组。Proof of Work 证明生成区块所需的工作，而分支累计的工作量叫作 chainwork。 付款确认后，就不能再通过 Mempool 中的交易替换来撤销它。另一条有效分支必须排除原付款、纳入第二笔花费，并积累比收款人当前活动链更多的工作量，也就是 chainwork。没有欺诈也可能发生链重组，例如区块几乎同时被挖出，或软件、网络出现故障。只有攻击者因冲突交易获胜而取得价值，才算对受害者实施了成功的双重支付。对于钱包中落败的交易，Bitcoin Core 可能在 confirmations 字段显示负数的确认数，并在 walletconflicts 字段列出相关冲突。 [4] [7] [8]

Hashrate 是挖矿计算的速度。占比更高有助于争夺交易历史，但不意味着可以绕过其他规则。 秘密挖出的分支能否追上诚实链，取决于攻击者占全网算力的比例、确认数等因素。能够获取的价值主要影响的是发动攻击是否划算。占比低于 50 % 并不意味着成功机会为零；持续占据多数会显著提高追上另一条分支的可能性。但即使占据多数，矿工也不能伪造签名、花费他人的 UTXO、违反发行规则，或强迫全节点接受无效区块。评估攻击时，需要考虑算力、能源以及放弃诚实挖矿而损失的奖励。可用资金、失败风险和被发现的可能性也很重要。收益也可能包含金融市场头寸带来的利润，因此仅凭矿机租赁价格不足以估算攻击的得失。 [1] [10] [12]

这里的 race 指时间上的竞赛：收款人和矿工可能分别先看到不同的交易。 race attack 是一种抢在付款确认前得手的竞速攻击。付款人把一笔交易发给商户，同时把冲突交易发给矿工或其他节点，试图让商户在区块选定其中一笔之前，就不可撤回地交出商品。结果取决于交易传播、商户看到的网络情况、矿工的选择，以及交货时点。用多个独立节点监控网络有助于发现冲突，却不能保证不可逆的结算。race、Finney 和 Vector76 这些名称描述的是攻击场景，不是交易数据字段，也不是不同的共识规则。 [2] [11]

Finney attack 是一种特定攻击场景，攻击者除了发起付款，还具备挖矿能力；它不是钱包正常提高手续费的行为。 在 Finney attack 中，具备挖矿能力的攻击者先私下挖出一个区块，其中包含一笔将价值转回给自己的冲突交易。随后，他用同一个 UTXO 向接受未确认付款的商户支付，拿到商品后再公布隐藏的区块。只有这个区块仍然可用，而且网络在诚实矿工挖出的竞争区块打乱计划之前接受它，攻击才会成功。攻击者因此要承担损失区块奖励和挖矿成本的风险。等待商户的交易进入已验证的区块，可以打断这种经典攻击流程，但不能消除以后发生链重组的风险。 [1] [11]

RPC 是节点的编程接口。下面的名称是支付系统开发者使用的命令和字段，并非另一种确认。 商户系统可以在自己的全节点上监控 Mempool 中的冲突花费，调用 gettxspendingprevout，读取 walletconflicts 字段，比对活动链的最新区块，并在确认数丢失时报警。连接更多节点，或使用更多独立节点，可以减少盲区；但没有发现冲突，只能提供很弱的安全证据，因为攻击者可以扣住冲突交易不发，或从其他路径发送。区块浏览器展示的是它自己的节点视角，也可能有延迟。发现冲突可以让商户停止交货，却不能命令矿工选择哪笔交易，也不能让未确认付款获得与已确认付款相同的保障。 [8] [9] [11]

检查真正收到的付款、目标地址、金额和确认数。发送方提供的凭证不能替代这些检查。运行自己的全节点可以直接验证规则；使用他人的服务时，要弄清信息和资金托管依赖谁。商户系统应把订单与具体输出关联起来，并持续跟踪交易替换。如果出现冲突或确认丢失，就应暂停无法撤回的交付。后续交易如果花费了未确认的找零，它仍然依赖原交易，并不是原付款安全性的独立证明。Lightning Network 通过由比特币交易注资的通道实现快速付款。通道双方交换已签名的 commitment 交易，记录资金如何分配。更新通道时，双方会向对方交出秘密数据；如果随后公布过时状态，对方就能据此实施惩罚，这种使旧状态失效的机制称为 revocation。保护的前提是及时发现这种尝试并作出响应。因此，它不同于看到未经确认的链上转账就交货。未经确认就启用的通道，即 zero-conf channel，会主动信任出资方，注资交易被双重支付的风险依然存在。 [13] [14]