交易的第一行数字
每笔比特币交易的序列化开头就是一个四字节版本字段（代码里叫 nVersion）。它排在输入输出列表之前，签名的时候也被一并签进去。版本为 1 的交易是绝对时间锁的常规交易；版本 2 起，输入的序列号字段被赋予相对时间锁语义；版本 3 收紧了替代拓扑：一笔父交易最多允许一个未确认的子交易，且子交易不得携带新的未确认输入。同一个字段，三个版本讲了三套规矩。
但版本字段更日常的作用是当一道闸门：节点的中继政策明确写着，版本高于当前标准上限或低于标准下限的交易，直接以 version 为由拒转。截至 2026 年 9 月初核验的比特币核心源码，标准窗口是版本 1 到 3。也就是说，哪怕未来协议定义了版本 4 交易，在它被网络普遍接纳之前，你的节点会安静地把它判为不标准交易。
标准性不等于共识
这里要划一条关键的分界线。共识规则（决定区块能否被接受的规则）与标准性政策（节点愿意中继什么交易的自选规矩）在比特币里是两层楼。交易版本字段长期属于标准性这一层：一个版本 99 的交易如果脚本合法、签名正确，理论上可以被打包——矿工节点有权接受任何共识上有效的交易——但默认配置的公共节点不会帮它转发。版本 4 交易诞生的那一天，网络看到的不是“协议突然多了一种交易”，而是“有一小撮实验节点开始转发新东西”。
两步放行的传统
核心源码在定义版本常量的位置留了一段很务实的注释：改变默认交易版本要走两步——先提高中继政策里的版本上限，之后才在钱包和 RPC 层放开生成新版本交易的入口。这个顺序反过来说明了部署哲学：先让网络学会认，再让钱包学会造。回看版本 3 的节奏：政策层早于钱包层放行，钱包默认造 v3 要再晚一些。这样即使新特性设计有缺陷，受影响面也被压在最小组合里。
版本字段的历史包袱
版本字段早年吃过亏。最早的客户端把版本检查写成“小于等于某个数”，每当需要放行新版本就要改代码，等于强制所有人升级。后来规则改成“任何非零版本”共识上都有效，版本演进的压力被推到标准性层，闸门越做越轻。如今读一个区块，版本字段基本只说明两件事：相对时间锁语义按哪版解释、替代规则按哪版执行。
对普通用户的意义
日常钱包生成的交易永远落在版本 1 到 3 这个安全带里，你不需要关心它。唯一可能被版本字段硌到的场景是试验新特性的开发者工具：自造版本超窗的交易会在广播第一步就被邻居拒转，报错指向 version。此时的正确动作不是换节点碰运气，而是理解自己站在部署时间线的哪一格——公共网络还没准备好，等政策窗口打开。
谁需要读这个字段
对普通用户，版本字段只在一件事上有用：理解为什么自造实验交易会被公共网络安静拒绝。对开发者，它是路线图上的路标——新交易格式的定义流程里，第一步永远是提交标准性窗口的调整提案，第二步才是钱包接入。窗口宽度本身就是一份公开的时间表，读源码常量就能知道当前政策放到哪一格，不必猜测网络“应该”支持什么。
快速问答
问：版本越高的交易越优先吗？ 答：不是。矿工和节点的中继队列按费率与政策筛交易，版本只决定“能不能进这个门”，不决定排序。
问：版本字段会被矿工改吗？ 答：不会也不应。它参与交易哈希计算，任何改动都会破坏签名并改变交易身份。
风险提示
本文描述节点公开机制，不构成投资或开发建议。版本常量与政策窗口以当期源码与文档为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。