还是 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 裸公钥输出）在这方面会存在一些混淆。

一个私钥可以控制很多很多种地址。

一般来讲，不同的地址就是不同的地址。

@h4de5
摘自 solidot：
"著名的《 Mastering Bitcoin 》（《精通比特币》）一书中有段 Python 代码有误（ key-to-address-ecc-example.py ），这段代码被广为流传。这个错误有极高的概率会根据一个正确的私钥生成一个错误的压缩公钥，从而产生一个错误的比特币收款地址，如果使用这个地址会导致比特币资金丢失。”

话说，有什么方便的办法能检验 apk 签名么？最好是能直接跟 play 之类权威来源比对，最不济也要能比对公钥指纹。
keytool 命令行太麻烦了。

python 不是有 pip 可以安装 libsecp256k1 么

如果楼主不是想寻宝的话，也有 btcrecover 这个可以用来恢复钱包，比如助记词差了一两个单词这种。

@shafake 就是 Large Bitcoin Collider 吧

已经有了，Large Bitcoin Collider 。
印象里破出来的都是之前有个人故意留下来的寻宝游戏私钥。