1. 基础概念铺垫
在深入理解各类数字货币钱包地址之前，掌握必要的底层基础知识至关重要。这主要包括非对称加密中的公私钥机制、哈希算法的应用、常见的数据编码方式，以及地址生成的核心原理。比特币钱包地址的设计严格遵循BIP（比特币改进提案）协议，而大多数非比特币系的数字钱包也沿用或借鉴了这些BIP相关标准。因此，在梳理比特币地址知识时，我们将适当穿插介绍其他类型钱包地址的相关特性。
1.1. 非对称加密与公私钥机制
非对称加密构成了现代密码学的基石，这一概念由惠特菲尔德·迪菲（Whitfield Diffie）和马丁·赫尔曼（Martin Hellman）于1976年首次提出。其核心特征在于使用一对数学上紧密关联的密钥：一个是公开的公钥，另一个是必须严格保密的私钥。这种机制解决了传统对称加密中密钥分发的难题，实现了无需预先共享秘密即可进行安全通信的目标。具体而言，用公钥加密的数据只能由对应的私钥解密；反之，用私钥签名的信息，则可通过对应的公钥来验证其真实性。
在当前数字货币领域，椭圆曲线数字签名算法（ECDSA）是最广泛使用的非对称加密方案，特别是比特币采用的 secp 256 k 1 曲线，相较于传统的RSA算法，它在同等安全强度下拥有更短的密钥长度和更高的运算效率。随着比特币 Taproot 技术的引入，加密货币领域开始采用 Schnorr 数字签名算法，相较于 ECDSA，Schnorr 具备更多的技术优势。
公钥与私钥的算法原理及其在数字货币中的作用如下：
在数字货币体系中，私钥是一个随机生成的巨大数值，它是控制资产的唯一凭证。公钥则是通过单向的椭圆曲线乘法运算从私钥推导而来（即从私钥推导公钥极易，但从公钥反推私钥几乎不可能）。而钱包地址通常是由公钥经过哈希运算后得到的结果。
二者的具体分工如下：
- 私钥：用于生成交易签名，以此证明用户拥有花费相应资金的权限。私钥必须绝对保密。
- 公钥：用于验证交易签名的有效性，确保签名确实源自对应的私钥。同时，公钥还用于生成公开的收款地址，该地址可以安全地分享给任何人。
简而言之，私钥负责“签名”，公钥负责“验证”和“生成地址”，二者结合共同确保了资产所有权转移的安全性与可靠性。
在比特币体系中，公钥分为两种形式：未压缩公钥（uncompressed）和压缩公钥（compressed）。未压缩公钥以字节 04 开头，长度为65字节；压缩公钥则以 02（表示偶数Y坐标）或 03（表示奇数Y坐标）开头，长度为33字节。
示例如下：
- public key (uncompressed): 04 b 4632 d 08485 ff 1 df 2 db 55 b 9 dafd 23347 d 1 c 47 a 457072 a 1 e 87 be 26896549 a 87378 ec 38 ff 91 d 43 e 8 c 2092 ebda 601780485263 da 089465619 e 0358 a 5 c 1 be 7 ac 91 f 4
- public key (compressed):02 b 4632 d 08485 ff 1 df 2 db 55 b 9 dafd 23347 d 1 c 47 a 457072 a 1 e 87 be 26896549 a 8737
传统未压缩公钥的结构示意图：
压缩公钥的结构示意图：
在与数字货币相关的公私钥知识中，还有一个常见术语 WIF（Wallet Import Format），即钱包导入格式的私钥，其编码结构示意图如下：
具体数据样例如下：
1.2. 比特币常用的哈希算法
除了公私钥知识，了解哈希算法（也称散列算法）也是必不可少的环节。
单向哈希函数具有一个输入和一个输出，输入称为消息（message），输出称为哈希值（hash value）。该函数根据消息内容计算出固定的哈希值，常用于检查消息的完整性。无论输入信息的长度如何，哈希函数都能将其映射为定长的输出值。
1. 常用算法介绍：SHA-256 与 RIPEMD-160
SHA-256 全称为安全哈希算法256位，它能接收任意大小的输入数据，通过复杂的数学计算生成一个固定长度（256位，即32字节）且看似随机乱码的字符串。该字符串通常以64个十六进制数字（0-9, A-F）表示。
例如，对 "hello world" 进行 SHA-256 计算后得到：
b 94 d 27 b 9934 d 3 e 08 a 52 e 52 d 7 da 7 dabfac 484 efe 37 a 5380 ee 9088 f 7 ace 2 efcde 9
RIPEMD-160 全称为 RACE 原始完整性校验消息摘要-160位，它是一种专门生成较短数字指纹的生成器。与 SHA-256 类似，它也是一个单向哈希函数，接收输入并产生固定长度（160位，即20字节）的输出，通常用40个十六进制数字表示。
例如，对 "hello world" 进行 RIPEMD-160 计算后得到：
d 7 d 56920283 f 17 ab 4 d 7 e 10 d 4 a 5 d 6 df 50 e 594 a 9 c 3
2. 比特币中常见的哈希组合
HASH 256 （双 SHA-256，最常用）
HASH 160 （SHA-256 + RIPEMD-160）
SHA-256 （单 SHA-256）
HMAC-SHA 512（基于 SHA-512 的消息认证码）
3. 应用场景
（1）比特币挖矿使用的是 HASH 256，即区块头中的哈希值是通过双 SHA-256 计算得出的。
（2）交易标识-TXID 使用的是 HASH 256。
（3）交易中的 merkle root 使用的是 HASH 256。
（4）公钥哈希使用的是 HASH 160，即执行一次 SHA-256 后再执行一次 RIPEMD-160。
（5）扩展密钥使用的是 HMAC（SHA-512）。
（6）签名交易过程中涉及 HASH 256。
1.3. 常见编码知识：Base64、Base58、Bech32
在比特币钱包地址的处理中，需要理解几种关键的编码方式，分别是 Base64、Base58 和 Bech32。
1. Base64 编码（虽未在比特币核心中使用，但作为早期常见编码在此介绍）
设计目标：旨在仅支持文本的媒介（如电子邮件、HTML、XML）中安全、可靠地传输二进制数据，防止数据因某些字符具有特殊含义（如换行符）而在传输过程中被修改。
原理：
- 将每3个字节（24位）的二进制数据划分为4组，每组6位。
- 每个6位的值（0-63）对应一个可打印字符。因为 2^6 = 64，所以共有64个字符。
- 如果输入数据长度不是3的倍数，会使用 '=' 字符进行填充。
字符集：
共64个字符：A-Z, a-z, 0-9, +, /
主要特性：
- 高编码效率：每个字符承载6比特信息，是三种编码中效率最高的。
- 通用性强：广泛用于MIME电子邮件、数据URL（如网页中的 data:image/png;base64,...）、存储加密密钥和证书等。
- 包含非字母数字字符：使用 '+' 和 '/'，这些字符在命令行或 URL 中可能需要转义处理。
- 无校验功能：标准 Base64 编码本身不提供错误检测能力。
2. Base58 编码
设计目标：针对人工处理进行优化，消除视觉上的歧义，方便用户手动输入和校对。主要应用于比特币的原始地址格式。
原理：
- 源自 Base64，但移除了容易混淆的字符。
- 将数据视为一个大整数，连续除以58，并将余数映射到特定的字符集。
- 前导零（0x00）字节会被编码为字符 '1'。
字符集：
123456789 ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
（移除了 0(零), O(大写o), I(大写i), l(小写L), +, /，共58个字符）
主要特性：
- 人性化：字符集去除了易混淆字符，极大减少了抄写和输入错误。
- 纯字母数字：生成的字符串非常“干净”，不含任何符号，易于在任何环境中复制粘贴。
- 效率稍低：每个字符承载约5.857比特信息，效率略低于 Base64。
- 常与校验和结合：在比特币中实际使用的是 Base58 Check，它在编码前添加了版本前缀和4字节的校验和，能有效检测输入错误。
应用：比特币旧式地址（P2PKH，以1开头）、比特币私钥（WIF格式）、其他加密货币如莱特币的地址。
3. Bech32 编码
设计目标：专为比特币 SegWit（隔离见证）地址设计，具有更强的错误检测和纠正能力，并且对大小写不敏感，支持高效的大写字母转换。
相关的 BIP 协议为：
- BIP-173 Base32 address format for native v0-16 witness output
- BIP-350 Bech32m format for v1+ witness addresses
- Bech32m 是 Bech32 的 V1 版本，关于 checksum 算法有微小调整。
原理：
- 基于 BCH（Bose–Chaudhuri–Hocquenghem）码构造，这是一种可以检测并纠正多个错误的纠错码。
- 结构为：HRP（人类可读部分，如 bc1）+ 分隔符（1）+ 数据部分（Base32 编码）+ 校验和。
- 使用一个经过优化的32字符子集。
字符集：(所有字母都是小写，但编码是大小写不敏感的) qpzry9x8gf2tvdw0s3jn54khce6mua7l
主要特性：
- 强大的错误检测：能检测到绝大多数错误组合，并能自动纠正少数错误。这比 Base58 Check 只能“检测”而不能“纠正”更为先进。
- 大小写不敏感：无论用户使用大写还是小写输入，地址均有效，提升了用户体验。
- 紧凑高效：数据部分使用 Base32（每个字符5比特），对于 SegWit 数据来说编码更紧凑。
- 人类可读部分(HRP)：地址开头的 bc1（比特币主网）或 tb1（比特币测试网）明确了网络类型，不易混淆。
- 成本更高：编码和解码的计算复杂度高于 Base58。
应用：比特币原生 SegWit 地址（P2WPKH，以 bc1 q...开头）、Taproot 地址（P2TR，以 bc1 p...开头）。
如果读者希望进一步深入了解相关内容，推荐查阅以下网址，其中包含了详细的 Encode 和 Decode、Checksum 示意图及步骤讲解。
总结与选择建议
通用数据传输：选择 Base64。它是网络标准，几乎所有编程语言都有现成库，效率最高。
面向用户的标识符（如旧系统）：选择 Base58 Check。它生成的字符串易于阅读和手动输入，能有效防止视觉错误。
现代加密货币地址（尤其是比特币）：强烈推荐使用 Bech32（即 bc1 开头的地址）。它提供了最高的安全性和用户体验，转账手续费也可能更低（因为 SegWit 技术的原理，witness 字段按照原有区域的四分之一计算）。这是未来的发展方向。
1.4. 数字货币地址产生的基础原理
数字货币地址是基于公私钥的密码学机制生成的：首先产生一对公私钥，然后通过特定算法和标准将公钥转换为数字货币地址。此外，有时也会通过特定机制生成一组私钥及其对应的公钥集合。
私钥的产生过程可以参考如下示意图。
推导出私钥后，即可得到对应的公钥，进而根据算法计算钱包地址。以下演示最常见的比特币地址生成过程：
上述示意图展示了最常见的地址算法生成原理。后续章节将详细讲解不同类型的比特币地址，其原理图会存在一些差异。
2. 比特币地址的相关协议
掌握了生成比特币地址的算法与编码后，还需要具体的协议标准作为支撑，这主要来自于 BIP 协议和 SLIP 协议。这两个缩写的含义如下：
BIP：Bitcoin Improvement Proposal 比特币改进提案
SLIP：SatoshiLabs Improvement Proposals 中本聪实验室改进提案
2.1. 三个核心协议（BIP-32、39、44）及相关协议
1. BIP-32 (Hierarchical Deterministic Wallets) - 分层确定性钱包
主要作用：从一个主种子（Master Seed）派生出海量的密钥对（私钥和公钥）。在此之前，钱包只是一堆毫无关联的私钥集合，备份极其麻烦。BIP-32 允许用户只需备份一个主种子（通常由 BIP-39 的助记词生成），即可恢复整个钱包树状结构中的所有地址和资金。这极大地简化了备份和恢复流程。
BIP-32 协议定义了具体的公私钥衍生算法：Child key derivation (CKD) functions
- Private parent key → private child key
- Public parent key → public child key
- Private parent key → public child key
- Public parent key → private child key
BIP-32 的分层确定性钱包原理如下图所示：
2. BIP-39 (Mnemonic code for generating deterministic keys) - 助记词
BIP-39 的主要作用：将 BIP-32 中的随机数主种子（一长串0和1）转换成一串易于人类书写、备份和记忆的英文单词（通常是12或24个单词）。协议中也说明可以使用英文句子，但很少有此类实现案例。这就是你创建钱包时看到的助记词短语，它大大改善了用户体验和备份的可靠性。
BIP 官方提供的助记词词库语言包括：English、Japanese、Korean、Spanish、Chinese (Simplified)、Chinese (Traditional)、French、Italian、Czech、Portuguese
3. BIP-44 (Multi-Account Hierarchy for Deterministic Wallets) - 多币种和多账户层次结构
BIP-44 基于 BIP-32 描述的算法和 BIP-43 描述的目的方案，定义了确定性钱包的逻辑层次结构，为 BIP-32 的密钥树建立了标准化结构。它规定了一个清晰的路径格式，例如：m/purpose'/coin_type'/account'/change/address_index。这套标准使得同一个 HD 钱包种子可以用于管理多个不同的加密货币（如比特币、莱特币、以太坊），并在每种货币下管理多个账户，每个账户下又区分收款地址和找零地址。它确保了不同钱包提供商之间的兼容性，允许处理多个代币、多个账户、每个账户的外部和内部链以及每条链的数百万个地址。
标准格式：m / purpose' / coin_type' / account' / change / address_index
- m：主密钥（master）
- purpose'：固定为 44'，表示遵循 BIP-44 标准（强化派生）。
- coin_type'：币种类型，例如比特币是 0'，以太坊是 60'（强化派生）。
- account'：账户索引，允许用户在一个钱包内创建多个账户（强化派生）。
- change：找零链。0 用于外部链(External Chain)（接收地址），1 用于内部链(Internal Chain)（找零地址）。
- address_index：地址索引，从 0 开始顺序生成。
示例：第一个比特币账户的第一个接收地址的路径是：m/44'/0'/0'/0/0
单撇号 ' 表示强化派生
4. BIP-43（Purpose Field for Deterministic Wallets）确定性钱包的目的（purpose）字段
由于单独的 BIP-32 协议给实现者提供了过多的自由度，此协议专门描述了 purpose 字段。它鼓励不同的方案申请单独的 BIP 号码，并使用相同的 purpose 字段，从而避免从重叠的 BIP-32 空间生成地址。
在 4.2 节我们会看到不同的 BIP 定义的 purpose 字段。
用途代码 10001-19999 被保留给了 SLIP 协议。
5. SLIP-0044（Registered coin types for BIP-0044）
此协议定义了 coin_type 的类型。在 SLIP-0044 中可以查看当前主流的数字货币类型，多达数千种。详细内容可在链接中查看：
2.2. 地址格式协议与演进协议
1. BIP-11（M-of-N Standard Transactions）M/N 的标准交易
该协议提供了 M/N 签名的标准交易类型，旨在提供一种更安全地使用和管理比特币资产的方式。
其指令类型我们在 3.3 节中可以看到样例。
其中锁定脚本：m {pubkey}...{pubkey} n OP_CHECKMULTISIG
解锁脚本：OP_0 ...signatures...
但该协议只定义了一种标准交易，并未定义具体的地址类型。后来，这种多签的脚本都被规范为 P2SH 的地址类型。
2. BIP-13 (Address Format for pay-to-script-hash) - P2SH 地址
BIP-13 的主要作用：定义了以数字 3 开头的地址标准。这种地址不对应单个公钥，而是对应一个脚本的哈希值。最常用于：
多重签名钱包（需要多个签名才能花费资金）。
兼容性隔离见证。
意义：将复杂的脚本条件哈希成一个简短的地址，简化了用户体验，并开启了复杂智能合约的大门。
地址格式的具体定义：
base58-encode: [one-byte version][20-byte hash][4-byte checksum]
3. BIP-16（Pay to Script Hash）支付到脚本哈希
此协议定义了支付到脚本哈希的功能，而 BIP-13 定义了支付到脚本哈希的地址。可以看到 BIP-16 定义的脚本如下：
锁定脚本：OP_HASH160 [20-byte-hash-value] OP_EQUAL
解锁脚本：...signatures... {serialized script}
可以在 3.4 节中查看具体样例。
4. BIP-49（Derivation scheme for P2WPKH-nested-in-P2SH based accounts）基于 P2WPKH 嵌套 P2SH 账户的派生方案
当使用 P2WPKH 嵌套 P2SH (BIP-141) 交易时，需要一个通用的派生方案。它允许用户无缝地使用具有相同主种子和/或单个帐户的不同 HD 钱包。因此，用户需要创建专用的隔离见证账户，以确保只有与此 BIP 兼容的钱包才能检测到账户并进行适当处理。
为了从根账户导出公钥，此 BIP 使用与 BIP-44 中定义的相同的账户结构，但仅使用不同的目的值来指示不同的交易序列化方法。
m / purpose' / coin_type' / account' / change / address_index
对于 purpose 路径级别，它使用 “49”。其余级别的使用方式按照 BIP-44 中的定义。
为了从上面计算的公钥导出 P2SH 地址，使用 BIP-141 中定义的封装：
witness: <signature> <pubkey>
scriptSig: <0<20-byte-key-hash>>
(0x160014{20-byte-key-hash})
scriptPubKey: HASH160 <20-byte-script-hash> EQUAL
(0xA914{20-byte-script-hash}87)
5. BIP-84（Derivation scheme for P2WPKH based accounts）基于 P2WPKH 账户的派生方案
当使用 P2WPKH 交易时，必须有一个通用的派生方案。它允许用户无缝地使用具有相同主种子和/或单个帐户的不同 HD 钱包。因此，用户需要创建专用的隔离见证账户，以确保只有与此 BIP 兼容的钱包才能检测到账户并进行适当处理。
为了从根账户导出公钥，此 BIP 使用与 BIP-44 和 BIP-49 中定义的相同的账户结构，但仅使用不同的目的值来指示不同的交易序列化方法。
m / purpose' / coin_type' / account' / change / address_index
对于 purpose 级别，它使用 84'。其余级别按照 BIP-44 或 BIP-49 中的定义使用。
为了从上面计算的公钥导出 P2WPKH 地址，使用 BIP-141 中定义的封装：
witness: <signature> <pubkey>
scriptSig: (empty)
scriptPubKey: 0<20-byte-key-hash>
(0x0014{20-byte-key-hash})
6. BIP-86（Key Derivation for Single Key P2TR Outputs）单密钥 P2TR 输出的密钥派生
此协议提供了单密钥 P2TR（BIP-341）输出作为 Taproot 内部密钥。为了从根账户派生公钥，此 BIP 使用与 BIP-44、49 和 84 中定义的相同的账户结构，但脚本类型的目的值不同。
m / purpose' / coin_type' / account' / change / address_index
对于 purpose 路径级别，它使用 86'。其余级别的使用方式按照 BIP-44、49 和 84 中的定义进行。
7. BIP-173 (Base32 address format for native v0-16 witness outputs) - 原生隔离见证地址（Bech32）
BIP-173 的主要作用：定义了一种全新的地址格式，专为原生隔离见证（Native SegWit）交易设计，即通常以 bc1 q 开头的地址。
优势：
更低的交易费用：原生隔离见证交易的数据量更小，因此手续费更便宜。
防错性更强：使用 Bech32 编码，能有效防止输入错误（如混淆大小写 'O' 和数字 '0'）和检测错误。
支持更大规模的升级：为未来的升级（如 Taproot）铺平了道路。
8. BIP-350 (Addresses for P2WPKH and P2WSH in Bech32m) - Taproot 地址（Bech32m）
BIP-350 的主要作用：对 BIP-173 的 Bech32 格式进行了一次微小但关键的调整，创造了 Bech32m 编码，以支持新的 Taproot 支付方式（P2TR）。这就是以 bc1 p 开头的地址。
为什么需要新格式：为了与之前的原生隔离见证（v0 版本）区分开，因为 Taproot 使用了新的见证版本（v1）。Bech32m 确保了不同版本之间的校验和验证规则不会冲突。
9. BIP-141 (Segregated Witness) - 隔离见证本身
BIP-141 的主要作用：虽然 BIP-141 本身是一个核心协议，但它引入了兼容性地址（Nested P2SH），即包裹在传统 P2SH 脚本中的隔离见证交易。这种地址以 3 开头，看起来和多重签名地址一样。
目的：在生态系统的软件和服务尚未升级支持原生 Bech32 地址时，为用户提供一种提前享受隔离见证手续费优惠的方式。现在已逐渐被原生 Bech32 地址取代。
3. 比特币的地址类型与锁定脚本类型
3.1. 支付到公钥 P2PK
P2PK（Pay To Public Key），支付到公钥。这是最早的一种地址格式，直接支付给公钥，未经过地址运算。当前已很少使用。
为了对比学习，我们将其原理和样例数据总结如下：
（1）原理示意图
（2）样例数据
为了创建一个 P2PK 可以花费的脚本，样例数据如下：
在 output 中的锁定脚本
OP_PUSHBYTES_65
049464205950188c29d377eebca6535e0f3699ce4069ecd77ffebfbdcf95e3c134cb7d2742d800a12df41413a09ef87a80516353a2f0a280547bb5512dc03da8
OP_CHECKSIG
在 input 中的解锁脚本
OP_PUSHBYTES_72
3045022100c219a522e65ca8500ebe05a70d5a49d840ccc15f2afa4ee9df783f06b2a322310220489a46c37feb33f52c586da25c70113b8eea41216440eb84771cb67a67fdb68c01
在一些浏览器中，支付到公钥，还是会被显示成支付到公钥的哈希值，也就是 1 开头的比特币地址。
这种地址格式是 1 开头的长地址，例如：
13QECtNiFPXijbMZmcgaTom3pCXwHvDYTUWGtRxZN7fY24u4fG5iiqXaQz3TvuQydLrkz9L4YhcYn3khC44yQwaZme6uoXQ
形成的过程
public key (uncompressed) =04283338ffd784c198147f99aed2cc16709c90b1522e3b3637b312a6f9130e0eda7081e373a96d36be319710cd5c134aaffba81ff08650d7de8af332fe4d8cde20
prefix + public key + checksum=0004283338ffd784c198147f99aed2cc16709c90b1522e3b3637b312a6f9130e0eda7081e373a96d36be319710cd5c134aaffba81ff08650d7de8af332fe4d8cde2067da00eb
base58 address =13QECtNiFPXijbMZmcgaTom3pCXwHvDYTUWGtRxZN7fY24u4fG5iiqXaQz3TvuQydLrkz9L4YhcYn3khC44yQwaZme6uoXQ
3.2. 支付到公钥哈希 P2PKH
P2PKH（Pay To Public Key Hash），支付到公钥哈希。P2PKH 是比较常用的交易方式。
（1）原理示意图
（2）样例数据
output 中的锁定脚本
OP_DUP
OP_HASH160
OP_PUSHBYTES_20
55ae51684c43435da751ac8d2173b2652eb64105
OP_EQUALVERIFY
OP_CHECKSIG
input 中的解锁脚本
OP_PUSHBYTES_72
3045022100c233c3a8a510e03ad18b0a24694ef00c78101bfd5ac075b8c1037952ce26e91e02205aa5f8f88f29bb4ad5808ebc12abfd26bd791256f367b04c6d955f01f28a772401
OP_PUSHBYTES_33
03f0609c81a45f8cab67fc2d050c21b1acd3d37c7acfd54041be6601ab4cef4f31
执行脚本的示意图
P2PKH 的地址形成示意图
这种地址格式是 1 开头的地址，例如：1JBSCVF6VM6QjFZyTnbpLjoCJTQEqVbepG
形成的过程
public key (uncompressed) =04283338ffd784c198147f99aed2cc16709c90b1522e3b3637b312a6f9130e0eda7081e373a96d36be319710cd5c134aaffba81ff08650d7de8af332fe4d8cde20
hash160(public key) =bc73550c1612ee81155d29254217cbd60084a6d1
prefix+hash160(publickey)+checksum =00bc73550c1612ee81155d29254217cbd60084a6d1691c58b9
base58 address = 1JBSCVF6VM6QjFZyTnbpLjoCJTQEqVbepG
从理论上讲，一个未压缩的130字符的公钥，经过 Hash160 压缩为40字符的哈希值，就会有产生哈希碰撞的可能性，也就是地址会有重复的可能性（概率很小）。
3.3. 支付到多签 P2MS
P2MS（Pay To Multisig），支付到多签。相关的原理解释需要参考 BIP-11：M-of-N Standard Transactions
（1）原理示意图
对于上面的示意图，使用 2/3 多签示意如下：
（2）样例数据
output 中的锁定脚本
OP_2
OP_PUSHBYTES_65
04d81fd577272bbe73308c93009eec5dc9fc319fc1ee2e7066e17220a5d47a18314578be2faea34b9f1f8ca078f8621acd4bc22897b03daa422b9bf56646b342a2
OP_PUSHBYTES_65
04ec3afff0b2b66e8152e9018fe3be3fc92b30bf886b3487a525997d00fd9da2d012dce5d5275854adc3106572a5d1e12d4211b228429f5a7b2f7ba92eb0475bb1
OP_PUSHBYTES_65
04b49b496684b02855bc32f5daefa2e2e406db4418f3b86bca5195600951c7d918cdbe5e6d3736ec2abf2dd7610995c3086976b2c0c7b4e459d10b34a316d5a5e7
OP_3
OP_CHECKMULTISIG
input 中的解锁脚本
OP_0
OP_PUSHBYTES_72
3045022100af204ef91b8dba5884df50f87219ccef22014c21dd05aa44470d4ed800b7f6e40220428fe058684db1bb2bfb6061bff67048592c574effc217f0d150daedcf36787601
OP_PUSHBYTES_72
3045022100e8547aa2c2a2761a5a28806d3ae0d1bbf0aeff782f9081dfea67b86cacb321340220771a166929469c34959daf726a2ac0c253f9aff391e58a3c7cb46d8b7e0fdc4801
执行脚本的示意图
P2MS（支付到多签）实际上没有地址格式，最常用的方式是将 P2MS 支付脚本被包裹在 P2SH 或 P2WSH 脚本中，因此其地址参考其他两种类似的地址。与直接使用 P2MS 相比，具有如下优势：
因为 P2MS 没有地址格式。因此，如果你希望对你的比特币进行直接锁定，你需要自行构建并发送原始锁定脚本。更糟糕的是，这样可能无法为你创建此交易，因为大多数钱包只允许你在进行交易时使用地址（而非原始脚本）。这样的情况，使得只有专业的人员使用特定工具或开发工具来构造能花费这种 UTXO 的 input，对普通人具有较高的门槛。
P2MS 限制最多使用 3 个公钥。由于包含所有公钥，P2MS 的锁定脚本会变得非常庞大（导致手续费也很高），因此限制为 3 个（以防止 UTXO 集中存储过多数据）。但是，使用 P2SH，你可以使用最多 15 个公钥进行多重签名锁定。
因此，如果用户愿意，仍然可以使用 P2MS，但使用 P2SH 实现相同功能会更方便。
3.4. 支付到脚本哈希 P2SH
P2SH（Pay To Script Hash）支付到脚本哈希。可以支付到脚本哈希后，比特币的交易表现的能力得到了很大的增强。
（1）原理示意图
（2）样例数据
output 中的锁定脚本
OP_HASH160
OP_PUSHBYTES_20
748284390f9e263a4b766a75d0633c50426eb875
OP_EQUAL
input 中的解锁脚本
OP_0
OP_PUSHBYTES_71
3044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401
OP_PUSHBYTES_71
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6cec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae
执行脚本的示意图
地址原理
Encode the hash160 of a public key or script to a legacy address.
这种地址格式是 3 开头的地址（测试网是 2 开头地址），例如：
3Nfmmt78SUwQTZtr4p9qty5Wgaykt6PhoS
形成的过程：
将用户的公钥或脚本进行 Hash160 编码，得到结果：
hash160(public key or Script) =d5ed76bbb243d456240014178ba5fbb37ada36bc
base58 address = prefix（05）+hash160(public key or Script)+checksum（32e485ca）= 3MCAKgGRPTMjYP3cD1vTeD7aQZJPVECAC1
P2SH 的几个明显优点是：
- 更容易使用复杂的解锁脚本（也为后续的 Taproot 中使用 MAST 树提供了基础）；
- 更便宜的手续费（其实是将成本转移到了花费者的身上，花费输出的人需要使用更多的解锁字节）；
lP2SH 提供更强的隐私性；
因为 output 中的字节减少，整个 UTXO 的集合更小。因为单个 UTXO 的尺寸更小，更多的 UTXO 可以放到内存中。
注意：在 P2SH 中，赎回脚本的最大长度是 520 个字节。这也就是 P2SH 脚本如果是 P2MS，那么最多是 15 个公钥（压缩公钥是 33 字节，15 个压缩公钥是 33*15=495 字节，是小于 520 字节的最大值）。
3.5. 支付到包裹的见证公钥哈希 P2SH-P2WPKH
2SH P2WPKH wrapped in a P2SH，将支付到见证公钥哈希 P 包裹到支付到脚本哈希 P2SH 方式中。P-P2WPKH()2WPKH
（1）原理示意图
（2）样例数据
output 中的锁定脚本
OP_HASH160
OP_PUSHBYTES_20
6d3ed4cf55dc6752a12d3091d436ef8f0f982ff8
OP_EQUAL
input 中的解锁脚本
OP_PUSHBYTES_22
001402c8147af586cace7589672191bb1c790e9e9a72
执行脚本的示意图
（3）这种支付形成地址的示意图如下：
这种地址格式是 3 开头的地址，例如：3Beer3irc1vgs76ENA4coqsEQpGZeM5CTd
3.6. 支付到包裹的见证脚本哈希 P2SH-P2WSH
P2SH-P2WSH(P2WSH wrapped in a P2SH)，将支付到见证脚本哈希 PS 包裹到支付到脚本哈希 P2SH 方式中。
（1）原理示意图
（2）样例数据
output 中的锁定脚本
OP_HASH160
OP_PUSHBYTES_20
257014cec2f75c19367b2a6a0e08b9f304108e3b
OP_EQUAL
input 中的解锁脚本
OP_PUSHBYTES_34
0020973cfd44e60501c38320ab1105fb3ee3916d2952702e3c8cb4cbb7056aa6b47f
执行脚本的示意图
（3）这种支付形成地址的示意图如下：
这种地址格式是 3 开头的地址，例如：3NUPJunPTWu5ivNHoi375bsTiN7P2MpZC2
3.7. 支付到见证公钥哈希 P2WPKH
P2WPHK（Pay To Witness Public Key Hash）支付到见证公钥哈希。这种是用于隔离见证地址的支付。
（1）原理示意图
（2）样例数据
output 中的锁定脚本
OP_0
OP_PUSHBYTES_20
841b80d2cc75f5345c482af96294d04fdd66b2b7
input 中的解锁脚本（Witness 区数据）
3044022042e5e3ed2a41214ae864634b6fde33ca2ff312f3d89d6aa3e14c026d50d8ed3202206c38dcd0432a0724490356fbf599cdae40e334c3667a9253f8f4cc57cf3c448001
03f465315805ed271eb972e43d84d2a9e19494d10151d9f6adb32b8534bfd764ab
执行脚本的示意图
地址形成示意图
使用前缀 OP_0 来区分隔离见证的第一个版本（后面的 Taproot 地址使用 OP_1 来区分），后面是 20 个字节的公钥哈希，最后使用 Bech32 地址编码格式。
这种地址格式是 bc1 q 开头的地址，例如：
bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
注释：P2WPKH 只接受压缩公钥
3.8. 支付到见证脚本哈希 P2WSH
P2WSH（Pay To Witness Script Hash），支付到见证脚本哈希。
（1）原理示意图
（2）样例数据
output 中的锁定脚本
OP_0
OP_PUSHBYTES_32
65f91a53cb7120057db3d378bd0f7d944167d43a7dcbff15d6afc4823f1d3ed3
input 中的解锁脚本
00
30440220415899bbee08e42376d06e8f86c92b4987613c2816352fe09cd1479fd639f18c02200db57f508f69e266d76c23891708158bda18690c165a41b0aa88303b97609f7801
304402203973de2303e8787767090dd25c8a4dc97ce1aa7eb4c0962f13952ed4e856ff8e02203f1bb425def789eea8be46407d10b3c8730407176aef4dc2c29865eb5e5542bf01
522103848e308569b644372a5eb26665f1a8c34ca393c130b376db2fae75c43500013c2103cec1ee615c17e06d4f4b0a08617dff8e568936bdff18fb057832a58ad4d1b752103eed7ae80c34d70f5ba93f93965f69f3c691da0f4607f242f4fd6c7a48789233e53ae
执行脚本的示意图
地址形成示意图
使用前缀 OP_0 来区分隔离见证的第一个版本（后面的 Taproot 地址使用 OP_1 来区分），后面是 32 个字节的脚本哈希，最后使用 Bech32 地址编码格式。
这种地址格式是 bc1 q 开头的地址，例如：
bc1qmc7d40nxddfklulxq55f2jhupauaystdlxnj69asztedz8uz6e3q9lj223
3.9. 支付到 Taproot 地址 P2TR
P2TR（Pay To Taproot），支付到 Taproot 地址。这种类型的支付有两种情况一种是 Key Path Spend，另一种是 Script Path Spend，详细内容见下面的说明。
（1）原理示意图
（2）样例数据 1 -Key Path Spend
output 中的锁定脚本
OP_1
OP_PUSHBYTES_32
0f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667
input 中的解锁脚本
b693a0797b24bae12ed0516a2f5ba765618dca89b75e498ba5b745b71644362298a45ca39230d10a02ee6290a91cebf9839600f7e35158a447ea182ea0e022ae01
Key Path Spend 执行脚本的示意图
（3）样例数据 2-3 Script Path Spend
output 中的锁定脚本
OP_1
OP_PUSHBYTES_32
0f0c8db753acbd17343a39c2f3f4e35e4be6da749f9e35137ab220e7b238a667
input 中的解锁脚本
01769105cbcbdcaaee5e58cd201ba3152477fda31410df8b91b4aee2c4864c7700615efb425e002f146a39ca0a4f2924566762d9213bd33f825fad83977fba7f01
206d4ddc0e47d2e8f82cbe2fc2d0d749e7bd3338112cecdc76d8f831ae6620dbe0ac
c0924c163b385af7093440184af6fd6244936d1288cbb41cc3812286d3f83a3329
执行脚本的示意图
使用前缀 OP_1 来区分隔离见证的第二个版本（前面的 SegWit 地址使用 OP_0 来区分），后面是 20 个字节的公钥哈希，最后使用 Bech32 地址编码格式。
这种地址格式是 bc1 p 开头的地址，例如：
bc1ppsxtf9y28tx36e6nlra79m270vuagzknt97w6ga4ah5g7ggxpu8s6z8ftw
4. 比特币交易中的派生路径地址与隐私保护
4.1. 比特币的交易变化历史
比特币的地址变化还与几次比特币的交易变化历史有较大的关系。主要是比特币的两次隔离见证产生的变化。
1. 白皮书中定义的交易（简单交易模型）
早期最基本的比特币交易，允许有多个输入和最多两个输出。其中一个输出的数值是给自己的找零，另外一个输出是给外部的转账。（备注：总输入与总输出之间的差额是手续费）
早期的地址是 P2PK，P2PKH，P2MS，P2SH 几种地址类型。
2. 隔离见证第一版(SegWit)中的交易
隔离见证（Segregated Witness，简称 SegWit）是比特币区块链网络的协议升级方案，作为 Bitcoin Core 客户端的核心更新提案，由开发者 Pieter Wiulle 于 2015 年 12 月提出，通过分离交易数据与签名数据实现扩容。该方案保持与传统比特币网络的兼容性，避免了硬分叉。
其核心机制将区块容量上限从 1 兆字节扩展至 4 兆字节（统计中的实际扩容约 2-2.1 兆字节），通过将数字签名存储于附加见证区块释放主链空间。该技术解决了交易延展性问题，改进交易标识生成方式防止双重支付攻击，并为闪电网络等第二层协议奠定基础 。作为被业内大多数企业采用的主流客户端标准，Bitcoin Core 的此次升级需全网 95%算力支持，但实际支持率长期维持 32%-33.8%。反对意见集中于技术效用争议及第三方介入可能削弱比特币去中心化特性。2017 年 8 月 24 日该协议在比特币主网激活。
中的地址是 P2WPKH，P2WSH，P2SH-P2WPKH，P2SH-P2WPSH 几种地址类型。
3. 隔离见证第二版（Taproot）中的交易
Taproot 技术在 2020 年 1 月份提出，2021 年 11 月，Taproot 以软分叉的形式正式生效。此次升级由 BIP-340、BIP-341 和 BIP-342 组合。其中 BIP-340 引入了可以同时验证多个交易的 Schnorr 签名，取代了椭圆曲线数字签名算法（ECDSA），再一次扩大了网络容量并加快了批量交易的处理速度，为部署复杂的智能合约提供了可能性；BIP-341 实现了默克尔化抽象语法树（MAST）来优化区块链上的交易数据存储；BIP-342（Tapscript）采用比特币的脚本编码语言扩充的比特币原生脚步能力的不足。
Taproot 中的地址是 P2TR 一种地址类型。
4.2. 常见的已知派生路径定义
我们先了解比特币的常见派生路径，然后再看其他链的常见派生路径。
1. 常见的比特币派生路径
BIP 中定义的派生路径标准格式：m / purpose' / coin_type' / account' / change / address_index
比特币最常见的几种派生路径，它们的主要区别在于 purpose 字段，对应了不同的地址类型。
（1）BIP-44 - Legacy (原始)地址(1...)
路径：m/44'/0'/0'/0/0
目的：最早的 HD 钱包标准，用于生成以 1 开头的 P2PKH 地址。
特点：
兼容性最好，所有钱包和交易所都支持。
交易手续费最高，因为其交易数据体积较大。
使用场景：现在主要用于从非常老的钱包中恢复资金，或向不支持新地址类型的古老平台充值。
（2）BIP-49 - Nested SegWit (嵌套隔离见证)地址(3...)
路径：m/49'/0'/0'/0/0
目的：用于生成以 3 开头的 P2SH-P2WPKH 地址。
特点：
通过将 SegWit 地址包装在 P2SH 脚本中来实现。
手续费比 Legacy 低，但比 Native SegWit 高。
兼容性很好，几乎所有的钱包和交易所都支持接收和发送到 3 开头的地址。
使用场景：在 SegWit 推广初期，作为向 Native SegWit 过渡的兼容方案。现在仍然被广泛支持。
（3）BIP-84 - Native SegWit (原生隔离见证)地址(bc1 q...)
路径：m/84'/0'/0'/0/0
目的：用于生成以 bc1 q 开头的 P2WPKH 地址。
特点：
手续费最低，因为其交易数据体积最小，是最高效的格式。
安全性最佳，完全受益于隔离见证的技术优势。
兼容性：目前绝大多数现代钱包、节点和交易所都已支持。但一些非常老旧的系统可能无法识别。
使用场景：当前的首选和推荐标准，用于节省手续费并享受最新的技术特性。
（4）BIP-86 - Taproot (P2TR)地址(bc1 p...)
路径：m/86'/0'/0'/0/0
目的：用于生成以 bc1 p 开头的 P2TR 地址。这是比特币的最新一次重大升级。
特点：
隐私性更好，使简单支付和复杂脚本交易在链上看起来几乎没有区别。
效率更高，为复杂的智能合约（如闪电网络、DLCs）提供了更好的可扩展性和更低的费用。
签名算法（Schnorr Signatures）更高效，支持密钥聚合。
使用场景：代表比特币的未来发展方向，适合希望使用最新技术、追求更低费用和更好隐私的用户和应用。
（5）RGB 技术中用到的派生路径
如果根据 RGB-0044 协议，符合 BIP-44 协议标准和 SLIP-44 协议中队 coin 的定义，purpose 使用的是 84，RGB 的官方派生路径如下：m_type/84’
此外作者还查阅到 RGB 官方网站中，根据 LNPBP-46: LN derivations 中的描述，使用了 m/9735'/的衍生路径，具体的相关内容如下：
注：具体以哪个为标准，还需要进一步的研究相关应用和 RGB 协议文档。
（6）其他重要路径
BIP-32 根路径：m/0' (或有时用 m/0)。一些老旧的实现或非标准钱包可能会直接使用这个路径，但极不推荐，因为它不符合多币种多账户的标准。
多签名钱包路径：对于多签钱包，每个协作者通常会使用自己的标准路径（如 m/48'/0'/0'/2'）来派生用于多签的公钥。这通常由协调多签的钱包软件（如 Electrum, Specter）来管理，普通用户无需手动处理。
测试网路径：只需将上述路径中的 coin_type 从 0'改为 1'即可。例如，测试网 Native SegWit 路径为：m/84'/1'/0'/0/0。
2. 以下列出一些主流币种及其常见的派生路径。
（1）以太坊(Ethereum)及 EVM 兼容链(BSC, Polygon, Avalanche C-Chain 等)
以太坊及其众多衍生链共享相同的 coin_type，因为它们使用相同的密码学（secp 256 k 1 曲线）和地址格式。
路径：m/44'/60'/0'/0/0
coin_type: 60'
地址格式: 0x...
说明:这是 MetaMask、Trust Wallet 等绝大多数钱包使用的默认路径。所有基于 EVM 的链（如 BSC m/44'/60'/0'/0/0, Polygon m/44'/60'/0'/0/0）都使用同一个路径和同一组私钥。你在不同链上的地址看起来会一模一样，但它们是不同链上的独立账户。切换网络时，钱包软件通过 RPC 节点来区分不同的链。
（2）币安币(BNB)信标链
BNB 有其独立的链和地址系统，与 EVM 链不同。
路径：m/44'/714'/0'/0/0
coin_type: 714'
地址格式: bnb1... (Bech32)或 tbnb1... (测试网)
说明:用于币安链（Binance Chain）上的 BNB 资产。
（3）波卡(Polkadot)
路径：m/44'/354'/0'/0/0
coin_type: 354'
地址格式:基于 SS58 格式，通常以 1 开头。
（4）索拉纳(Solana)
路径：m/44'/501'/0'/0'
coin_type: 501'
说明:注意，Solana 的路径在最后使用了强化派生 0'，而不是普通的 0。这是其标准做法。
（5）卡尔达诺(Cardano)
Cardano 的派生路径比较特殊和复杂，它基于自己的 BIP-44-ADA 方案。
路径：m/1852'/1815'/0'/0/0
purpose: 1852' (专门为 Cardano 设计)
coin_type: 1815' (ADA 的诞生年份)
地址格式: addr1... (Bech32)
说明:这是 Daedalus 和 Yoroi 钱包使用的标准路径。
（6）瑞波币(Ripple - XRP)
路径：m/44'/144'/0'/0/0
coin_type: 144'
地址格式: r... (Base58)
（7）莱特币(Litecoin)
莱特币类似比特币，也有多种地址类型。
Legacy (L...): m/44'/2'/0'/0/0
SegWit (M...): m/49'/2'/0'/0/0
Native SegWit (ltc1 q...): m/84'/2'/0'/0/0
coin_type: 2'
（8）狗狗币(Dogecoin)
路径：m/44'/3'/0'/0/0
coin_type: 3'
地址格式: D... (Base58)
（9）波场(Tron)
路径：m/44'/195'/0'/0/0
coin_type: 195'
地址格式: T... (Base58)
3. 非标准或例外情况
（1）门罗币(Monero)
门罗币不使用 BIP-32/BIP-44 标准。它有自己的分层确定性钱包方案，使用不同的密码学（Ed25519 曲线）和密钥结构。
它的派生路径看起来像：m/44'/128'/0' (但这不是标准 BIP-32 路径)
重要提示:你不能使用为比特币/以太坊设计的助记词在门罗钱包中直接恢复出资金，反之亦然。恢复门罗币钱包必须使用门罗币自己的助记词和系统。
（2）硬件钱包的“以太坊经典”路径
一些硬件钱包（如 Ledger）为以太坊经典（ETC）设置了独立的路径，以将其与以太坊（ETH）区分开，尽管它们的地址格式相同。
以太坊(ETH): m/44'/60'/0'/0/0
以太坊经典(ETC): m/44'/61'/0'/0/0
4.3. 隐私保护与多地址使用
比特币有一个比较特殊的现象“找零地址变化”，或者说 UTXO 模型的区块链都可以有这种特性。要理解“找零地址变化”，需要理解三个关键知识点：
1. UTXO 模型（未花费交易输出）
这是比特币最核心的账本模型，不同于传统的账户余额模型。
基本原理：比特币网络记录的并不是你的“余额”，而是一张张未花费的“支票”（即 UTXO）。这些支票面额各异，且一旦被花掉就会被销毁，并创造出新的支票。
交易过程：当你支付时，你必须拿出你钱包里的一张或几张“支票”（输入），它们的总面值必须大于或等于你要支付的金额。交易会创建两个新的“支票”：
一张给收款人：面额等于支付金额。
一张给你自己（找零）：面额等于（输入总额-支付金额-交易手续费）。
关键结论：找零本质上是一笔支付给你自己的新输出（UTXO）。它和你付给别人的输出在交易结构中没有任何区别。
注释：这里使用支票这个单词，而不使用现金（经常是定额印刷好的）这个单词，是因为支票上的金额是随机的，每张支票的金额都有可能不同，这更符合比特币中 UTXO 的场景描述。很多时候混合使用支票和现金都是表达同一个意思。
2. 隐私保护设计
使用固定的地址会严重损害隐私。
地址复用问题：如果所有 UTXO（包括找零）都回到同一个地址，那么区块链分析机构或人员可以轻易地：
关联你的所有交易：知道这个地址背后的所有资金流动。
估算你的财富：清楚地看到你的总收入。
破坏匿名集：无法将他人的交易与你的交易混合起来。
解决方案：为每一笔交易的找零使用一个全新的地址。这使得外部观察者很难确定一笔交易中哪个输出是支付给商家的，哪个输出是找零返回给自己的。这极大地增加了区块链分析的难度，保护了你的财务隐私。
3. HD 钱包（分层确定性钱包）的技术实现
手动为每次找零管理新地址和私钥是不可行的，HD 钱包自动化了这个过程。
链式结构：HD 钱包从一个种子（助记词）可以生成近乎无限个地址和私钥。
派生路径：如我们之前讨论的，标准路径 m/44'/0'/0'/1/*专门用于找零（change = 1）。
m/44'/0'/0'/0/*： 用于生成接收地址（外部链）。
m/44'/0'/0'/1/*： 用于生成找零地址（内部链）。
工作流程：
你的钱包软件在构造一笔交易时，如果需要找零，它会自动从内部的“找零地址池”（/1/*）中取出作为找零接收地址。下一个从未使用过的地址
这笔交易被广播并确认后，新的找零 UTXO 就保存在这个新地址下。
当你下次花费资金时，你的钱包会同时扫描接收链和找零链下的所有 UTXO，将它们一起作为可用的“输入”。你无需手动管理，钱包会自动处理好一切。
简单总结：“找零地址变化”是、和三者结合的必然结果。它不是可选项，而是比特币钱包的标准行为。UTXO 模型隐私保护需求 HD 钱包技术
使用区块链浏览器：找一笔真实的交易（比如你自己钱包里的一笔交易），在 mempool.space 或 blockstream.info 上查看它的详情。尝试分析它的输入和输出，猜猜哪个是支付输出，哪个是找零输出（通常找零输出会指向一个属于发送方的新地址）。
使用测试钱包：在测试网上创建一个新钱包，进行几次发送和接收操作，然后观察你钱包内的地址列表是如何变化的，UTXO 是如何产生和消耗的。
到此这篇关于比特币地址是什么?一文带你系统梳理比特币地址相关的知识体系的文章就介绍到这了,更多相关比特币地址内容请搜索以前的文章或继续浏览下面的相关文章，希望大家以后多多支持！