bech32 エンコーダー / デコーダーとは
bech32 エンコーダー / デコーダーは、生のバイト列と BIP-173 の文字列形式を相互に変換します。この形式は、人間可読部（bc、ltc、lnurl、npub）、区切り文字 1、32 文字のアルファベットで 5 ビットずつ表したペイロード、6 文字の BCH チェックサムから成ります。Bech32m（BIP-350）はチェックサム定数だけが異なる同じ形式で、SegWit バージョン 1 以降（Taproot の bc1p…）で必須です。
具体例
witness プログラム 751e76e8199196d454941c45d1b3a323f1433bd6 をバージョン 0、hrp bc でエンコードすると、BIP-173 のリファレンスアドレス bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 になります。これをデコードするとバージョン 0、20 バイトのプログラム、エンコーディング bech32 が返ります。同じプログラムをバージョン 1 にすると bech32m が必要になり、bc1p で始まります。
bech32 が使われる場所
- Bitcoin: bc1q（P2WPKH、P2WSH）、bc1p（P2TR）、テストネットの tb1、regtest の bcrt1。
- Litecoin: ltc1。その他のチェーン: Cosmos（cosmos1…）、Cardano（addr1…）、Zcash の統合アドレス、Harmony（one1…）は同じ方式を独自のペイロードで使い、長さ制限が緩い場合もあります。
- Lightning: BOLT11 インボイス（lnbc…）は 90 文字制限のない bech32 です。LNURL は URL を hrp lnurl の bech32 で包みます。
- Nostr: npub、nsec、note、nprofile の識別子（NIP-19）。
Bech32 vs. bech32m vs. Base58Check
| エンコーディング | チェックサム | 誤り検出 | 主な用途 |
|---|---|---|---|
| bech32（BIP-173） | 6 文字、定数 1 | 90 文字以内なら最大 4 文字の置換を保証付きで検出 | bc1q SegWit v0、LNURL、Lightning インボイス、npub |
| bech32m（BIP-350） | 6 文字、定数 0x2bc830a3 | 同上。さらに末尾の p の前への挿入に対する弱点を修正 | bc1p Taproot、SegWit v1 以降 |
| Base58Check | ダブル SHA-256 の 4 バイト | 確率的、保証なし | 1… と 3… の Bitcoin、Tron の T…、XRP |
よくある間違い
- 大文字と小文字の混在。
bc1Qw508…は無効です。文字列はすべて小文字かすべて大文字でなければなりません。 - チェックサムの種類の誤り。 バージョン 1 のプログラムを bech32m ではなく bech32 でエンコードすると、ウォレットに拒否される文字列になります。
- 区切り文字の読み違い。 人間可読部の後の
1は区切り文字であってデータではありません。数字の 1 はペイロードのアルファベットには含まれません。 - 5 ビットグループをバイトとして扱う。 デコードしたデータは 5 ビットから 8 ビットに再グループ化する必要があります。SegWit プログラムはパディングビットを捨て、LNURL は厳密なバイト境界を保ちます。
Base58 のレガシー形式を含む Bitcoin アドレス全体の検証は、Bitcoin アドレスバリデーターで行えます。