比特币Median Time Past是什么? 图 1
比特币Median Time Past是什么? · 图 1

区块头里有timestamp,但比特币不会把一位矿工写入的单个时间直接当作所有时间锁的可靠时钟。Median Time Past,简称MTP,是过去11个区块时间戳的中位数;BIP 113让交易时间锁的共识判断使用它,从而降低单个异常时间戳提前释放交易的影响。

MTP不是北京时间、UTC当前时刻,也不是11个值的平均数。

11个时间戳怎样取中位数

取目标链尖之前的11个区块时间戳,按数值从小到大排序,选择第6个。极端偏早或偏晚的少数值被排到两端,不会像平均数那样强烈拉动结果。

假设排序后是:100、102、103、104、105、106、107、108、109、130、150,中位数是106。即使最后两个时间戳明显偏大,MTP仍由中间位置决定。

在验证新区块中的交易时,节点使用前一链尖的过去中位时间作为参照。区块浏览器展示某个块的mediantime时,通常表达截至该块的过去中位时间。写程序时要明确你比较的是哪一个链位置,避免差一块。

为什么不直接使用新区块时间

矿工可以在共识允许范围内选择区块timestamp,它并不要求与现实时间精确一致。若绝对时间锁直接使用候选块自己的时间,出块者可能把时间拨快,让本应稍后生效的交易提前进入区块。

中位数要求多数窗口共同移动,单个值无法立即推动结果。由于新区块时间还必须大于之前的MTP,过去中位时间也提供了随链推进的共识顺序。

MTP如何影响nLockTime和CLTV

BIP 113把时间型nLockTime的最终性判断改为使用前一块MTP。BIP 65的CLTV又会检查交易nLockTime是否达到脚本的绝对门槛。因此,某些钱包显示的“到某时可花费”,实际要等链上MTP越过阈值,而不是手机时钟刚刚到点。

高度型锁定仍按区块高度,不使用MTP;相对时间锁还涉及BIP 68与CSV。三类机制的整体区别可用原始BIP复核,签名时也要同时检查sequence。

MTP可能落后于现实时间

11块窗口取中位位置,天然会反映较早的一组区块;区块间隔又不是固定十分钟。因此MTP可能比当前墙上时间落后,差值也不是一个可承诺的常数。把“预计解锁时间”精确到分钟,会造成错误期待。

手续费同样无法绕过这一步。未满足锁定条件的交易不能靠高费率提前确认;条件满足后,才进入普通打包竞争。有关虚拟大小和费率的计算可参考比特币vbytes和sat/vB怎么算,卡住后的替代方案见RBF和CPFP怎么选

用Bitcoin Core核对mediantime

Bitcoin Core的getblockheader在verbose结果中返回time与mediantime。time是该区块头自身时间戳,mediantime是过去中位时间。排查时记录区块hash、高度、time和mediantime,不要只截取浏览器格式化后的“几小时前”。

如果要独立复算,可取连续11个区块头的time字段排序并选中位数,再与节点结果比较。应从自己信任的规范链节点取数据;链重组后,同一高度的区块hash和窗口都可能变化。

四个常见误读

第一,把MTP当11块平均值;正确是中位数。第二,把某区块timestamp当MTP;它们是两个字段。第三,用本地系统时间判定共识有效;节点按链上规则验证。第四,认为到期会自动广播;时间条件满足只让交易变为可接受,UTXO仍需未被花费,签名和手续费也要有效。

UTXO是否仍可花费可结合比特币UTXO是什么核对。预签交易存放时间较长时,还应防止同一输入被另一笔交易消费。

面向用户的判断流程

先确认锁定值是高度还是时间;若是时间,找到相关链尖和MTP;等待MTP越过门槛;随后重新检查UTXO、签名、找零和费率;广播后以交易进入规范链为准。任何钱包给出的日历时间都应视为估算,不是共识承诺。

本文用于比特币共识时间和链上数据教育,不构成托管或交易建议。不同节点、浏览器和时区的展示可能不同,关键操作请固定区块hash并用Bitcoin Core等可信节点复核原始字段。