Bitcoin: bip143

比特币脚本有4个验证签名 操作码:

CHECKSIGC
CHECKSIGVERIFY
CHECKMULTISIG
CHECKMULTISIGVERIFY

at least 2 weaknesses in the original SignatureHash transaction digest algorithm

在原来的hash数字摘要签名算法中, 至少有2个弱点:

For the verification of each signature, the amount of data hashing is proportional to the size of the transaction. Therefore, data hashing grows in O(n2) as the number of sigops in a transaction increases. While a 1 MB block would normally take 2 seconds to verify with an average computer in 2015, a 1MB transaction with 5569 sigops may take 25 seconds to verify. This could be fixed by optimizing the digest algorithm by introducing some reusable “midstate”, so the time complexity becomes O(n).

验证每笔交易, hash数据量跟交易数据成正比. 因此, hash数据的增长是 O(n2)级别, 相对于签名数据的增长.
1MB的 block 在一个2015年 平均水平的电脑上通常要花2 秒验证. 5569 sigops个 1MB的交易 要花25秒验证.
可以通过引入一些可重用的midstate 去优化摘要算法, 时间复杂度变成 O(n).

The algorithm does not involve the amount of Bitcoin being spent by the input. This is usually not a problem for online network nodes as they could request for the specified transaction to acquire the output value. For an offline transaction signing device ("cold wallet"), however, the unknowing of input amount makes it impossible to calculate the exact amount being spent and the transaction fee. To cope with this problem a cold wallet must also acquire the full transaction being spent, which could be a big obstacle in the implementation of lightweight, air-gapped wallet. By including the input value of part of the transaction digest, a cold wallet may safely sign a transaction by learning the value from an untrusted source. In the case that a wrong value is provided and signed, the signature would be invalid and no funding might be lost.

这个算法不涉及比通过特币输入被花费的数量. 这通常不是个问题对于线上网络节点, 他们能请求特殊的交易
获得输出的数量. 对于线下交易签名设备(冷钱包), 不知道输入的数量,无法计算花费的数量和交易费用.
为处理这个问题, 冷钱包必须获取花费的所有交易, 这将成为一个大障碍在实现 lightweight, air-gapped 钱包上. 包括输入值的交易的一部分digest, 一个冷钱包可能安全的签名一个交易, 通过学习 value从一个不受信任的源. 在这种情况下 一个错误的值被提供和签名, 这个签名将是无效的也没有资金, 可能会丢失.

Deploying the aforementioned fixes in the original script system is not a simple task. That would be either a hardfork, or a softfork for new sigops without the ability to remove or insert stack items. However, the introduction of segregated witness softfork offers an opportunity to define a different set of script semantics without disrupting the original system, as the unupgraded nodes would always consider such a transaction output is spendable by arbitrary signature or no signature at all.

部署上文中的修改在原始脚本系统中不是一个简单的任务. 这将硬分叉或软分叉对于新的 sigops,不能删除或插入栈内容的 sigops. 然而, 引入隔离见证软分叉 提供了一个机会, 去定义语义不同的脚本在不影响原系统的情况下, 随着unupgraded节点总是考虑这样一个由可使用的签名或没有签名构成的任意输出的交易.

Specification 规范

A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program:

定义一个新的交易摘要算法,但只适用于 sigops in version 0 witness program:

  Double SHA256 of the serialization of:
     1. nVersion of the transaction (4-byte little endian)
     2. hashPrevouts (32-byte hash)
     3. hashSequence (32-byte hash)
     4. outpoint (32-byte hash + 4-byte little endian) 
     5. scriptCode of the input (serialized as scripts inside CTxOuts)
     6. value of the output spent by this input (8-byte little endian)
     7. nSequence of the input (4-byte little endian)
     8. hashOutputs (32-byte hash)
     9. nLocktime of the transaction (4-byte little endian)
    10. sighash type of the signature (4-byte little endian)

Semantics of the original sighash types remain unchanged, except the followings:

原sighash类型的语义保持不变,除了以下:

1. The way of serialization is changed;

2. All sighash types commit to the amount being spent by the signed input;

3. FindAndDelete of the signature is not applied to the scriptCode;

4. OP_CODESEPARATOR(s) after the last executed OP_CODESEPARATOR are not removed from the scriptCode (the last executed OP_CODESEPARATOR and any script before it are always removed);

5. SINGLE does not commit to the input index. When ANYONECANPAY is not set, the semantics are unchanged since hashPrevouts and outpoint together implictly commit to the input index. When SINGLE is used with ANYONECANPAY, omission of the index commitment allows permutation of the input-output pairs, as long as each pair is located at an equivalent index.

1. 序列化方式改变;

2. 所有sighash类型提交 �被花费的(被签名的输入)总额 ;

3. FindAndDelete 签名不在用于scriptCode;

4. OP_CODESEPARATOR(s)后执行OP_CODESEPARATOR不删除scriptCode(最后执行 OP_CODESEPARATOR和任何脚本 在ta总是删除之前);

5. SINGLE 不提交 input index. 当 ANYONECANPAY没有设置时,
   语义不改变, 自从 hashPrevouts 和 outpoint 一起隐式提交到 input index.
   当 SINGLE ANYONECANPAY 一起使用, 缺失索引承诺允许置换输入-输出对,只要每个对 位于 一个等价的索引.

尼玛 会说人话么

---

参考:

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki
https://en.bitcoin.it/wiki/Script
https://bitcoin.stackexchange.com/questions/50590/how-to-compute-double-sha256-shown-in-examples-of-bip-143