更新後的 bech32m 解決了哪些與 bech32 地址相關的問題？
更新後的bech32m解決了哪些與bech32地址相關的問題？
我知道原始 bech32 存在一個問題，即長度擴展突變弱點，但我不知道是否還有其他問題。
據我所知，“長度擴展突變弱點”是唯一需要解決的問題，由 bech32m 解決。但“長度延伸突變弱點”包括插入和刪除。
插入：如果一個有效的 Bech32 字元串有後綴 p，在 p 之前插入一個 q 字元將產生另一個有效的 Bech32 字元串。
刪除：如果一個有效的 Bech32 字元串有後綴 qp，刪除 q 字元將產生另一個有效的 Bech32 字元串。
除了“最終 p 之前的 q”之外，還有更複雜的插入和刪除是可能的（參見底部的 Pieter 評論），儘管到目前為止我還沒有在任何地方發現這一點。
為了解決這個問題，設計了一個新的校驗和算法：
用 0x2bc830a3 替換最後異或到校驗和中的常數 1
Bech32m 編碼將僅用於 SegWit 輸出版本 1 及更高版本。版本 0 將繼續使用 bech32，因為長度擴展突變弱點不會對版本 0 造成問題，因為 SegWit v0 地址被限制為兩個特定長度（目前沒有對更高版本的 SegWit 版本地址施加這樣的長度限制。）它們被定義為只能是 42 個字元 (P2WPKH) 或 62 個字元 (P2WSH)。儘管從技術上講，您可以插入 20 個 q 字元來生成具有來自 P2WPKH 地址的有效校驗和的 P2WSH 地址，但校驗和並非旨在防止對抗性情況或插入這麼大。校驗和的目標是防止拼寫錯誤、複製粘貼錯誤、轉錄錯誤、錯誤被作為口語轉發。
Pieter 在GitHub 上添加：
我認為讓多個地址對同一個 scriptPubKey 有效是個壞主意。當解碼/重新編碼不往返時，它只會導致混亂。v0 輸出使用 bech32，我認為這不會改變，無論好壞。它還將錯誤檢測惡化到 29 位（因為每個 v0 輸出現在都有兩個有效校驗和）。
一旦你提出了兩種不同的編碼方案（bech32 和現在的 bech32m），這對錢包提出了一個挑戰，即知道使用哪種編碼，因此 bech32m 草案 BIP 決定使兩者完全不兼容，即不可能將 bech32m 地址作為有效的 bech32 地址，反之亦然。
感謝 Pieter Wuille 和 Russell O’Connor 對原始文章的一些更正。