比特币脚本与多签：P2WSH、P2TR 等输出类型在浏览器怎么认

摘要：比特币没有账户余额字段，每个输出都带一段 scriptPubKey。本文用 2026-10-07 主网真实交易，在 Blockstream Explorer 里逐个认出 P2PKH、P2SH、P2WPKH、P2WSH、P2TR 五种输出，拆解一笔 2-of-3 多签 P2WSH 花费的 witness 四项，并用 Esplora API 复算 SHA256(witnessScript) 与链上哈希核对，对照 BIP-141/147/341 原文。

比特币没有「账户余额」字段，每一笔输出（UTXO）都自带一段锁定脚本 scriptPubKey，规定「谁、拿什么」才能花它。我们平时看到的 1 开头、3 开头、bc1q、bc1p 地址，其实就是不同脚本类型的编码。它和以太坊多签最容易混：以太坊多签（如 Safe）是一个智能合约账户，而比特币多签只是一段脚本，钱还是一个个 UTXO。本文只讲怎么在区块浏览器里认出 P2PKH、P2SH、P2WPKH、P2WSH、P2TR 五种输出，以及一笔 2-of-3 多签 P2WSH 花费时 witness 里每一项是什么，并用公开 API 自己核对一遍。

文中的交易都是 2026-10-07 比特币主网第 970,281 块里的真实交易，浏览器用 Blockstream Explorer（blockstream.info，界面为英文）。本来也想用 mempool.space 对照，但截图环境里该站连接被重置，打不开，所以统一用 Blockstream 及其开源后端 Esplora 的 API；你在本地用 mempool.space 查同一笔 txid，字段含义一致。全程只读，不需要钱包和私钥。

一、先看规范：标准脚本有哪几类
二、在浏览器里认输出类型：一笔交易里五种全有
三、P2WSH 为什么用 32 字节：看 BIP-141 原文
四、真实 2-of-3 多签花费：witness 逐项拆开
五、用 API 自己核对：SHA256(witnessScript) = scriptPubKey 里的哈希
常见误读
想自己动手的话
相关阅读

一、先看规范：标准脚本有哪几类

Bitcoin 开发者文档 Transactions · Standard Transactions 解释了为什么有「标准交易」：节点默认只转发符合少数几种安全模板的脚本（IsStandard() 检查）。文档列出的传统标准类型包括 P2PKH、P2SH、裸 Multisig、Pubkey 和 Null Data（OP_RETURN），隔离见证（BIP-141）和 Taproot（BIP-341）之后又加入了 P2WPKH、P2WSH 和 P2TR。

比特币脚本与多签：P2WSH、P2TR 等输出类型在浏览器怎么认-程序旅途 — 图1：developer.bitcoin.org「Standard Transactions」：标准公钥脚本类型列表，以及 P2PKH 的 Pubkey script：OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG、Signature script：<sig> <pubkey>；界面为英文

五种常见输出的对照如下（字节数是 scriptPubKey 长度，可以在下文终端输出里逐个核对）：

类型	地址长相	scriptPubKey 模板	解锁数据放哪
P2PKH	1 开头（Base58）	`OP_DUP OP_HASH160 <20B> OP_EQUALVERIFY OP_CHECKSIG`，25 字节	scriptSig：签名 + 公钥
P2SH（BIP-16）	3 开头（Base58）	`OP_HASH160 <20B> OP_EQUAL`，23 字节	scriptSig：解锁数据 + redeemScript
P2WPKH	bc1q，42 个字符（bech32）	`OP_0 <20B>`，22 字节	witness：签名 + 公钥
P2WSH	bc1q，62 个字符（bech32）	`OP_0 <32B>`，34 字节	witness：解锁数据 + witnessScript
P2TR（BIP-341）	bc1p，62 个字符（bech32m，BIP-350）	`OP_1 <32B>`，34 字节	witness：密钥路径 1 个签名；脚本路径为参数 + 脚本 + control block

记住一个规律：地址前缀只告诉你脚本「类型」，不告诉你脚本「内容」。P2SH、P2WSH 输出上链时只露出一个哈希，背后是单签、多签还是时间锁，要等它被花费、把脚本公开出来时才看得到。

二、在浏览器里认输出类型：一笔交易里五种全有

打开交易 f64b4c16…54bd0，点右上「Details +」展开。这是一笔 1 输入 7 输出的批量付款，正好覆盖了全部五种类型。每个输出卡片里看三行：TYPE、SCRIPTPUBKEY (ASM)、SCRIPTPUBKEY (HEX)。

先看 HEX 开头两字节：0014 = 版本 0 + 推 20 字节（P2WPKH）；0020 = 版本 0 + 推 32 字节（P2WSH）；5120 = OP_1 + 推 32 字节（P2TR）；76a914…88ac 是 P2PKH；a914…87 是 P2SH。
再对地址：同是 bc1q，P2WPKH 地址明显短（42 字符），P2WSH 长（62 字符）；P2TR 是 bc1p。
别被「金额大」迷惑：输出 #0 是一个 P2WSH，金额较大但还没被花费，链上只能看到 32 字节哈希，看不出它是不是多签。

三、P2WSH 为什么用 32 字节：看 BIP-141 原文

BIP-141 的 P2WSH 一节用一个 1-of-2 多签举例，把 witness、scriptSig、scriptPubKey 三者的关系写得很清楚：

scriptSig 为空：原生隔离见证输入的解锁数据全部移到 witness，交易 ID（txid）不再受签名数据影响。
witness 最后一项是 witnessScript：节点把它取出做一次 SHA256，和 scriptPubKey 里的 32 字节比对，一致才执行。注意这和 P2SH 的 HASH160（SHA256 后再 RIPEMD160，20 字节）不同。
为什么多 11 字节：文档说明 P2WSH 的 scriptPubKey 是 34 字节，BIP-16 P2SH 是 23 字节；改用 32 字节哈希是为了提高抗碰撞安全性。文档还写明 P2WSH 绕过了 520 字节的单次推送限制，脚本最大可到 10,000 字节。

四、真实 2-of-3 多签花费：witness 逐项拆开

再看交易 8a40414c…daf69。它只有 1 个输入，花的是一个 P2WSH 多签地址，输出一笔给 P2TR 地址，另一笔找零回到同一个多签地址（所以 Blockstream 在摘要里标了「Address reuse」）。

witness 一共 4 项，按顺序读：

第 1 项：<empty>（0 字节）
OP_CHECKMULTISIG 有个历史遗留的「多弹出一个元素」问题，所以必须垫一个占位项。软分叉 BIP-147（NULLDUMMY）进一步规定这个占位必须为空，否则交易无效。看到多签 witness 第一项是空的，是正常现象。

第 2、3 项：两个签名（各 72 字节）
以 30 45… 开头的是 DER 编码的 ECDSA 签名，末尾 1 字节是 sighash 类型，所以长度通常在 71～73 字节之间浮动。签名的顺序必须和脚本里公钥的顺序一致。

第 4 项：witnessScript（105 字节）
十六进制以 52（OP_2）开头、53 ae（OP_3 OP_CHECKMULTISIG）结尾，中间是 3 个 21（推 33 字节）+ 压缩公钥。读出来就是「3 把公钥里任意 2 把签名即可」，即 2-of-3。长度 1 + 3×34 + 1 + 1 = 105 字节，能和浏览器显示对上。

顺带看摘要区的费用：这笔交易 393 字节、权重 804 WU、虚拟大小 201 vB，手续费 1,500 sat，约 7.46 sat/vB。witness 数据按 1/4 计入权重，所以多签放进 witness 比放在 P2SH 的 scriptSig 里更省（Blockstream 摘要里给出了它自己的估算比例）。费率是这一笔的成交结果，不代表当前行情，实时费率要以内存池为准。

五、用 API 自己核对：SHA256(witnessScript) = scriptPubKey 里的哈希

浏览器的「TYPE」是它替你解析的。想自己验证，直接请求 Blockstream 的公开 Esplora API。下面四条命令是本机真实执行的（只读）：

B=https://blockstream.info/api

# 1) 一笔交易里每个输出的类型、scriptPubKey 字节数、地址
curl -s $B/tx/f64b4c16dc56048506900029576b338352bcd3c098296c978390fa39ed854bd0 \
  | jq -r '.vout[] | [.scriptpubkey_type, (.scriptpubkey|length/2), .scriptpubkey_address] | @tsv'

# 2) 多签输入：被花费输出的 scriptPubKey 与 witness 每项字节数
curl -s $B/tx/8a40414c7847da0eedb3af905b18a5b7eb18eac9b8bd137053a1cd20722daf69 \
  | jq '.vin[0] | {prev_type: .prevout.scriptpubkey_type, prev_scriptpubkey: .prevout.scriptpubkey, witness_bytes: (.witness | map(length/2))}'

# 3) 对 witness 第 4 项（witnessScript）做 SHA256
curl -s $B/tx/8a40414c7847da0eedb3af905b18a5b7eb18eac9b8bd137053a1cd20722daf69 | jq -r '.vin[0].witness[3]' \
  | python3 -c 'import sys,hashlib; print(hashlib.sha256(bytes.fromhex(sys.stdin.read().strip())).hexdigest())'

# 4) 对照：一笔 P2TR 密钥路径花费的 witness
curl -s $B/tx/11a054c5d883e5ff06c2d7d8f6d0fac37e4ea80d76d1c5ffcbf9ff5238006251 \
  | jq '.vin[0] | {prev_type: .prevout.scriptpubkey_type, prev_address: .prevout.scriptpubkey_address, witness_bytes: (.witness | map(length/2))}'

从输出能核对出四件事：

字节数和模板一一对应：25 / 23 / 22 / 34 / 34，和第一节的表一致；P2WSH 与 P2TR 都是 34 字节，要靠第一个字节（00 还是 51）区分版本。
P2WSH 的哈希能自己复算：第 3 条命令算出的 a18a1f…f7e8 就是第 2 条 prev_scriptpubkey 里 0020 后面的 32 字节。这正是 BIP-141 规定节点要做的那一步校验。
多签的成本看得见：0 + 72 + 72 + 105 字节的 witness，比单签 P2WPKH（约 72 + 33 字节）大一截，这就是多签手续费更高的原因。
Taproot 密钥路径只有一个 64 字节签名：按 BIP-341，witness 栈只有 1 项时走密钥路径，这一项是 Schnorr 签名（默认 sighash 时 64 字节，否则 65 字节）。外人从链上看不出这把输出公钥背后是一个人的密钥，还是多方聚合出来的密钥。

常见误读

「bc1q 都一样」：42 字符的是 P2WPKH 单签，62 字符的是 P2WSH，背后可能是多签或其他脚本。
「3 开头就是多签」：P2SH 只说明「付给一个脚本哈希」，很多钱包用 3 开头地址做嵌套隔离见证（P2SH-P2WPKH）单签。花费之前判断不了。
「多签 witness 第一项为空是数据丢了」：那是 CHECKMULTISIG 的占位项，BIP-147 要求必须为空。
「P2WSH 用 HASH160」：P2WSH 用单次 SHA256（32 字节），P2SH 才是 HASH160（20 字节）。自己复算时用错哈希会对不上。
拿以太坊思路找「合约地址」：比特币多签没有合约，规则就在 witnessScript 里，钱在一个个 UTXO 上（UTXO 怎么读见比特币 UTXO 模型）。

想自己动手的话

只读查询不需要钱包。想实际收发 BTC，可以用支持比特币的自托管钱包，例如欧易 Web3 钱包（创建时可填推荐码 CHENGXULVTU），收款前先看清钱包给你的是哪种地址。少量 BTC 可以在币安或欧易买入后提到钱包，提币网络选 Bitcoin，并确认平台支持你的地址类型（以提币页提示为准），第一次先小额试。