版本消息里的子版本字符串最长二百五十六字节：MAX_SUBVERSION_LENGTH 与 uacomment 的预算

比特币节点握手时发的 version 消息里，有一个人类可读的”子版本”字符串，形如 /Satoshi:31.0.0/——你在各种节点监控页看到的”客户端版本”就来自它。这个字符串有两条容易被忽略的纪律：自己这边拼太长的话节点直接拒绝启动；收到别人超长的话按协议处理。上限是一个写在源码里的数字：256 字节。而让字符串变长的常见原因，正是那个看起来无害的 -uacomment 参数。本文全部以 Bitcoin Core v31.0 源码为准。

字符串怎么拼出来的

子版本由 FormatSubVersion 组装：固定名字 Satoshi、编译期版本号、以及用户在 -uacomment 里附加的若干注释，用斜杠包起来串成 /Satoshi:版本/注释1/注释2/... 的形状。-uacomment 在 init.cpp 注册，允许出现多次，每次追加一段。为防止塞进乱七八糟的字符，源码对每一段做字符白名单过滤（SanitizeString 的 UA 注释字符集），带非法字符的直接报错拒启。所以拼出来的串长度是可控的：基础部分固定，你加多少注释就长多少。

256 的上限在两处生效

在 src/net.h 里，常量 MAX_SUBVERSION_LENGTH 定义为 256，注释写明是”version 消息里用户代理字符串的最大长度”。两处代码引用它。第一处在启动路径：init.cpp 组装完子版本后立即检查，一旦总长超过 256，直接 InitError 停机，报错原文的意思是”网络版本字符串总长度超限，请减少 uacomment 的数量或大小”——也就是说，节点不会带着一个超长身份出门，而是宁可不开。第二处在收包路径：net_processing.cpp 用 LIMITED_STRING(strSubVer, MAX_SUBVERSION_LENGTH) 读取对端子版本，把解析严格卡在 256 字节内，防止一个对端用无限长的字符串撑爆内存。

谁会真的撞上这条线

普通用户几乎永远碰不到：/Satoshi:31.0.0/ 才十几个字节，离 256 十万八千里。会逼近它的，是那些把部署信息塞进注释的运维——有人习惯用多个 uacomment 标机房、实例号、构建哈希，比如 /Satoshi:31.0.0/机房A/机架12/节点03/deploy-20260801-a1b2c3/...，每段都吃掉十几个字节，堆到十几段就会看到启动失败。这个报错的友好之处在于它直接告诉你解法：减少注释的数量或大小，而不是让你猜。

uacomment 的另一面：你愿意公开多少

值得多提醒一句：uacomment 不是私有备注，它是全网可见的广播字段，任何对端在握手时都能读到。有人用它做良性标识（矿池节点分组、软件发行版标签），但也有人无意中把内部命名规律（服务器编号、部署时间）广播给了全世界，等于给指纹识别送素材。在 Tor 或 I2P 后面跑节点、又在意可关联性的运维，常见做法恰恰是反向的：一个 uacomment 都不加，保持和其他节点 /Satoshi:31.0.0/ 完全一致的出厂长相。长度预算和隐私预算，其实是同一笔账的两面。

常见误区

一是把 256 当成 P2P 消息总长上限——那是另一个更大的协议级限制，256 只管子版本这一个字段。二是以为 uacomment 超了只是被截断：自己的节点是拒绝启动，不是悄悄剪短；截断只发生在读取对端数据的防御性解析里。三是以为字符串可以随便放中文或空格：白名单字符集之外一律拒启，写部署脚本前先在测试网实例试跑一次，是最省事的验证方式。

和握手字段划清边界

顺带把子版本放回复杂的上下文里：version 消息是一个固定结构的二进制包，里面有协议号、服务位、时间戳、创世块哈希、对端地址等一堆字段，256 字节只管其中那个可读字符串；对端协议号低于本节点可接受的最低版本会被断开，创世块哈希对不上链身份直接拒——这些失败与字符串长度无关，报错现场也完全不同。把日志里的断连原因逐字段归位，是区分”身份太花哨”与”链不同路”的第一步。

风险提示：本文为 P2P 握手字段机制科普，常量与字符规则以 Bitcoin Core 当前版本源码为准，可能随版本调整；不构成隐私水平承诺或投资建议。