比特币中TxHash为什么会变化?
一直不理解比特币的Tx在被打包确认之前TxHash为什么会发生变化,这次终于找到了依据.
交易可延展性
虽然交易签名后，签名当前不会覆盖经过哈希处理以创建事务哈希的事务中的所有数据。因此，虽然不常见，但网络上的节点可能会以散列无效的方式更改您发送的事务。请注意，这只会更改哈希值; 交易的输出保持不变，比特币将转到他们的预期收件人。然而，这确实意味着，例如，在任何情况下接受一系列确认块数不够的交易是不安全的，因为后来的交易将取决于先前交易的哈希值，并且这些哈希值可以被更改，直到它们在链上被确认为止。
签名可延展性
可延展性的第一种形式是签名本身。每个签名都只有一个DER编码的ASN.1八位位组表示，但OpenSSL不会强制执行此操作，只要签名没有严重错误，它就会被接受。[1]此外，对于每个ECDSA签名（r，s），签名（r，-s（mod N））是同一消息的有效签名。[2]
从块363724开始，BIP66软分叉使得块链中的所有新事务都必须严格遵循DER编码的ASN.1标准。目前仍在努力关闭DER签名中其他可能的延展性。
任何有权访问相应私钥的人都可以更改签名。 这句话的意思是私钥拥有者对同一笔交易反复签名,他们每次签名都不一样,但是都是有效的.
scriptSig Malleability
比特币中使用的签名算法不会签署全部的scriptSig来创建签名。虽然签署整个scriptSig是不可能的 - 签名本身就是签名 - 这意味着可以添加额外的数据,然后再将所需的签名和公钥推送到栈上。比如可以添加OP_DROP,执行效果和完全没有添加一样。
正在考虑防止scriptSig延展性。当前在其scriptSig中具有除数据推送操作之外的任何操作的事务被认为是非标准的并且不会被广播，并且最终该规则可以扩展为强制执行后堆栈具有恰好一个项目。但这样做可能会影响以后对比特币的扩展。
BIP62
BIP_0062是2014年初提出的比特币改进方案，旨在解决延展性问题。它旨在找到所有可能的延展性方法并逐一修复它们。BIP被撤销，因为发现这对于延展性阻止的用例（例如[闪电网络](https://en.bitcoin.it/wiki/Payment_channels）是不够的4 5 6 BIP文件本身包含作者可以想到的所有延展性方法。
Segwit
隔离见证是对比特币的更新，其目的之一是修复所有形式的可塑性。仅花费segwit输出的交易不易受延展性影响。