acess
2021-04-22 02:42:11 +08:00
中本聪那个时代我没经历过,不过从当时的官网软件截图来看,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 地址,它编码表示的是公钥哈希,从公钥哈希是无法逆推计算得到公钥的,只能扫描区·块·链账本才能找到哈希值匹配的公钥。