离线签名btc冷钱包 隔离见证

隔离见证本身与区块大小的话题无关。 “Segregated Witness在一定程度上增加了区块大小”其实是一个副产品，并不是它的主要目的。 但由于区块大小和分叉话题过于激烈，而Segregated verification恰恰是矛盾方极力推动的技术实现，因此被视为增加2MB对应的区块大小的技术实现。 比如我们经常看到有人说“Classic直接升级到2MB，Core升级到最大1.8MB是通过另一种叫做隔离验证的复杂技术”。 事实上，这根本不是一回事。 .

在这里，我必须反复强调这句话“Segregated verification就是隔离验证，它的主要目的和它的字面意思是一样的，就是隔离地做验证，而不是增加区块大小。隔离验证最终可以增加block size.by-products”，记住这句话。 那么，在正式进入隔离验证的讨论之前，我们先来思考一个问题：比特币交易的结构是什么样的？

对此感兴趣的要么是业内人士，要么是比特币爱好者。 大家对比特币交易还是有一些了解的。 很多人可能都读过类似的关于交易结构的文章。 我也浏览了比特币wiki和开发者文档，甚至知道了一些术语如：TxIn、TxOut、OP_CHECKSIG、OP_EQUAL、ScriptSig、ScriptPubKey等，但你真的“懂”比特币交易吗？ 比如比特币交易为什么要这样设计？ 这有什么好？ 怎么了？

我们来看一个具体的比特币交易：

bitcoin-cli getrawtransaction c0a0d0f4de3be3b57f516f127a6fa5d5895f09bfacbb001853593320fb0a4164
0100000001473e2a366b081a0e6645199692ccf2f6e25e4556a18265785a88b46d50fd68c2000000006a4730440220296dd1587b8290a04a9253de431b5dbb698030527df5ca75592ab29eea12e85b0220737cafd85b79a7dea1b29c0a5753432d1dacb50f5225221974e38134617ffc85012103dd38b9b13b24498c382045afb08a4256c3c8bf86e15122df741bd2c2a0bd120fffffffff02a0d21e000000000017a914d1640264c522d9a31aaf69207e57d0a224eb7e668770110100000000001976a914dfd6b01e5ec1ecb1568da79931ddd8327dafd9b588ac00000000
tx_id = tx_hash = c0a0d0f4de3be3b57f516f127a6fa5d5895f09bfacbb001853593320fb0a4164
raw_tx = 0100000001473e2a366b081a0e6645199692ccf2f6e25e4556a18265785a88b46d50fd68c2000000006a4730440220296dd1587b8290a04a9253de431b5dbb698030527df5ca75592ab29eea12e85b0220737cafd85b79a7dea1b29c0a5753432d1dacb50f5225221974e38134617ffc85012103dd38b9b13b24498c382045afb08a4256c3c8bf86e15122df741bd2c2a0bd120fffffffff02a0d21e000000000017a914d1640264c522d9a31aaf69207e57d0a224eb7e668770110100000000001976a914dfd6b01e5ec1ecb1568da79931ddd8327dafd9b588ac00000000
tx_hash = double_sha256(raw_tx)

这实际上是原始格式（十六进制）的比特币交易：rawtx。 这就是比特币网络上传播的那种交易，你发送和接收的比特币交易实际上是这样的。

可能有人会说，不懂。

看不懂吗？ 没关系，要看懂今天的内容，并不需要能够看懂交易格式。

在刚才的交易中，签名是这样的：

30440220296dd1587b8290a04a9253de431b5dbb698030527df5ca75592ab29eea12e85b0220737cafd85b79a7dea1b29c0a5753432d1dacb50f5225221974e38134617ffc8501

那么，你现在可以找一个文本编辑器（记事本之类的），然后在原始交易rawtx中搜索签名，问你一个问题离线签名btc冷钱包，签名出现在交易的什么地方？ 搜索过的人现在应该可以回答了，在中间和前面的位置，也就是说签名在交易里面，基本在内容的前半部分（其实就是TxIn的位置） ).

现在的问题是，为什么签名在这里，在这里有什么好处？

答案是：中本聪是这样设计的，所以签名就在这里。 好吧，实际上没有任何好处。 不但没有好处，反而还有很多坏处。

1、由于这种设计，比特币的交易结构中凭空隐藏了很多“骗局”。 例如：unsigned transactions实际上使用了另外一个内容叫ScriptPubKey，它先占据签名需要的位置，然后对unsigned transaction进行签名，然后替换签名的结果。 这其实是一件很麻烦的事情。 解释清楚不容易，用代码实现也难。 当一笔交易有多个输入（TxIn）时，必然有一套“秘籍”依次准备未签名的交易，依次替换签名； 而当一笔交易涉及多签交易时，则需要另外一套约定好的规则来准备未签名的交易，然后在签名后进行数据替换； 如果交易涉及多个输入和多个签名怎么办？ 那就是金手指套，反正真的很麻烦； 有兴趣有能力的爱好者不妨去翻看比特币协议在各种语言中的实现，你会发现无论是C++、Java、Python等，编写一个比特币协议库通常需要编写大量令人困惑的代码来做上面提到的交易数据构建工作，很头疼，写过的都懂。

2. 将签名放在交易结构中。 由于签名的可塑性，交易也具有可塑性。 例如，由于椭圆曲线的对称性，s和s'都是可以验证的签名。 在这种情况下，任何接收到您广播的交易的节点都有能力将 s 替换为 s'，然后重新广播。 转播的交易其实内容是一样的（输入TxIn和输出TxOut），但是tx_id（tx_hash）不同，从而达到混淆视听的目的，甚至影响一些比特币公司的服务（比如交易所） . 交易延展性不会直接导致您丢币，但会影响个人和企业对比特币交易状况的判断，可能导致资产管理风险。 之前bitcoin-core为解决BIP62中的交易延展性问题做了一些尝试，但从某种意义上说，交易延展性并不能完全治愈，至少私钥的拥有者可以重新生成一个签名，交易保持不变但签名改变了，最终的 tx_id 也改变了。 这种情况应用于多重签名的场合，甚至可能会影响其他关键持有人对交易的判断，导致一些潜在的资产风险。 在目前的交易结构下，我们无法完全避免这种情况的发生；

3、当我们需要对交易进行签名时，对每个TxIn进行签名的hash是不同的（见上面的“秘籍”），所以“冷钱包”等离线签名的实现其实增加了很多难度离线签名btc冷钱包，无论是数据结构或代码级别；

也就是说，将签名放在交易内容中其实没有任何好处，反而增加了结构的复杂性和交易延展性的风险，显然得不偿失。 那么，最合理的交易结构应该是什么样的呢？ 其实很简单：

TxIns + TxOuts + [签名]

也就是说，把签名单独拿出来放在外面，就可以解决上述所有问题。 这让我回到了我正在谈论的标题 - “隔离见证”。 隔离验证实际上是将原始比特币交易中已签名的部分取出，放入另一个称为witness的结构中，以达到既定目的。 看到这里，大家也就明白了。 通常，看似复杂的题目“隔离验证”的基本原理其实并不复杂。 要达到的目的其实很简单，就是把签名取出来放到另一个地方，所谓“隔离”，就是这么简单。

签名是用来“验证”的数据，是要“隔离”在另一个地方的，所以把这件事命名为“隔离验证”是合理的。 通过上面的描述，大家应该能明白隔离验证的好处了，它的好处确实是巨大的：交易就是交易，签名就是签名。 对于交易，我们只关心 TxIn 和 TxOut。 我们都知道比特Token交易实际上是花费了之前收到的一笔钱，也就是说，将之前收到的TxOut作为本次交易的TxIn，然后发送给后续的TxOut。 隔离后的交易结构，让你更容易决定花哪一笔 当这笔钱给谁时，交易的内容已经确定，交易的数据不会改变，最终的tx_id依然存在不变。 想要验证签名？ 然后去witness找对应的签名数据验证合法性。 很简单，不存在事务可扩展性的问题。 用coder的语言来说，那真是“不要太cool”！

众所周知，我们的比太钱包提供了一个易于使用且安全的冷钱包解决方案。 对于我们来说，当然希望在离线签名的过程中，冷私钥需要签名的hash是准确的，而不是变化的。 其实这也是隔离验证的好处之一。 另外，有人问隔离验证对闪电网络有没有好处？ 隔离验证有利于所有基于比特币区块链的扩展应用（甚至交易所和钱包等）。 准确的tx_id当然会让很多基于tx_id的扩展应用变得更加容易和可靠。 .

所谓的隔离验证，其实并不是为了解决区块大小的问题，也不是像某些人所说的“Core团队中BlockStream的几位核心开发者为了防止扩容而采取的改变阴谋”，而是比特币交易本应如此，隔离验证的结构改进，如压缩格式的公钥，属于由于初始结构设计不合理而需要改进的内容，换言之，比特币交易应具有本来就是“隔离验证”的，但是像现在这样最初是中本聪设计的，所以一直保留到现在，也许今天就不会有那么多的争议了。比特币程序员也可以节省很多脑细胞去做更有意义的事情，而不是纠结于交易结构，各种比特币公司也可以减少一些交易延展性的困扰。

Segregated Witness 的改进应该怎么做？

出于向后兼容和兼容各种客户端旧版本的考虑，开发者希望尽可能采用“软分叉”的方式来实现。 为了实现这一点，总共有 4 个相关的 bips (141-144)。

众所周知，对于任何计算机系统来说，设计一个新的结构很容易，但要实现向后兼容就困难得多。 如果要让新旧结构共存，旧版本能够正常运行，那肯定是比较困难的，尤其是当我们考虑到这些新旧结构的数据仍然在同一个区块链上传输时，需要付出更多的努力是必须的。 这些部分在几个bip中都有详细的描述，有兴趣的可以进一步阅读相关技术文档：

例如：

bip141详细描述了一种名为“witness”的新结构，并将脚本、签名等数据移至该新结构中，并介绍了如何实现隔离验证的向后兼容；

bip142 描述了 segwit 的新地址格式；

bip143举例说明了隔离验证交易签名的验证方法；

bip144 描述了如何在保持向后兼容性的同时通知节点之间隔离验证的支持以及传播和请求验证数据的方式；

好了，通过这些内容的描述，大家应该能够大致了解Segregated Witness是怎么回事了。 Segregated Witness本身与区块大小无关，只是因为验证数据是兼容的，所以放在另一个空间。 ，同时修改了出块上限的计算方式，让Segregated Witness本身在一定程度上起到扩容的作用，以至于大家把它当成另一种扩容方案，反观其2MB方案。

最后总结一下，Segregated Witness其实是对之前不合理的比特币交易结构的一种优化。 开发人员正在尝试使用“软分叉”的方法，尽可能减少影响并尽可能向后兼容。 为实现这一点，改进本身（如“压缩公钥”）是非常合理的，与块大小争论没有直接关系。 如果Segregated Witness软分叉上线，我们可能会看到新旧版本的交易在比特币网络上共存相当长的时间，就像直到今天，还有人在使用5.key开头的私密交易（而不是以 K 和 L 开头的私钥的压缩版本）。

隔离见证带来的区块大小增加只是一个副产品。 块大小是否应该增加以及应该如何增加实际上是另一个话题。 这就需要各方充分讨论，尽可能客观公正地听取对方的意见。 我自己不会对区块大小的争论发表任何评论。 至于如何管理比特币代码的问题，这是一个治理问题，是一个政治问题，不在本次公开课的讨论范围之内。

隔离验证是应该进行的改进。 因为夹杂着区块大小的争议，很多人看“隔离验证”的时候都带有很多感情色彩。 个人建议，隔离验证就是隔离验证。 要想做到向下兼容、软分叉不出问题，需要核心开发者、产业链上下游相关企业、比特币钱包开发者的共同努力。 , 以确保此改进的安全性。 如果非要问我隔离验证方案有没有风险，我觉得最大的风险就是大家被迫说“你们的隔离验证方案什么时候可以用？2MB但是下个月就会分叉”，逼迫核心开发者急于达到增加区块大小的目的，得不偿失。 隔离验证的升级还是需要全面测试的，相关公司和软件方案也要尽可能全面的测试兼容性。 然后再上网。