BIP 62（“處理延展性”）實施了多少？
BIP 62列出了九個延展性來源：
- 非 DER 編碼的 ECDSA 簽名
- scriptSig 中的非推送操作
- 非標準大小類型的scriptSig中的推送操作
- 零填充數字推送
- 固有的 ECDSA 簽名延展性
- 多餘的 scriptSig 操作
- 腳本忽略的輸入
- 基於 Sighash 標誌的遮罩
- 發件人的新簽名
…並提出新的規則來解決前七個問題。在比特幣核心中實施了多少這些修復？
大多數修復已在比特幣核心的主分支或更早版本中實施，作為標準交易檢查，防止預設比特幣核心節點中繼或探勘違反規則的交易。以下是一些細節：
- 非 DER 編碼的 ECDSA 簽名
這些目前是非標準的，因此預設情況下比特幣核心節點（自 0.8.0，IIRC）不會中繼或探勘它們。當BIP66軟分叉成功並且第 3 版塊成為強制性時，此規則將在所有已確認的交易上執行。
- scriptSig 中的非推送操作
這些目前也是非標準的，並且完全禁止用於花費 P2SH 輸出的簽名腳本。我不知道它們是什麼時候第一次成為非標準的，但我懷疑它是 0.8 或更早。
- 非標準大小類型的scriptSig中的推送操作
這些在0.9.0中是非標準的，它們被稱為“非規範編碼的序列化大小”。
- 零填充數字推送
- 固有的 ECDSA 簽名延展性
這是目前允許的，並且一些流行的比特幣程序仍然可以創建全範圍簽名。在實施 BIP62 之前讓這些程序更新為僅使用低 S 值會很好，但這並不重要，因為新的 BIP62 驗證規則將僅適用於版本 2 事務。即使在軟分叉之後，仍然允許不更新的程序創建版本 1 事務。
使用 v2 交易的程序的優勢在於它們通常可以被第三方建構為不可延展的，因此 v2 交易可以更安全地用於應用程序，例如建立小額支付渠道的初始債券部分。
*編輯：*本節的早期版本錯誤地表示讓程序僅創建低 S 簽名至關重要。感謝@PieterWuille 下面的評論指出我的錯誤。
- 多餘的 scriptSig 操作
自 0.6.0 以來非標準。在 master 中，此測試已移至此處。
- 腳本忽略的輸入
這部分在 0.10.0 中得到解決，但請參閱下面的註釋。
- 基於 Sighash 標誌的遮罩
- 發件人的新簽名
根據BIP62，“前六個和第七個的部分可以通過額外的共識規則來修復，但後兩個不能。無法修復 #7 意味著即使使用這些新的共識規則，也總是可以創造出其支出交易都具有延展性的產出。”
簡而言之，規則 7 沒有完整的解決方案，規則 8 和 9 也沒有任何解決方案。（實際上，8 的延展性是一個特性，修復 9 需要不同的簽名方案。）