一笔普通转账里不常见的字段
用区块浏览器或 getrawtransaction 查看比特币交易时，很多人会发现最后一行的 nLockTime 不是零，而是一个非常接近当前链尖高度的整数，多半正好等于链尖高度、偶尔略低几十块。第一反应往往是：这笔交易是不是设置了某种倒计时，会不会要等很久才能花？事实恰恰相反——这个写法是钱包在主动做一件好事：告诉网络，这笔交易只应该进下一个块，不要进别的分叉。
什么是费用狙击
所谓费用狙击，是一种针对矿工的激励设想：如果某个块里堆积了大量高费率未确认交易，一个矿工在打包当前块之后，理论上可以不再继续扩展这条链，而是私下另起一个块，把同一批高费率交易重新收进自己的块里，赌自己的块成为主链，从而把这批手续费再赚一遍。对算力占比高的矿工来说，这种“打两下”的策略在数学上未必亏。防费用狙击的思路很简单：让交易天生拒绝被塞进“回头”的块——把 nLockTime 写成基于高度的数值，并且只比链尖高一块，也就是说只有正向延伸的下一个区块才满足它的锁定条件，落在旧高度分叉上的复制版交易直接无效。
Bitcoin Core 钱包实际怎么写
以比特币核心 v29.0 的钱包代码为准（src/wallet/spend.cpp 中的 DiscourageFeeSniping 逻辑），创建普通支付时钱包会做三件事。第一，把 nLockTime 设为当前区块高度，含义是“下一块起可打包”。第二，有十分之一的概率，再把这个高度随机往前推零点到一个九十九个块之间——这是顺手给高延迟场景（例如混币类多轮协作流程里交易被压了很久才广播）留隐私余量，让交易即使晚几个块出现也能被打包，同时这类数值分布本身让外界更难根据字段猜发送者。第三，所有输入的 nSequence 都不能写成终极值：要么用代表可替换的 0xFFFFFFFD（符合 BIP125 的 RBF 信号），要么用不启用替换但同样非最大的 0xFFFFFFFE，否则基于高度的 nLockTime 根本不会生效。还有一个容易忽略的分支：当节点自身还没追上链尖时，钱包会把 nLockTime 直接写零，因为这时按高度锁定既起不到防狙击作用，反而会暴露节点落后的状态。
它为什么不会拖慢你的转账
关键在“基于高度”这四个字。nLockTime 填高度值时的生效条件是“区块高度严格大于该值”，而链尖高度加一就是下一块，所以只要网络正常出块，下一块就无条件满足条件——正常路径上零等待。它约束的只是“不能进更低高度的分叉块”，而那种块本来也不该承载你的交易。也就是说，这个字段在这里不是日期，不是挂起的定时单，而是一句只朝未来生效的声明。真正的时间锁定要用不低于 LOCKTIME_THRESHOLD（五亿）的大数值或者带 OP_CHECKLOCKTIMEVERIFY 的脚本，那是另一套东西，与此处无关。
普通用户要知道的三件事
第一，看到自己或他人的交易里 nLockTime 写着一个非常接近当前链尖高度的整数，不必恐慌，它多半就是 Core 或行为相近的钱包的默认防狙击写法，不代表任何锁定意图。第二，这个保护是钱包侧的默认策略而不是全网强制的共识规则，手工构建交易、部分第三方钱包或交易所清结算系统可能不设它，链上两种形态都会长期共存。第三，如果你自己开发钱包或签名工具，可以按同样思路实现：非同步状态写零、同步状态写链尖高度、一成的概率往前退 0 到 99、输入序列号保持非最终值，这样既兼容现有网络习惯，也给未来的替代方案留了余地。顺带一提，针对 Taproot 支出还有一份编号 BIP326 的草案提出用 nSequence 承担同样的防狙击职责、给链下协议做掩护，该草案截至本文撰写仍是草案状态，未成为共识规则。
风险提示：本文只解释交易字段的协议机制，不构成任何投资建议；理解字段含义有助于核对交易，但不改变比特币转账一经确认即不可逆的事实。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。