Bech32m

この欠陥は限定的ですが実在します。bech32の文字列が文字「p」で終わるときは常に、その最後の文字の直前に「q」を何文字挿入しても、また何文字削除しても、チェックサムは有効なままなので、改変されたアドレスがチェックを通過してしまいます。BIP-350は、bech32が値1を組み合わせていたチェックサムに0x2bc830a3を組み合わせることで、この穴を塞ぎました。

仕組み

Bech32mは、数値を1つ変更したbech32です。エンコーダーは人間が読めるプレフィックスを展開し、データを追加し、その結果に同じBCH多項式を適用します。違いは最後の段階だけにあり、出力は1ではなく0x2bc830a3と組み合わされます。読み手が見ることのできる部分はすべて同じままです。同じ32文字のアルファベット、同じ「1」の区切り、同じ6文字のチェックサム、同じ90文字の上限です。

定数の変更は副作用ではありません。それが仕組みそのものです。2つの方式は一致しないため、bech32mの文字列はbech32のチェックサム検査に失敗し、bech32の文字列はbech32mの検査に失敗します。そのため古いソフトウェアは新しいアドレスを中途半端に理解するのではなく、きっぱりと拒否します。BIP-350はこれを意図的な互換性の断絶と説明しており、bech32をその場で黙って修正する方法ではなくこちらが選ばれました。

線引きはウィットネスバージョンです。ウィットネスバージョン0、つまり単一の鍵とスクリプト用のbc1qアドレスはbech32のままです。ウィットネスバージョン1から16まではbech32mを使用します。今日定義されているのはバージョン1のみで、これはTaprootであるため、実際にはbech32mはbc1pを意味します。この規則はまだ存在しないバージョンも対象とするように書かれたもので、だからこそ正しいウォレットはアドレスのプレフィックスではなくバージョン番号を確認します。

どこで見られるか

bc1pの受取アドレスはbech32mであり、62文字の長さで、32バイトの鍵をエンコードしています。テストネットワークでは、同じ出力がtb1pとして現れます。Taproot出力は2021年11月14日にブロック709,632で使用可能になり、これがbech32mアドレスがメインネットで実際の価値を運び始めた時点です。

Bitcoin Coreはバージョン22.0でBIP-350を実装し、そのリリース以降、アドレスを受け取るすべてのリモートプロシージャコールはウィットネスバージョン1以上に対してbech32mを要求します。バージョン23.0はさらに進みました。新しく作成されたディスクリプターウォレットには自動的にtr()ディスクリプターが付与されるため、要求されなくてもbc1pアドレスを発行します。

実務上の摩擦は出金画面で現れます。一部のプラットフォームは、そのアドレス検証機能がbech32を理解しても新しい定数を理解しないため、いまだにbc1pの宛先を拒否します。その場合でもウォレットに問題はなく、同じシードから生成したbc1qアドレスでもコインは同じウォレットに届きます。

Bech32m vs P2TR

Bech32mはエンコーディングであり、P2TRは出力タイプであり、今日この2つが一致しているのはタイミングの偶然によるものです。Bech32mは、バージョン1以上の任意のウィットネスプログラムをテキストとして書き下す方法を定めます。P2TRはバージョン1のプログラムが何を意味するかを定めます。すなわち、Schnorr署名またはスクリプトの開示によって使用できる、32バイトの調整済み公開鍵です。流通しているすべてのbech32mアドレスはP2TR出力をエンコードしていますが、ウィットネスバージョン2がいずれかに割り当てられた瞬間にそれは成り立たなくなります。そうしたアドレスもbech32mでありながらTaprootではなくなるからです。