多金快讯 / 知识读本 · 比特币 · 2 分钟阅读
“已广播”“已确认”和“交易所已入账”描述的是三个不同阶段。确认数帮助收款人管理交易被替换或区块被重组的风险，却不是一个跨场景通用的保险数字。判断等待多久，需要同时知道收款规模、交付是否可撤回和你信任的数据来源。
从内存池到区块历史
未确认交易可能只存在于部分节点的内存池中。不同节点的接收策略、容量和连接状况不同，因此某个浏览器查不到交易，并不证明全网没有见过它。交易被有效区块收录后获得第一次确认，后续接在该区块之后的区块会增加确认数。
矿工有时同时找到不同区块，网络最终可能选择累计工作量更高的有效分支。短暂重组会让某笔交易失去原来的位置，交易可能重新等待收录，也可能与另一笔花费发生冲突。
算例：高度与确认数
假设付款位于高度八十万的区块，当前有效链尖高度八十万零二，确认数是三，即当前高度减收录高度再加一。这里没有使用分钟作为判断依据，因为出块间隔具有随机性，经过半小时并不保证恰好出现三个区块。
商户如果在第一次确认后立刻寄出不可追回的贵重商品，承担的风险与提供一杯低价饮料不同。确认门槛应成为业务规则，并明确异常时如何暂停交付，而不是临时听取付款人的截图解释。
零确认为什么需要额外信任
交易进入内存池并未锁定其最终排序。手续费不足、输入存在冲突或节点策略变化，都可能影响后续收录。可替换交易标记有参考意义，但没有替换标记也不应被视作不可双花的证明。
收款方应直接核实交易的输入和目标输出，不能把钱包弹窗或转账凭证当成结算。托管平台还可能要求内部风控通过；平台显示未入账，未必意味着链上未确认，需要分别排查。
把等待策略写成流程
先确定由哪个节点提供有效链高度，再决定不同金额档位的交付规则。发现确认数倒退时，应检查是否发生重组、节点同步延迟或浏览器故障，暂停后续业务动作，并保存交易标识与区块哈希。
对长期保存证据的场景，区块高度不够精确，应连同区块哈希记录，因为同一高度可能曾出现不同候选区块。支付处理系统还要允许状态回退，避免把第一次出现的“成功”永远写死。
实用检查清单
- 直接核对收款输出，区分钱包通知与链上确认。
- 按金额与交付可逆性设定等待规则。
- 监测节点同步高度，保留重组后的重新核对流程。
常见问题
确认越多就绝对无法修改吗？
确认增加通常提高重写历史所需的成本，但不能把概率性的安全描述成数学上的绝对不变。还要确认节点本身采用正确规则且已同步。
超过一小时还没确认是否已经丢币？
时间长本身不能得出结论。先检查交易是否仍在节点内存池、费率是否足够以及输入是否被另一笔交易花费，再考虑钱包支持的加速方式。