深入浅出比特币脚本：P2PKH、P2WPKH 与 P2SH 的核心差异

深入浅出比特币脚本：P2PKH、P2WPKH与P2SH的核心差异

前置约定

为确保后续示例的一致性和准确性，先明确以下核心数据（均符合比特币系统的标准格式）：

• 公钥P：0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483
  这是一个33字节的压缩公钥，由椭圆曲线加密算法生成，是比特币地址的核心源头数据。

• 公钥哈希H：0x7c8e10322a2e321ca9d3ff48e5897023055aa39b6
  由公钥P经两步哈希计算得到：先对P执行SHA-256哈希，再对结果执行RIPEMD-160哈希，最终得到20字节的哈希值（比特币地址的生成基础）。

• 签名Sig：3045022100...（省略部分字节）
  这是用与公钥P对应的私钥对交易数据签名的结果，共64字节，符合ECDSA（椭圆曲线数字签名算法）的格式规范，用于证明“资金所有者同意花费这笔UTXO”。

一、比特币脚本：定义资金归属的“数字契约”

比特币的脚本系统是一套基于栈的简单编程语言，它的核心作用是给UTXO（未花费交易输出）设定“解锁规则”。每一笔转账都会生成新的UTXO，其“锁定脚本”（ScriptPubKey）就像一份“数字契约”，规定了“谁能花这笔钱”；而当用户要花费这笔UTXO时，必须提供“解锁脚本”（ScriptSig）或“见证数据”（Witness），满足契约条件才能通过验证。

举个通俗的例子：

• 锁定脚本 = 银行保险柜的开锁条件（比如“必须输入张三的指纹+6位密码”）；
• 解锁脚本 = 张三提供的指纹和密码；
• 验证过程 = 银行系统检查指纹和密码是否符合预设条件。

P2PKH、P2WPKH、P2SH正是三种最具代表性的“数字契约”，分别对应不同的使用场景和技术需求。

二、P2PKH：最经典的单签脚本，却藏着“交易延展性”隐患

P2PKH（Pay-to-PubKey-Hash，支付到公钥哈希）是比特币最早普及的脚本类型，设计初衷是通过“公钥哈希”简化地址格式并隐藏原始公钥，但其底层设计存在一个关键缺陷——交易延展性。

1. 地址生成：从公钥到“1开头”的Base58地址

基于前置约定的公钥P，P2PKH地址的生成步骤如下：

1. 计算公钥哈希H：如前置约定所示，H是P经SHA-256→RIPEMD-160后的20字节结果；
2. 添加标识与校验：在H前添加1字节的主网标识0x00（P2PKH专属），后添加4字节校验码（对0x00+H执行两次SHA-256，取前4字节），形成25字节的原始数据；
3. Base58编码：将25字节数据转换为Base58格式，最终得到地址：1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa（以“1”开头，长度约34字符）。

2. 锁定脚本：用“公钥哈希+签名”锁定资金

当A向P2PKH地址转账时，区块链会记录该UTXO的锁定脚本，定义“只有持有对应公钥和签名的人才能花费”：

OP_DUP OP_HASH160 <H> OP_EQUALVERIFY OP_CHECKSIG

对应的十六进制字节码（可直接被比特币节点解析）：
76 a9 14 7c8e10322a2e321ca9d3ff48e5897023055aa39b6 88 ac

各部分含义拆解：

• 76（OP_DUP）：复制栈顶元素（后续用于公钥哈希计算）；
• a9（OP_HASH160）：对栈顶数据执行Hash160（SHA-256+RIPEMD-160）；
• 14：标记后续数据长度为20字节（即公钥哈希H）；
• 88（OP_EQUALVERIFY）：校验两个哈希是否相等，不等则交易直接失败；
• ac（OP_CHECKSIG）：用公钥验证签名的有效性。

3. 解锁流程：用“签名+公钥”证明所有权

当地址持有者要花费这笔UTXO时，需提供包含签名（Sig）和公钥（P）的“解锁脚本”，与锁定脚本拼接后由比特币节点执行验证。整个过程的“栈操作”如下（栈顶在上，栈底在下）：

步骤	执行操作	栈状态变化	逻辑说明
1	压入解锁脚本	[Sig, P]	先将签名和公钥放入栈中
2	执行OP_DUP	[Sig, P, P]	复制公钥P（后续用于计算哈希）
3	执行OP_HASH160	[Sig, P, H']	对复制的P计算Hash160，得到H'
4	压入锁定脚本中的H	[Sig, P, H', H]	将锁定脚本中存储的H压入栈中
5	执行OP_EQUALVERIFY	[Sig, P]	对比H'和H，若不等则交易失败；若相等则继续
6	执行OP_CHECKSIG	[true]	用公钥P验证签名Sig，有效则返回true，交易通过

4. 关键缺陷：为什么签名被修改会导致TXID变化？

P2PKH存在“交易延展性”问题，核心原因与TXID的计算方式和签名的可修改性直接相关：

• TXID是什么？：TXID（交易ID）是对整个交易数据（包括输入、输出、脚本等所有字段）执行两次SHA-256哈希后得到的32字节值，用于唯一标识一笔交易。
• 签名（Sig）的位置：在P2PKH中，签名Sig存储在输入的“解锁脚本（ScriptSig）”中，而ScriptSig是交易数据的一部分，直接参与TXID的计算。
• 签名的可修改性：ECDSA签名由(r, s)两个参数组成，其中s满足s' = N - s（N是椭圆曲线的阶，比特币中N=0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141）。修改后的s'与原s对应的签名同样有效（均可通过公钥验证），但字节形式完全不同。

连锁反应：
当s被修改为s'后，签名Sig的字节形式改变→导致ScriptSig的字节数据改变→整个交易数据改变→TXID（基于交易数据计算）也随之改变。最终结果是：同一笔交易出现两个不同的TXID，但两者都能被区块链认可。

这会带来实际风险：例如交易所收到用户的转账后，若TXID被修改，可能导致系统无法识别“已确认的交易”，引发对账混乱或资产损失。

三、P2WPKH：隔离见证带来的“优化版”单签脚本

P2WPKH（Pay-to-Witness-PubKey-Hash，支付到见证公钥哈希）是2017年“隔离见证（SegWit）”升级后推出的脚本类型，专为解决P2PKH的交易延展性问题而设计，目前已成为比特币网络的主流脚本。

1. 地址生成：Bech32编码的“bc1开头”地址

基于前置约定的公钥哈希H，P2WPKH地址的生成步骤如下：

1. 转换5位组：将8位字节的H转换为5位一组的数据（Bech32编码要求），得到32个5位元素（32×5=160位，恰好对应20字节的H）；
2. Bech32编码：添加前缀bc（比特币主网标识）和校验码，生成地址：bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq（以“bc1”开头，长度约42字符，自带错误校验功能）。

2. 锁定脚本：简化的“隔离见证”标识

P2WPKH的锁定脚本大幅简化，仅用于标记“这是一个隔离见证单签地址”：

OP_0 <H>

对应的十六进制字节码：
00 14 7c8e10322a2e321ca9d3ff48e5897023055aa39b6

各部分含义：

• 00（OP_0）：隔离见证单签的专用标识；
• 14：标记后续20字节为“见证公钥哈希”（即H）。

3. 解锁流程：见证数据与交易数据分离

P2WPKH的核心优化是将“签名和公钥”从传统的ScriptSig移到独立的“见证区域（Witness）”，验证流程如下：

步骤	执行操作	逻辑说明
1	验证锁定脚本类型	检查锁定脚本是否为OP_0 + 20字节，确认是P2WPKH类型
2	读取见证数据	从见证区获取[Sig, P]（无需复杂脚本，直接存储原始数据）
3	校验公钥哈希	计算P的Hash160得到H'，对比H'与锁定脚本中的H，必须相等
4	验证签名	用公钥P验证签名Sig的有效性，有效则交易通过

4. 核心优势：解决交易延展性+降低手续费

• 彻底解决交易延展性：见证数据（含Sig）不参与TXID的计算（TXID基于不含见证的交易数据生成），即使修改Sig的s值，TXID也不会变化；
• 降低手续费：见证数据不计入区块的“容量限制”（按权重折扣计算），同等金额下手续费比P2PKH低30%~50%；
• 地址更可靠：Bech32编码自带校验机制，输入错误（如字符混淆、长度错误）可被即时识别，减少转账失误。

四、P2SH：支持复杂逻辑的“万能脚本”

P2SH（Pay-to-Script-Hash，支付到脚本哈希）专为复杂场景设计，例如多签（需要多人共同签名）、时间锁（指定时间后才能花费）等。它的核心思路是“通过脚本的哈希锁定资金”，大幅简化复杂规则的地址格式。

1. 场景举例：2-of-3多签（3人中2人签名即可花费）

假设一个团队有3个管理员，约定“需2人签名才能动用资金”，首先需要定义“赎回脚本（Redeem Script）”——即具体的花费规则：

OP_2 <公钥A> <公钥B> <公钥C> OP_3 OP_CHECKMULTISIG

简化后的十六进制字节码：
52 2102A... 2102B... 2102C... 53 ae

各部分含义：

• 52（OP_2）：表示需要2个有效签名；
• 2102A...：3个管理员的公钥（每个33字节，前缀21标记长度）；
• 53（OP_3）：表示总共有3个公钥；
• ae（OP_CHECKMULTISIG）：比特币系统的多签验证指令。

2. 地址生成：从“赎回脚本哈希”到“3开头”的地址

基于上述赎回脚本，P2SH地址的生成步骤如下：

1. 计算脚本哈希S：对赎回脚本执行SHA-256→RIPEMD-160，得到20字节哈希：
   S = 0x3e934e242553b4506216912c5a32c9b951a55175c；
2. 添加标识与校验：在S前添加1字节的主网标识0x05（P2SH专属），后添加4字节校验码，形成25字节原始数据；
3. Base58编码：转换为Base58格式，得到地址：3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy（以“3”开头，长度约34字符）。

3. 锁定脚本：锁定到“脚本哈希S”

向P2SH地址转账时，锁定脚本仅验证“赎回脚本的哈希是否匹配S”：

OP_HASH160 <S> OP_EQUAL

对应的十六进制字节码：
a9 14 3e934e242553b4506216912c5a32c9b951a55175c 87

• a9（OP_HASH160）：对输入的赎回脚本计算Hash160；
• 87（OP_EQUAL）：对比计算结果与锁定脚本中的S是否相等。

4. 解锁流程：两步验证，先验哈希再验规则

花费P2SH的UTXO需要两步验证：先确认赎回脚本的哈希正确，再执行赎回脚本的逻辑：

步骤	执行操作	栈状态变化	逻辑说明
1	压入解锁脚本	[SigA, SigB, 赎回脚本]	提供2个签名和原始赎回脚本
2	执行OP_HASH160	[SigA, SigB, S']	对赎回脚本计算Hash160，得到S'
3	压入锁定脚本中的S	[SigA, SigB, S', S]	将锁定脚本中存储的S压入栈中
4	执行OP_EQUAL	[SigA, SigB, true]	对比S'和S，若不等则失败；若相等则继续
5	执行赎回脚本	[true]	验证SigA、SigB是否匹配2个公钥，有效则返回true

5. 核心价值：让复杂规则变得“简单易用”

• 支持复杂逻辑：除多签外，还可实现时间锁（OP_CHECKLOCKTIMEVERIFY）、条件支付（如“满足A或B条件即可花费”）等功能；
• 地址简洁：无论赎回脚本多复杂（甚至数百字节），地址始终是34字符，方便存储和传输；
• 隐藏规则细节：发送方无需知道接收方的复杂规则（只需地址），降低使用门槛。

五、三者核心差异对比表

维度	P2PKH	P2WPKH	P2SH
地址格式	Base58，以1开头	Bech32，以bc1开头	Base58，以3开头
锁定对象	公钥哈希（H）	见证公钥哈希（H）	赎回脚本哈希（S）
解锁数据位置	传统ScriptSig中	独立Witness区域	传统ScriptSig中
核心功能	基础单签	优化版单签（低手续费）	复杂逻辑（多签、时间锁等）
交易延展性	存在（Sig修改导致TXID变化）	解决（Sig不影响TXID）	存在（同P2PKH）
典型使用场景	旧系统、兼容性需求高的场景	主流个人钱包、交易所	团队账户、冷钱包、合约场景

六、现状与选择：为什么P2WPKH成了主流？

从比特币网络的UTXO分布来看：

• P2WPKH占比超过60%，凭借低手续费、无交易延展性问题等优势，成为个人用户和交易所的首选；
• P2PKH占比约20%，主要存在于旧钱包和硬件设备中，使用比例持续下降；
• P2SH占比约15%，在多签等复杂场景中不可替代，其隔离见证版本（P2WSH）也在快速普及（结合了P2SH的灵活性和P2WPKH的性能优势）。

普通用户选择P2WPKH地址（bc1开头）是性价比最高的方案；团队或企业管理资金时，P2SH/P2WSH的多签功能更能保障资产安全。

结语

P2PKH、P2WPKH、P2SH的演进，本质是比特币在“功能需求”与“技术优化”之间的持续平衡。从最初的简单单签，到支持复杂逻辑，再到隔离见证的效率提升，每一种脚本都对应着特定的技术痛点和场景需求。理解它们的差异，不仅能帮助我们更合理地选择地址类型，更能深入体会区块链“用代码定义规则”的底层哲学。