acess
2021-04-22 04:00:41 +08:00
19 楼提到的陷阱,是不是在 taproot 里能避免,这个老实说我还不是非常确定,毕竟楼主我是半桶水;但是 taproot 能干啥,我应该还是知道的。
首先复读一下,P2SH 是啥样的?
先登记合同的哈希值(脚本哈希),未来要按照合同内容执行时(把币花出去),再提供完整的合同全文(赎回脚本)。
然后,taproot 又是什么情况?
前文不是提到,公钥里可以藏一个哈希么,很显然,这个哈希可以是脚本哈希啊,于是就可以把 P2SH 的功能包括进来了。
然后,即便是把哈希藏到公钥里,只要交易打包进链,那“合同全文内容”还是固定了,改不了了。
但是,没关系。重点来了——
taproot 的这个公钥,不仅可以藏哈希;归功于 Schnorr 数字签名的神奇数学性质,这个公钥本身,还可以是多个公钥“合体”变成的。
然后,只要合体前的多把私钥全部都签名了,那么就可以无视(作废)掉当初藏进去的那个脚本哈希。
欸,作废了?那还藏这个脚本哈希进去有啥用?
有用啊。
如果多把私钥的主人们并没有全部达成一致意见,出现了争议,那就可以把当初订立的合同(赎回脚本)重新拿出来,对外出示,还是可以按照当初订立的合同来执行。
(这里也存在不少遗憾,比如这个神奇的 Schnorr 签名只能在所有人一个不落下全部都达成一致的情况下才好用;光靠 schnorr 签名本身,并不能实现“少数服从多数”的多重签名;(理论上)顶多只能实现反过来的“多数服从少数”。想要“少数服从多数”,还是得靠脚本)