比特币 6 个确认是高额交易的建议下限而不是协议规定

确认数(Confirmations)数的是区块:交易被打进一个区块记 1,这个区块后面每接上一个新区块再加 1。比特币开发者文档列了 0、1、2、6 四档参考刻度,其中 6 是给高额交易的建议下限。这份文档是写给收款程序看的,要等几个确认,由收款一方自己取舍。

比特币 0、1、2、6 个确认各代表什么?

比特币开发者文档的 Payment Processing 页有一节讲收款方怎么验证付款(Verifying Payment)。协议按「想换掉这笔交易得改动多少个区块」给每笔交易一个不断更新的置信分数,交易上面每多一个区块,就多一个确认。改动区块相当困难,分数越高,交易受到的保护越强。

把交易所在的区块记作第 N 个。链上最新的区块就是第 N 个时,确认数是 1;最新区块排到第 N+5 个,确认数是 6。

双花指同一笔币被花出去两次:网络最终收下的若是付款人的另一版交易,付给你的那一版就落空。

6 这个数,文档写明多少带点任意(somewhat arbitrary)。它的身份是一条建议,对象是处理高额交易、或者有被欺诈风险的软件。比特币网络不会在第 6 个确认时给交易盖一个完成的章,第 7 个、第 8 个确认照样往上加。

同一节还要求收款程序在下面这些情形另做双花风险分析:

• 程序或它的用户等不了确认,想接受未确认的付款;
• 收的是高额交易,却等不了至少 6 个确认;
• 出现实现上的缺陷,或者有针对比特币的长时间攻击,让系统不如预期可靠。

为什么比特币转账的第一个确认有时要等很久?

出块时间本身不固定。bitcoin.org 的 Some things you need to know 页说,新区块平均大约每 10 分钟加进区块链一个,但找到区块这件事是概率性的,单个确认来得早得多或晚得多都有可能,延迟没有保证的下限,也没有保证的上限。

手续费是第二个变量。交易付的手续费低于网络当时优先处理的水平,第一个确认可能明显更久。平均 10 分钟拿到一个确认这个数带着前提:交易付了足够的手续费。

按平均数算,6 个确认大约是 60 分钟。这是平均值,轮到某一笔具体的转账,六个区块用掉的时间可以比一小时短,也可以比一小时长。

确认数停在 0 时,拿交易哈希到区块浏览器里查这笔交易,这串字符在转出方的转账记录里能复制到。浏览器显示它是未确认,说明交易已经广播出去,在等区块收它,这时别急着再发一笔同样的转账。

发送界面让你自己选手续费时,选低的那一档,代价就是前面说的更久的等待。

以太坊的最终确定大约要 15 分钟

以太坊这边,官方文档讲交易安全时用的刻度是最终确定(Finalized)。按 ethereum.org 的权益证明(Proof-of-stake)说明页,交易所在的区块要是不烧掉大量 ETH 就无法改动,这笔交易就具备了最终性。

以太坊把时间切成时隙和时段:一个时隙 12 秒,一个时段 32 个时隙。一个时段的长度是 32 × 12 秒 = 384 秒,也就是 6.4 分钟。

每个时段的第一个区块是检查点。验证者给成对的检查点投票,一对检查点拿到的票代表了全部质押 ETH 的至少三分之二,两个检查点就各升一级:较新的那个变成已合理化,较早的那个在上一个时段已经合理化过,这时升为已最终确定。

区块最终确定之后,想把它改回去,攻击者得准备好损失质押 ETH 总量的至少三分之一。

从出块到最终确定要多久,ethereum.org 路线图里的 Single slot finality 页给的数是大约 15 分钟。它讲的是一个区块在链上走完这道程序的时间。

区块浏览器显示已确认但对方没到账怎么办?

区块浏览器里这笔转账已经有确认,对方账户却还是空的,先比两个数:浏览器里的当前确认数,和收款方充值页或订单页上标的要求确认数。页面只写了等待网络确认、没有具体数字,就问对方客服这个币要求几个。

当前数小于要求数,这笔钱还在等区块。每出一个新区块,确认数加 1;区块是全网出的,收款方的客服加快不了它。

当前数已经达到要求数,对方仍未入账,原因在确认数以外:核对收款地址、所选网络,以及有没有漏填 Memo 或 Tag,再带着转账凭证联系收款方客服。

发出去的转账能不能撤回