Finality

保罗最初看到的，只是钱包已经知道这笔交易。这不等于交易已被纳入区块。区块形成、后续区块不断接上之后，要替换这段历史，就需要超过越来越多的工作量。这就是实际意义上的 Finality 如何增强。不过，潜在攻击者的资源和网络状态仍然重要。协议不会签发一张数学上的“绝对不可逆证明”；收款人需要判断，接受这笔具体付款的依据究竟有多充分。 [1] [2]

Full Node 会独立验证 Bitcoin 的规则，不会仅因为一段历史很长就接受它。节点先确认历史有效，再从有效分支中选择累计工作量最大的分支。这里比较的是区块证明的工作量，不是按人数或持币量投票。再多的工作量也不能让无效交易变得有效。对保罗来说，两个问题都要核实：付款是否符合规则，以及它在当前采用的有效历史中已经埋得多深。 [1]

在这个例子中，保罗的交易位于高度 800000 的区块，同一分支的当前末端高度为 800005。高度表示区块的位置，不是时间。计算为 800005 − 800000 + 1 = 6 次确认，其中包含交易所在的区块本身，并非只计算之后增加的区块。如果付款仅存在于 mempool，也就是该节点收集的未确认交易集合中，它就有 0 次确认。单纯等待不会增加这个数字。 [2] [3]

网络可能短暂获知相互竞争的区块，随后沿着另一条工作量更大的有效分支继续前进。这种活动历史的变化称为重组。在 Bitcoin Core 28.0 的文档中，查询区块头的 getblockheader 会在该区块不属于活动链时返回 confirmations = -1。这描述的是区块状态，并不表示其中所有付款都已丢失。保罗的交易可能也出现在新分支中，可能变为未确认，也可能与另一笔交易冲突。必须重新检查这笔交易的具体状态。 [1] [3]

开发者指南提到，6 次确认是大额付款常用的接受门槛，同时也说明了风险评估的必要性。这是收款人的接受规则，不是 Bitcoin 共识发生变化的开关。保罗应考虑自行车的价值、可能损失多少，以及验证是否可靠；一个数字不能替他做决定。平均大约一小时，也不意味着六个区块每次都能在一小时内出现。挖矿没有固定时刻表，较早的通用建议并非适用于所有情况的保证。 [2]

保罗可能已经收到有确认的 BTC，却仍然与买方争论车辆交付或车况。PFMI，即金融市场基础设施的国际原则，要求明确最终结算的时点，以及参与者不能再撤销指令的界限。这个框架不同于计算 Bitcoin 区块数。确认次数本身不能决定合同的法律效力、银行付款的最终性，或所售物品的所有权是否转移。核实付款固然重要，但不能替代交易的其他条件。 [4]

如果保罗和买方同意退款，通常需要由原付款的收款人发送一笔新交易。原来的转账仍保留在历史中。Bitcoin 没有一个中央客服部门，可以应客户要求按下按钮取消已确认付款。重组是网络活动历史的变化，不是纠正操作失误的客户服务。因此，发送前就要核对收款人和金额；多等几次确认，无法修复填错的付款。 [5]

对于支付应用的运营者，接受付款并不意味着工作结束。应用应记录交易、所在区块和验证来源，并识别节点是否落后于网络。confirmations 只是查询时的状态，不是永久证书。如果次数下降或出现冲突，应用需要按事先制定的规则处理，并重新检查活动分支。旧截图不是新的证据。对保罗而言，实际做法很简单：根据付款目前的状态决定，而不是仅凭钱包曾经显示过什么。 [2] [3]