Base58 エンコーダー & デコーダー | Bitcoin アドレスとチェックサムを手元で検算
Bitcoin の hex 公開鍵から P2PKH アドレスを組み立てたい、自作スクリプトの Base58Check 実装が合っているか答え合わせしたい、Solana のキーや IPFS CIDv0 を bytes に戻して中身を確認したい——そういうときに使う Base58 専用エンコーダー / デコーダーです。バージョンバイト 5 種 (P2PKH 0x00、P2SH 0x05、WIF 0x80、Testnet P2PKH 0x6f、Testnet P2SH 0xc4) のプリセットと、SHA-256 二重ハッシュ先頭 4 バイトのチェックサム判定をブラウザ内 BigInt + Web Crypto で完結させます。
💡 このツールについて
Base58 は Satoshi が Bitcoin アドレス用に設計した 58 文字アルファベットで、ゼロ 0 と大文字 O、大文字 I と小文字 l のように紙に印刷したときや QR を OCR したときに区別がつかない 4 文字を除外しているのが特徴です。Base64 と違って + / = も含まないため、URL やコマンドライン引数にそのまま渡せます。
Base58Check はこの上に「先頭 1 バイトのバージョンバイト + payload + payload を 2 回 SHA-256 した先頭 4 バイト」というレイアウトで checksum を載せた派生形で、1 文字でもタイプミスがあればデコード時に弾けるよう設計されています。Bitcoin アドレス、WIF 形式の秘密鍵、Solana の公開鍵、IPFS CIDv0、Flickr の写真 ID など、Base58Check は今でも分散システムの「人が手入力できる識別子」として広く使われています。
このツールはエンコード方向で 16 進数のバイト列を受け取り、Base58Check モードならバージョンバイトを指定するだけで checksum 込みの文字列を組み立てます。デコード方向では Base58 文字列を入力すると bytes に戻し、Base58Check モードならバージョンバイト・payload hex・ASCII 表示・checksum 検証結果を分けて出力します。BigInt と Web Crypto を使うため、Python の base58 ライブラリや Go の btcutil/base58 の出力と一致するか手元で突き合わせるのに向いています。
プライバシー: WIF (0x80) で秘密鍵を扱う場合があります。入力した値はサーバーに送信されません。すべてブラウザ内で BigInt 演算と SHA-256 計算が走ります。
🧐 よくある質問
Q. Base58 と Base64 はどう違いますか?
A. Base64 は A-Za-z0-9+/= の 64 文字、Base58 は 0, O, I, l と +, /, = を除いた 58 文字です。Base58 のほうがエンコード後の文字数は約 4 % 長くなりますが、人間が紙や口頭で扱う識別子として誤読しにくく、URL エンコードも不要です。
Q. Base58Check の checksum はどう計算されますか? A. 「バージョンバイト + payload」全体に SHA-256 を 2 回かけ、先頭 4 バイトを取り出して末尾に付けます。デコード側は同じ計算をやり直し、付与されている checksum と一致するかで判定します。1 ビット違っても先頭 4 バイトはほぼ別物になるため、タイプミスの検出に十分です。
Q. バージョンバイト 5 種以外を使いたいのですが?
A. このツールは Bitcoin 系で最も使う 5 プリセットに絞っています。Litecoin (0x30 P2PKH、0x05 / 0x32 P2SH)、Dogecoin (0x1e)、Solana の base58 (Base58Check ではなく生 Base58)、IPFS CIDv0 (Qm 始まり、Base58Check ではなく Multihash) など、生 Base58 として扱えるものは「生 Base58」モードで処理できます。Base58Check のバージョン違いはツール側で対応していないので、Python や JS で b'\x30' + payload + double_sha256(...)[:4] を手書きで組んでから本ツールに貼って検算するのが現実的です。
Q. 「checksum 不一致」と出ましたが、どこが間違っていますか?
A. 典型例は (1) Base58 文字列の途中で 0/O/I/l 系の誤コピペがある、(2) O を 0 に変換するエディタの「全角→半角」自動変換が走っている、(3) そもそもアドレスではなく Multihash や生 Base58 を Base58Check モードで読もうとしている、の 3 つです。デコード結果が「先頭 1 バイト + 4 バイト末尾」の構造になっていなければ Base58Check ではない可能性が高いです。
Q. WIF 形式の秘密鍵をデコードしたら最後の 1 バイトが余分ですが?
A. 圧縮公開鍵対応 WIF (compressed) は末尾に 0x01 が付くため、payload は 33 バイトになります。先頭 32 バイトが秘密鍵、末尾 1 バイトが「圧縮形式」マーカーです。非圧縮 WIF なら payload は 32 バイトです。本ツールの decode 結果の hex の長さで見分けられます。
📚 豆知識
Base58 のアルファベット並び順は 1 から始まりますが、これはアドレスの「先頭ゼロバイトを 1 でパディングする」設計と整合させるためです。Bitcoin アドレスの先頭が 1 で始まる (mainnet P2PKH) のは、バージョンバイトが 0x00 で、その 0x00 1 バイトが Base58 で 1 に化けるからです。3 で始まる P2SH (0x05) や、5 / K / L で始まる WIF (0x80) も同じ仕組みです。
歴史的には Flickr が「短い写真 URL」用に独自の Base58 アルファベットを採用していて、Bitcoin の 123456789ABCDE... 並びとは順序が違います。Solana も Bitcoin と同じ並びを使っていますが、Base58Check ではなく生 Base58 で 32 バイト公開鍵をそのまま表現しているため、本ツールでは「生 Base58」モードで decode すると正しく hex に戻ります。