确认

Alice 给朋友发送 20 000 sat，sat 是比特币的最小单位。她的钱包显示已发送，朋友也已看到入账交易，但确认数仍为零。这并不矛盾：付款信息已在节点之间传播，也就是在验证比特币的计算机之间传播，却还没有进入区块。Mempool 是某个节点本地保存未确认交易的地方，并非全网共用的一条队列。付款进入被接受的区块后，就有第一次确认。下一个相连区块带来第二次，再下一个带来第三次。Alice 无须再次发送。广播交易不等于确认，交易标识 txid 也不能保证确认。未确认交易可能被替换，例如通过 Replace-by-Fee（RBF）提高手续费。接受未确认付款称为 zero-conf，这意味着承担同一笔资金的另一笔花费最终被确认的风险。 [4] [8] [11]

矿工挑选交易组成新区块，并寻找有效的 Proof of Work，也就是比特币规则要求的、需要付出计算成本才能找到的结果。其他全节点随后独立检查区块：签名、金额和花费条件是否正确，资金是否尚未花费？这不是矿工投票，也不是某家公司盖章批准。矿工不能把无效付款放进区块就让它变得有效。节点只在自己接受的链上把交易计为已确认。在有效分支之间，节点选择累计工作量最大的分支，这种工作量称为 chainwork。每个区块都引用前一个，因此修改较早的历史还需要重建它后面的部分。 [2] [7]

比特币以平均十分钟一个区块为目标，并不按时刻表运行。下一个区块可能几秒后出现，也可能晚得多。等了一小时并不自动意味着已有六次确认。更高的手续费率可能增加矿工选中交易的机会，但不会加快区块产生。有的钱包支持 RBF，用更高手续费的交易替换未确认交易；或者支持 CPFP（Child Pays for Parent），让依赖前一笔交易的新交易支付足够手续费，使矿工愿意把两笔一起打包。能否使用取决于钱包和交易本身。低手续费可能导致久等，或被节点从 Mempool 移除。因此，钱包显示的等待时间是估算，不是承诺。 [3] [4]

收款人或服务商决定收到多少次确认后接受付款。小额购物可以容忍的风险，可能不同于不可撤销地交付昂贵商品。如果交易平台要求多次确认，交易可能已经在区块链上，但平台账户余额尚未入账。这不一定表示付款出错。应在自己的钱包核对金额、目标地址和状态，并查看服务商的入账要求。信息来源同样重要。攻击者可能隔离一个节点，只给它有限的网络视图，这称为 Eclipse Attack。因此，合适的等待程度取决于金额、能否补救、对交易对方的信任和验证方式。确认数本身无法防止私钥被盗。 [11] [13]

可以把付款想成一条记录，后面不断叠加新的历史书页。攻击者不能只改动某一张旧页，而必须构建一条有效的竞争历史，并积累足够的工作量。在通常的假设下，确认越多，这件事越难。但结果也取决于攻击者的计算能力与网络状况。常说的六次确认只是历史经验，不是共识规则，也不是绝对安全的神奇分界线。不能用一个固定概率诚实地代表所有情形下的历史改写风险。更多确认也不会纠正错误地址，或撤回已经付给骗子的钱。 [1] [13]

两个矿工几乎同时找到区块时，即使没有攻击，也可能短暂分叉。节点切换到另一条胜出分支称为重组。交易输出记录金额和花费条件；后续交易的输入引用并花费它。尚未花费的输出称为 UTXO。如果另一条有效分支积累了更多工作量，也就是 chainwork，节点会断开原链末端的区块，接上胜出的分支。被断开区块中的交易，如果仍然有效，可能回到 Mempool；也可能在另一个高度重新获得确认。如果新分支已经花费了它的输入所引用的同一个输出，这笔交易还可能变成冲突交易。Bitcoin Core 中 confirmations 的负值，是钱包表示冲突深度的方式，并不意味着共识规则中存在负数的区块数量。 [5] [7]

区块高度是区块在序列中的位置，从编号为零的初始区块开始计算。如果交易所在区块的高度为 h，节点活动链最后一个区块的高度为 H，确认数就是 H − h + 1。也就是说，包含交易的区块本身算作第一次确认。结果取决于该节点已验证的最佳区块，因此新块到达时，各节点之间可能暂时有差异。这个数值不属于交易本身，不会仅因时间流逝而增加，也不能从时间戳可靠地推算出来。Bitcoin Core 根据相应钱包或 UTXO 视图所掌握的状态，返回 blockhash、blockheight、confirmations 等数据。 [3] [5] [6]

SPV 指简化支付验证，RPC 则是查询节点的程序接口。即使两个应用显示相同的确认数，验证方式的区别仍然重要。全节点验证区块链，并根据自己已验证的链的当前末端作答。SPV 客户端检查区块头中的 Proof of Work，以及证明交易已被纳入的 Merkle 证明，但不会自行验证全部共识规则。Merkle 证明利用一小组数据的密码学指纹，就能证明交易包含在某个区块中，无须下载该区块的全部交易。代用户保管资金的服务还会采用自己的入账和风险管理规则。即使是全节点的 RPC 返回结果，也只是某个时点的状态，链重组可能改变它。因此，除了确认数，还要看用户信任的是谁的链视图、验证过程和资金保管。 [1] [2] [8]

Coinbase Transaction 是区块中特殊的第一笔交易，用于支付矿工奖励，与 Coinbase 交易平台无关。时间锁限制资金何时可以花费。BIP 是技术提案或标准文档。确认也会启动某些协议等待期。coinbase 交易的输出受 COINBASE_MATURITY = 100 规则约束：最早只能在比包含这笔 coinbase 交易的区块高 100 的区块中花费。这是花费区块奖励前必须遵守的等待期，不是普通付款收款人的选择。BIP68 相对时间锁以被花费输出的确认为起点，按区块数或时间规则判断它已经历的间隔。脚本是一段规定输出花费条件的简短程序。BIP112 的 CHECKSEQUENCEVERIFY（CSV）指令可以在脚本中强制执行这一相对条件。花费未确认输出的交易，仍然依赖创建该输出的交易。要让后续交易获得确认，它的前置交易必须已被纳入同一个或更早的区块。 [9] [10]

Lightning Network 通过由比特币交易注资的通道进行支付。BOLT 是其技术规范的名称；这里讨论的是开通通道，并非通道内每次付款都等待区块。BOLT 2 允许接受 Lightning 通道的一方，在发送 channel_ready 消息前，通过 minimum_depth 字段规定注资交易所需的确认数。这项要求用来考虑注资遭遇双重支付的风险。未经确认就开启的通道，即 zero-conf channel，把 minimum_depth 设为零，明确选择依靠对出资方的信任以及协议限制，并不会因此获得即时、不可逆的结算。如果注资交易本身就是 coinbase 交易，BOLT 2 要求没有发起通道开启的一方至少等待 100 个区块。运营者应监控具体的注资输出，即 funding outpoint、它在活动链中的深度，以及链重组。仅仅广播 txid，并不意味着通道已经打开。 [12] [14]