隔离见证Segregated Witness业内简称 SegWit是比特币历史上最有分量的一次底层升级它不光是“让区块变大一点”那么简单。它牵涉到交易结构、签名机制、地址格式、手续费计算甚至闪电网络、脚本扩展全都是踩在它肩膀上长出来的。我接触这个领域的时间不算短见过很多人把隔离见证当成“扩容方案”一句话带过但其实它的设计精妙程度远超这个标签。这篇文章我会从一笔比特币交易到底长什么样开始逐步拆解为什么我们需要把“见证”隔离出去、隔离之后交易格式变成了什么。你不论是做钱包开发、跑节点维护还是只是想知道为什么bc1开头的地址更便宜这篇文章都可以当作一份完整的参考。1. 隔离见证是什么从一笔交易的结构说起1.1 旧交易结构里的“大头”是签名在隔离见证出现之前比特币交易的结构非常直白每个输入里除了声明要花掉哪个 UTXO还必须附带一段“解锁脚本”scriptSig里面放的是签名和公钥用来证明你有权花这笔钱。你可以把一个输入想象成一张银行卡卡号是 UTXO 引用密码是签名。没有密码谁也不能动卡里的钱。问题在于这个“密码”非常占地方。一个典型的 P2PKH 转账交易里一个输入大约 148 字节其中签名本身就要 70 到 72 字节。如果是多重签名签名数量成倍增长。中本聪最初设计时并没有刻意区分“交易本身的账本信息”和“证明所有权信息的签名”全都糅在同一个输入字段里。这就导致早期比特币交易体积膨胀得很快1MB 区块一旦遇上集中转账需求手续费就会飙到天上。绝大多数人第一次听说隔离见证是因为它可以省手续费、扩容。但我想说的是这更像是“顺手解决”的附属福利。隔离见证真正的动机在于交易展开的另一个维度——延展性攻击。1.2 延展性攻击签名成了交易的“瑕疵开关”在区块浏览器上我们会看到一个交易有两个 ID一个是txid另一个是hash在隔离见证后还区分了wtxid。老交易里的txid是对整个交易数据进行双 SHA256 运算的结果其中自然包含输入里的签名。而签名是非确定性的如果你拿同一笔交易广播在未确认前中间节点或第三方可以把交易里的签名稍微改几个字节比如给签名额外加一个填充字节的 DER 编码变体从而生成一个内容合法、但txid完全不同的新交易。这就像你把车钥匙交出去复印别人却用一把能开车但齿纹不同的“非官方钥匙”把车开走了。最终交易能成功账本上多出来的记录却不是原来的那一条。比特币的核心开发者们早就意识到这种延展性会让需要“在链上等确认后做后续动作”的协议变得脆弱。比如你要在两笔交易之间建立一个状态通道第一笔交易还没确认时如果它的 ID 被改写你构造的第二笔交易引用的条件就全部失效。隔离见证把签名从计算txid的范围内拿出来直接砍掉了这个“瑕疵开关”。1.3 什么是“见证”在比特币的语境里“见证”就是解锁脚本里那一堆证明材料签名、公钥、以及多签时的各类堆栈元素。你可以把它理解为“证明自己有权花费的那部分数据”。Segregation 的意思是“隔离”合起来就是把输入中的解锁脚本从交易的主体结构中剥离开放到交易末尾一个独立字段里。老交易输入里还保留一个“空脚本”占位真正的签名信息放到交易尾部一个叫witness的字段中。这样txid计算时使用的主体部分不再包含签名交易 ID 因此变得稳定。同时因为见证数据被单列我们可以单独为这部分设计不同的计费权重。隔离见证的名字之所以叫“见证隔离”原因就在这它隔离的不是资金而是“证明”。2. 隔离见证的技术原理拆解2.1 新交易格式标记、标志与见证字段隔离见证交易在原来的基础交易结构上新增了两个辅助字节外加一个可选的witness字段。普通交易的序列化结构是version (4字节) input_count (可变整数) inputs (...) output_count (可变整数) outputs (...) locktime (4字节)隔离见证交易变成version (4字节) marker (1字节固定是 0x00) flag (1字节固定是 0x01) input_count (可变整数) inputs (...) output_count (可变整数) outputs (...) witness (与input数量对应的见证数据) locktime (4字节)其中 marker 0x00 是老交易里input_count不可能出现的值不可能有 0 个输入所以老节点看到 0x00 会认为这是一笔非法交易向后兼容性由软分叉的额外规则保证。flag 0x01 表示这个交易带见证数据。如果 flag 为 0那么 witness 字段必须为空整个交易就退化为老格式。你可以把这次改造理解成在快递箱里给贵重物品专门加了一个防震层原有发票信息保持不动防震层单独放在角落里。老线工人只要看到特殊封条就知道要用新流程核验防震层没有经过培训的旧工人虽然不检查防震层但包裹规则仍兼容。对于 P2WPKH 交易它的输出脚本非常简单OP_0 20字节公钥哈希这是一段任何人都可以认作“非标准”但共识上允许的脚本。在老节点眼里它相当于把 0 压入栈再压入一段数据并不再执行任何校验。因此老节点也会认为这个输出有效而新节点则会额外检查隔离见证交易中的 witness 是否对该输出提供了合法签名。2.2 重量计算为什么隔离见证能“额外塞更多交易”隔离见证没有简单地把区块上限改成 4MB 字节而是引入了一个更聪明的计量单位区块重量Weight Units, WU。具体公式如下weight base_size * 3 total_size其中base_size不含见证数据的基础交易序列化字节数含 marker、flag但 witness 为空。total_size含 witness 数据的完整交易序列化字节数。因为total_size base_size witness_size所以上面的公式等价于weight 4 * base_size witness_size这样看就有意思了见证数据的每一字节在区块重量里只算 1 个 WU而基础数据的每一字节要算 4 个 WU。换句话说见证数据获得了 75% 的“折扣”。一个区块的重量上限被设置为 4,000,000 WU老交易没有见证字段witness_size 0于是weight 4 * total_size这意味着纯老交易最多仍只能填满 1,000,000 字节也就是我们熟悉的 1MB。但隔离见证交易因为相当一部分数据算在见证里总物理字节数可以超过 1MB最高理论上限约为 4MB。为什么采用这种不对称权重因为见证数据不需要全节点一直保存在 UTXO 集里它只在验证交易的那一刻被用到验证完就可以丢弃。对于节点长期运行的内存消耗来说见证数据比核心账本数据“更轻”。所以设计上给见证数据打四分之一价格经济上引导用户把签名这类非本质信息尽量放进见证字段相当于在不清除老节点规则的前提下让区块空间利用率变得更高。2.3 地址的进化三种形态并存隔离见证升级过程中产生了多种地址格式在今天的生态里你可能同时看到它们地址类型前缀技术基础适用场景P2PKH1老 P2PKH所有老钱包、交易所P2SH 嵌套 SegWit3P2SH-P2WPKH / P2SH-P2WSH兼容老钱包低层钱包过渡原生 SegWitbc1Bech32 P2WPKH / P2WSH新钱包手续费最低为什么会有3开头的隔离见证地址这是为了兼容那些不知道隔离见证规则的旧钱包。旧钱包不能识别bc1地址但完全遇到过3开头的 P2SH 地址。于是开发者想了一个“包装”办法输出脚本先按 P2SH 写成OP_HASH160 20字节脚本哈希 OP_EQUAL但提供的赎回脚本其实是OP_0 20字节公钥哈希老钱包收到这笔钱后花费时只需要提供赎回脚本并让栈里留下“非空”即可而新钱包则会在 P2SH 的 redeemScript 后面额外附加签名和公钥。这个过程完成了兼容过渡代价是交易体积比原生bc1稍大一点手续费折扣也少一些。如果你是自己管私钥尽量把资金都换到原生隔离见证地址能省下不少链上费用。3. 隔离见证的实际应用与操作指南3.1 手动构造一笔 P2WPKH 交易如果你对隔离见证只有抽象理解我建议你手动构造一笔 P2WPKH 交易试试。这个过程能让你彻底搞懂 base size 和 witness size 的区别。我们需要准备一个还没有被花费的 P2WPKH 输出UTXO假设它的锁定脚本是OP_0 00142f1f9e89f1d0f9d2cf9dcee71a9c1c3f26f8b0f5要花费这笔钱交易主体部分包含version: 01000000 marker: 00 flag: 01 input_count: 01 input: prev_txid: e7f... (32字节就是你引用的UTXO交易ID) prev_vout: 00000000 (4字节) scriptSig_length: 00 (空脚本) sequence: ffffffff (4字节) output_count: 01 output: value: 00e1f50500000000 (金额8字节小端) scriptPubKey_len: 16 (22字节) scriptPubKey: 0014 a11a... (对方的P2WPKH脚本) locktime: 00000000然后在 locktime 之前你需要插入 witness 数据。对于 P2WPKH见证字段包含两项签名长度约 71 字节和公钥33 字节。witness_count: 02 sig_length: 47 signature: ... (DER编码签名含 sighash) pubkey_length: 21 pubkey: ... (压缩公钥)注意这个 witness 列表紧跟 outputs 之后而不是在 locktime 之后。严格来说序列化顺序是marker、flag、inputs、outputs、witness、locktime。我一开始就搞错过顺序结果构造出的交易直接无法被节点接受。构造完成之后把 witness 字段参与hashPrevouts、hashSequence、hashOutputs、hashPreimage按 BIP143 的“新签名哈希算法”计算生成签名。BIP143 相比老方案最大的变化是不再把整个交易序列化后哈希而是分别对输入输出做部分哈希这样更高效也让签名时不需要知道其他输入是否已经签名。3.2 在钱包里切换隔离见证时的三个关键细节如果你在开发钱包支持原生隔离见证不只是改个地址生成字符串那么简单。有非常多的隐藏细节需要处理。第一个细节是找零地址。早期不少钱包把找零仍然发回1开头的 P2PKH 地址哪怕收款地址是bc1。这样会导致你明明用了隔离见证收款但转出时因为找零是旧格式手续费并没有省到位。正确做法是把找零地址也统一为与输入一致或优先生成原生隔离见证地址。第二个细节是签名哈希算法的切换。给 P2WPKH 输入签名时必须使用 BIP143 规定的算法即使某些输入没有 witness 也要遵循。如果算法不对签名在广播时会得到mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation)一类的错误。新手常犯的错误是把老的sigHash算法套到隔离见证交易上。第三个细节是“最大字节数”的估算。因为 witness 长度不像 scriptSig 那样被清晰限制在同一结构里某些钱包在构造超大交易时会低估交易体积导致超出节点策略的max_tx_weight限制默认 400,000 WU。比如说你一次性拼几百个输入的大额转账需要精确计算重量否则容易在广播前被自己的节点依赖拒绝。3.3 手续费省多少用实际数据算一笔账我们拿一笔普通的“一进一出”转账来做对比。假设这是一笔 P2PKH 转账输入大小148 字节输出大小34 字节找零也按 P2PKH 算加上其余部分总大小约 226 字节。按老方式计费无见证折扣重量 226 * 4 904 WU。如果同样是一进一出双方都为原生隔离见证地址基础部分不含 witness版本4字节 marker/flag 2字节 输入约41字节32字节txid 4字节vout 1字节scriptSig长度 空scriptSig 4字节sequence 输出约43字节8字节金额1字节长度22字节脚本 找零类似 locktime 4字节总计约10 41 43 43 4 141字节。见证部分一个输入带 1个签名(约72字节) 1个公钥(33字节) 若干长度字节 约107字节。总物理大小约 248 字节。重量 3 * 141 248 671 WU。按同样的费率比如 30 sat/WU老交易费用为 27,120 sat隔离见证交易费用为 20,130 sat。省了大约 25.8%。很多人说是省 30%实际数值因找零地址和输入类型而异。如果再考虑到隔离见证交易可以容纳更多交易到同一区块矿工为了收入最大化还会对低费率的隔离见证交易更友好一点。所以如果你还在给矿工多交那 25% 的“旧格式税”开始切换到原生隔离见证地址是当下最划算的链上优化。4. 隔离见证的常见误解与问题排查4.1 误解一隔离见证 扩容 4 倍这是最广泛的误解。隔离见证过后比特币区块的物理大小确实可以超过 1MB最高到约 4MB但并不是说所有区块都能无限制塞满 4MB。关键在于基础数据部分仍然受 1MB 字节等价权重的约束如果一笔交易完全没有见证数据那 4MB 的区块仍然只能装 100 万个字节。隔离见证更像是把区块中的“存储空间”划分为两个不同的计费池。账本信息池还是原来那么大证明信息池则是新增出来的。如果未来所有交易都变为全隔离见证格式那区块容量理论上还不到 2MB 左右因为纯隔离见证交易的 witness 占比通常在 35% 到 45%。所以把隔离见证形容为“让区块更有效地使用空间”比“扩容四倍”准确得多。4.2 误解二隔离见证解决了所有延展性问题隔离见证修复的是“交易 ID 可以被第三方改写”的问题因为txid不再对 witness 哈希。但是隔离见证并没有完全消除所有延展性形式。有一种叫“输出延展性”output malleability的问题依然存在如果有人先看到了你的交易他可以构造一笔几乎一样的交易改变输出的顺序或找零地址的编码方式只要交易语义一致同样能影响你之后基于输出位置索引的某些协议。另外隔离见证交易中的wtxid仍然是可以被矿工调整的。虽然这个 ID 不影响普通应用但在某些复杂的二层协议里依然要提醒参与者不能完全依赖wtxid不变。隔离见证解决的是“最常见、最容易利用的输入延展性”不是魔法棒。4.3 实操中遇到的兼容性问题清单我在给一些节点和钱包升级时遇到过下面这些典型问题可以直接对照排查现象可能原因解决建议钱包显示交易已发送但区块浏览器一直查不到txid广播的节点版本太老可能不认识 Bech32 地址或 witness 交易检查节点版本升级到支持 SegWit 的版本确认钱包真的是把完整交易广播到多个节点手写交易返回non-mandatory-script-verify-flag错误witness 字段格式不合法或顺序放错重新检查 marker、flag、witness 字段的位置确认所有 witness 都对应正确的输入无输入交易不能有 flag1bc1地址在某个老钱包里无法识别该钱包不支持 Bech32给这种钱包使用时换成3开头的嵌套隔离见证地址找零地址是1开头导致手续费没省多少钱包配置里找零地址类型未切换在钱包设置中改找零地址为原生隔离见证格式PSBT部分签名比特币交易里的 witness UTXO 信息缺失钱包在构造隔离见证输入时没有附带witness_utxo字段必须提供 witness UTXO 的金额和锁定期脚本才能推导签名哈希4.4 排查这类问题的通用思路如果一笔隔离见证交易广播后卡住不要第一时间怀疑网络应该按下面顺序检查确认交易所有输入对应的 UTXO 都还没被花费。确认每个输入都有witness_utxo信息金额与 scriptPubKey 完全匹配。使用 BIP143 签名哈希自行写一个小脚本验证签名是否正确而不是盲目相信钱包工具。把序列化后的交易 hex 复制到支持decoderawtransaction的节点工具中注视字段和 witness 字段的排列是否符合预期。如果签名格式没问题再检查手续费费率是否达到当前网络的最低要求。这些步骤能覆盖 90% 的隔离见证交易问题。剩下的 10% 大多是节点同步问题升级到最新版本基本都能解决。5. 隔离见证的后续生态与我的实际体会5.1 为什么说隔离见证是闪电网络的地基闪电网络的理论基础是“双方通过链上交易锁定资金链下交换承诺交易”。如果链上交易 ID 可以被轻易篡改那么一方的承诺交易就可能因为引用了“不存在的 txid”而失败。隔离见证让交易 ID 变成确定性结果也让每个参与者都能对同一笔交易生成互相不冲突的签名这为链下通道的建立、更新和关闭提供了安全前提。同时隔离见证带来的脚本限制解除使得 Schnorr 签名、Taproot 升级可以在此基础上设计地更优雅。比如 Taproot 用到了“key path spending”和“script path spending”的组合方案它能被顺利引入也正是因为 witness 字段可以灵活承载多种花费条件。你可以把隔离见证看成给比特币脚本开放了一扇新的窗户窗户本身并不决定窗外是什么风景但没有它新的协议根本没法落地。5.2 我在学习和实践隔离见证时最有价值的几个经验如果是刚开始了解这块我的建议是先动手造一笔假的本地交易而不是直接上主网。用 regtest 模式跑一个本地私链或者使用测试网络的 faucet把 P2WPKH 和 P2WSH 分别跑通观察它们的 base size 和 witness size。只有亲眼看到签名从 scriptSig 移到 witness你才会真正理解“隔离”的含义。另一个容易忽略的经验是升级节点前先备份好配置文件。曾经我在一个低版本钱包上直接导入bc1地址结果钱包提示无法同步交易历史搞得我以为私钥丢了。后来才发现只是旧版本的地址识别库还没有支持 Bech32并非资产丢失。如果你管理着很多地址落地切换前最好先在几个带少量资金的地址上做测试确认收发、找零、签名都没问题再批量迁移。我还喜欢用“区块容量演进”的视角去理解隔离见证它不是简单地把门改宽而是重新定义了“什么东西需要进门”。账本数据是必须存档的签名是验证完就可以丢的。让贵重物品占更多物理空间让一次性凭证打折存放是这个设计最核心的经济学直觉。如果你现在正为交易手续费发愁去生成一个bc1开头的新地址把钱包里租不出去的老地址资金整合转过去长期来看节省的币足够你操作很多次了。隔离见证不是一个“够用就好”的补丁它是比特币协议向前演进的重要分水岭理解它就是理解今天很多新技术的起点。