@mengyx 啊，我在 Fiddler 5.0 上试了，不过我把 fiddler.certmaker.GraceDays 和 fiddler.certmaker.ValidDays 都设成正整数了，而不是负数，负数好像会生成还没生效的证书。

@lusi1990 搜了一下，Fiddler 好像不支持 HTTP/2

@mengyx 额，证书过期时间这个，我确实没注意。重新生成证书后，貌似 MuMu 里自带浏览器就不会报证书错误了。至于之前为什么不同网站，有的报错有的不报错，我不知道为什么，也不想管了……

@MaxLi77 准确地讲，host 模式是有 GPU 加速的，但是有的时候渲染不正确。

@MaxLi77 额，按理说我现在有了带 edxp 的 AVD，也可以直接上 justtrustme……不过我感觉 AVD 还是有点卡，尤其是 GPU 硬件加速好像还是开不了，按照官方文档里说的，win 上可以从 host 模式调到 angle_indirect 模式，现在好像这个设置是无效的。再有就是 justtrustme 这类 xposed 模块虽然可以搞定 ssl pinning，也总有照顾不到的死角（ hook 不到的代码）吧……

@Telegram 我看 JustTrustMe 这个 Xposed 模块里提到，有些 app 用了 Public Key (Certificate) Pinning——感觉就是类似 SSH 那样，不是信任 CA 来验证，而是 app 里直接指定一个服务器公钥。这种情况貌似确实比较麻烦，导了 CA 也不能解决，只能是 xposed 或者改包了吧。

@KuroNekoFan 这个我之前也看到了，按理说 MuMu 是 Android 6，所以不需要折腾系统证书也能达到类似的效果吧……

我主要感觉奇怪的是，为什么同一个 app 下（自带浏览器），不同网站的情况也不一样……这太诡异了
再有就是为啥 Android 11 的 AVD 用了 movecert 就会无法正常启动……这也很诡异

莱特币的 M 开头地址表示的是 P2SH，和比特币这边 3 开头的地址一样。原先两个币种 P2SH 都是 3 开头的地址，所以偶尔会出现 BTC 打到 LTC 地址（或反之）之类的错误……嗯，（据我所知）按理说出现这个情况，其实币没丢，只要私钥倒腾一下，从 LTC 钱包倒腾到 BTC 钱包（或反之）即可；不过像交易所充错地址之类情况，可能交易所就以各种理由拒绝找回了。

BCH 因为去掉了隔离见证（当初从 BTC 分叉出去就是为了抵制隔离见证），貌似还新加了脚本操作码，所以情况会更复杂，打错币种可能出现币被锁死或者“任何人都可以花”的情况。

在 BTC 里面，一般而言（不去想 P2PK 这个历史包袱），不同的地址就是不同的地址。


考虑其他币种的话……

莱特币还有 M 开头的地址，表示的意思和 3 开头的地址一样，就是因为 3 开头的地址和比特币混淆了（），所以才改成 M 开头。这两种只是地址格式不一样，表示的内容是完全一模一样的，就是换了个编码方式，所以甚至还可以互相转换。不过很显然，这个转变有阵痛，而且也许很长很长时间都不能覆盖到所有人。

BCH 的 CashAddr 也是类似的情况。

P2PK 这个中本聪时代的梗其实相对不太重要……

楼主的问题，确实说来话长，我一写就刹不住车，新开了一个帖子：
/t/772332

（可以大幅节省字节数，N 个人一起混币，交易里只占一份数字签名的字节数，而不是 N 份），但 CISA 貌似也还是没有实现……

本来 schnorr 签名理论上还可以实现 CISA （ cross-input signature aggregation，跨输出签名聚·合），看上去对 coinjoin 很有用

换句话说，只有未来所有人都用上 taproot 了，taproot 的第(1)点好处才能完全体现；然而哪怕是现在，还有相当比例的人很守旧，连隔离见证都不愿意用（或者说，不知道怎么才能启用）。

额，怎么说呢，和绝大多数人脑补的匿名性、不可追踪性什么的，好像不怎么能挂得上边（虽然第(1)点涉及“可互换性”，勉强挂得上边吧）……不知道是不是我了解不到位。而且 taproot 未来还是要通过软分叉实现，换句话说，taproot 本身，相对之前已经存在的 P2PKH 、P2SH 、P2WPKH……这些，就已经是又一个截然不同的、新的地址类型——不同的地址类型其实是对“隐私”/“可互换性”不利的，这恰恰就是 taproot 想要缓解的问题。

taproot 的隐私性，据我所知只体现在两个方面：

(1)公钥里是不是藏了脚本哈希，外界看不出来，公钥和公钥看上去长得都很像，分不清彼此。所以，存在“可互换性”方面的好处。

(2)MAST 里只需要披露被执行的那部分脚本原文，不被执行的就可以不披露，外界只能看到哈希值，看不到原文。

最后，很多时候 taproot 被宣传成“比特币的隐私功能”

如果我没理解错，这其实和很多人预想的不太一样。

到了这里，其实“嵌套多层的脚本哈希”是啥，也许即便我不说，可能你大概也明白了。

因为有神奇的 schnorr 签名加持，在[所有人一个不落下全部都达成一致意见的情况下]，就可以无视当初藏进公钥的那个脚本哈希，不用出示完整的赎回脚本。

如果碰到了需要出示完整赎回脚本的情况呢？

脚本里，其实还可以包含一个公钥，这个公钥乍一看，怎么看都只是个公钥，实际上，它里面藏了一个脚本哈希……

这个脚本哈希呢，在需要出示脚本原文的时候，里面其实还可以包括一个公钥，这个公钥乍一看，怎么看都只是个公钥，实际上，它里面藏了一个脚本哈希……

……

嗯，就是这样，套娃了。
据我所知，（与 Schnorr 签名结合使用的） MAST 就是这么一回事。

而且，很容易想到：
就像代码里的 if then else，两个分支里只有一个会执行，不同条件执行不同的分支；
MAST 也是类似的，而且，你只需要出示被执行的那部分代码，没执行的那部分，你不用出示，然后大家就都只能看到哈希，看不到原文。

19 楼提到的陷阱，是不是在 taproot 里能避免，这个老实说我还不是非常确定，毕竟楼主我是半桶水；但是 taproot 能干啥，我应该还是知道的。


首先复读一下，P2SH 是啥样的？

先登记合同的哈希值（脚本哈希），未来要按照合同内容执行时（把币花出去），再提供完整的合同全文（赎回脚本）。


然后，taproot 又是什么情况？

前文不是提到，公钥里可以藏一个哈希么，很显然，这个哈希可以是脚本哈希啊，于是就可以把 P2SH 的功能包括进来了。

然后，即便是把哈希藏到公钥里，只要交易打包进链，那“合同全文内容”还是固定了，改不了了。

但是，没关系。重点来了——
taproot 的这个公钥，不仅可以藏哈希；归功于 Schnorr 数字签名的神奇数学性质，这个公钥本身，还可以是多个公钥“合体”变成的。

然后，只要合体前的多把私钥全部都签名了，那么就可以无视（作废）掉当初藏进去的那个脚本哈希。

欸，作废了？那还藏这个脚本哈希进去有啥用？
有用啊。
如果多把私钥的主人们并没有全部达成一致意见，出现了争议，那就可以把当初订立的合同（赎回脚本）重新拿出来，对外出示，还是可以按照当初订立的合同来执行。

（这里也存在不少遗憾，比如这个神奇的 Schnorr 签名只能在所有人一个不落下全部都达成一致的情况下才好用；光靠 schnorr 签名本身，并不能实现“少数服从多数”的多重签名；（理论上）顶多只能实现反过来的“多数服从少数”。想要“少数服从多数”，还是得靠脚本）

taproot 本身，就是说，一个公钥（这里需要配合将来要支持的 Schnorr 数字签名，而不是现在用的 ECDSA 数字签名），你看来看去，怎么看，它都只是一个公钥；但实际上，它不止是个公钥，这个公钥里还隐含了一个哈希值。

实际上 P2SH （以及隔离见证改进版的 P2SH，也就是 P2WSH 。P2WSH 也是 bc1 开头，但是比 P2WPKH 更长）用到多重签名上还存在一个陷阱：

如果你把币存到了 2of3 多重签名地址上，但是只备份了其中两把私钥，
那么不好意思，
（如果你把设置好的钱包文件删了）你的币丢了，永久丢失，谁也找不回来。

欸，不是 2of3 么，2 把私钥不是够了么，怎么会找不回来呢？

因为，要从 P2SH 地址里把币花出去，你不仅需要用 2 把私钥签名，还要知道被哈希的那个赎回脚本的完整原文是什么。如果你不知道第三把私钥对应的公钥，那也就等于你不知道赎回脚本。
当初建立多重签名钱包的时候，肯定是三个公钥都参与进来，才得到赎回脚本，然后赎回脚本哈希后就可以得到 3 开头的 P2SH 地址。

很显然，从脚本哈希是不能反推出脚本原文的，包括公钥。
如果你既没有赎回脚本本身，又没有第三把私钥对应的公钥（用这个公钥很显然可以重建赎回脚本），那就回天乏术了。