然后回到主贴提到的：
“未来激活了 taproot，公钥可以和脚本哈希合体，里面还可以藏入……额……嵌套多层的脚本哈希……”

乍一看很可怕。但是，只要明白了 P2SH 是咋回事——无非就是，先登记合同的哈希值，未来要按照合同内容执行时，再提供完整的合同全文——那就会明白，taproot （这里不单指 taproot 本身，还包括了 MAST ）并不是吓人的复杂怪物。

（不过老实说楼主也没亲自测试过 taproot，可能很多地方还有误解，轻喷）

（哎，14 楼还是有一处打字错误，纠正一下：“改进 [后就变成] 了现在广泛使用的新功能”，抱歉）

（楼上“P2PKH 就不是这样”这里没打错，我就是拿 P2PKH 举个例子，和 P2SH 的前身做一个对比）

（其实 P2SH 是把原先存在的一种很鸡肋的输出脚本语义改变了……这种很鸡肋的输出脚本，在比特币引入 P2SH 功能之前，只走到“把你给出的赎回脚本进行哈希，和当初的脚本哈希比对，结果一致”这一步，就算验证通过了。这种情况，乍一看，好像是“输入密码即可提款”，很简单，但没有实用性。为什么没有实用性？因为任何人都可以把交易输出里的收款地址篡改成自己的，篡改完了交易仍然有效。P2PKH 就不是这样，交易输出是受数字签名保护的，篡改了输出，交易就无效了。总之，P2SH 用一种很 hack 的方式，把之前几乎无用的一种输出脚本重新定义，改进了现在广泛使用的新功能）

这个脚本哈希值就可以代表你原先写的那个脚本，这种情况下，哈希之前的锁定脚本就改叫“赎回脚本”（ redeem script ）了。

未来要把币“解锁”转出去的时候，不仅要提供“解锁”的条件（一般就是数字签名），还要把“赎回脚本”的原文一同给出。
大家把你给出的赎回脚本进行哈希，和当初的脚本哈希比对，结果一致，然后就按照赎回脚本规定的步骤，去验证币能不能“解锁”花出去。

无论你的锁定脚本写得多么乱七八糟，都可以哈希一下，然后，这个脚本的哈希值就可以用一个 3 开头的地址来表示。

3 开头的地址——看看，有地址了！无论多么乱七八糟的锁定脚本，都可以用一个标准的、3 开头的地址来表示。

于是，很久很久以前（没记错的话是 2012 年），比特币引入了一个新功能，P2SH 。

1 开头的 P2PKH 地址，实际上对应了一个“锁定脚本”，它规定了，在满足什么条件下，可以把币“解锁”、转（花）出去。

如果条件不满足（比如，你没给出有效的数字签名；或者是锁定时间还没到期，等等），那这笔交易就是非法的，不能打包进链，哪个矿工敢打包，大家就都不承认他挖的区块。

这个锁定脚本的写法，很显然是很自由的……但是如果你写的不是标准的脚本，那按理说就没有对应的地址可以表示这个脚本了。

下面展开说说输出脚本这个梗……

第三种：bc1 开头的 P2WPKH 地址，又叫 Bech32 地址，或者叫“原生”隔离见证地址。
前两种地址都是中本聪设计的 Base58check 编码，大小写混合； Bech32 编码是新设计的，不含混合大小写，要么全大写要么全小写。
因为 Bech32 编码是新设计的，所以存在兼容性问题：老钱包不识别新地址，于是老钱包（在操作上）就不能转账给这种新地址——把钱包升级到支持 Bech32 的新版，或者把私钥 /助记词导出，再导入给支持 Bech32 的其他钱包，就可以了。
新钱包从新地址转给老钱包是没问题的（顶多就是零确认看不到，进链确认了就能看到进账了）。

第二种：3 开头的 P2SH-P2WPKH 地址，又叫 P2SH 封装隔离见证地址，或者叫“兼容”隔离见证地址。
兼容性和第一种差不多；
矿工费因为享受了折扣，所以（在转出时）比第一种便宜不少，但是因为 P2SH 封装本身也要占字节数，所以矿工费仍然比第三种贵；

第一种：1 开头的 P2PKH 地址，最老、最经典、最通用；矿工费没有折扣所以最贵。
（公钥当然是压缩公钥。P2PKH 可以用非压缩公钥，但是现在一般都不用了。另外下面提到的隔离见证还是禁用压缩公钥的）

(1)生成好多个地址；
(2)每次无论是收款还是付款，都会换（生成）一个新的地址（但是别怕，只要 HD 种子备份好了，这些地址都可以恢复出来）；
(3)而且这些地址还分 3 种：

……虽然，你给钱包导入 1 个 HD 助记词（或者叫 HD 种子）后，还是会：

还是 1-1 对应，还是那么简单清爽——虽然……

不过，幸运的是，对于现在最通用的 BIP39/44/49/84 钱包来说（不幸的是，最“官方”的 Bitcoin Core 目前还不是这个体系，尤其是有些开发者很抵制 BIP39 助记词，哎），不同的地址类型需要走不同的 HD 推导路径，不会出现一个公 /私钥被用到多种不同地址身上的情况。

只要你自己不自找麻烦，不把单个私钥或公钥手动导出后瞎折腾（换句话说，如果你瞎折腾了，那就可能出现问题，主要就是，你自己折腾出来的新地址，只能在你自己折腾的非标准钱包里看到交易记录和余额；而在标准的钱包里扫描不到，就好像丢了币一样），那还是：

[一个私钥]<=>[一个公钥]<=>[一个地址]

（因为万恶的和谐，必须把文字拆开，看看哪里触发了和谐，抱歉）

中本聪那个时代我没经历过，不过从当时的官网软件截图来看，1 开头的地址（公钥哈希）只是考虑收款方不在线的时候才要用到的。如果收款方在线，就直接用 IP 地址从对方下载一个公钥回来，然后支付给这个公钥（而不是公钥哈希）。这个“付款给 IP 地址”的功能后来被删掉了。

不仅如此，那个时候挖矿得到的币，也大多放到这种“裸公钥输出”（ P2PK ）上，而不是现在常用的公钥哈希输出（ P2PKH ）上。

就比如 9 号区块，没记错的话这个区块挖到的币公认是中本聪的，中本聪后来用这些币发起第一笔比特币转账给 Hal Finney 。

你去不同的区块浏览器查 9 号区块，显示出来的样子是就不一样的，虽然表示的内容实际上是一样的。
blockchair . com 会显示 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 这个地址；
而 blockstream . info 和 btc . com 就不显示这个 1 开头的地址。

9 号区块的 coinbase 输出用的就是这种 P2PK 裸公钥输出，而不是现在通用的 P2PKH 公钥哈希输出。

如果继续查 12cbQLTFMXRnSzktFkuoG3eHoMeFtpTu3S 这个地址的交易记录，不同区块浏览器显示的结果也不一样。不出意外的话，就是因为有的区块浏览器把 P2PK 和 P2PKH 都统计在内；而有的区块浏览器就只统计 P2PKH，不包括 P2PK 。

很多开发者都觉得，1 开头的地址就是 P2PKH 地址，只应该用来表示 P2PKH 输出，把它借用过来表示其他的东西是不对的，造成了混淆。但是毕竟这个“混淆”多年以前就一直这么干，现在要“纠正”反而还有点难受。毕竟，如果你一开始只知道 1 开头的 P2PKH 地址，它编码表示的是公钥哈希，从公钥哈希是无法逆推计算得到公钥的，只能扫描区·块·链账本才能找到哈希值匹配的公钥。

按理说，A 地址有币就是 A 地址有币，不会用 B 地址去查，结果却查到了 A 地址上的币。

（不过很显然，不同地址上的币是可以一起花出去的，毕竟比特币从一开始就推荐地址用一次就换一个，尤其是后来有了 HD 钱包，换地址后不需要重新备份私钥，只要备份好一个助记词种子就一劳永逸）

但是因为历史遗留问题，在极少见的情况下（比如中本聪的币，用了 P2PK 裸公钥输出）在这方面会存在一些混淆。