ムラゴン ホーム
Segwitに関して調べた記録6
前回の続き
Segwitで採用される新しいアドレスフォーマット（はじめに）
その送金先がSegwitアドレスであることを示す為のアドレスフォーマットについてここでは書く。
Segwitのアドレスフォーマットは元々BIP-142に定められていたのだが、後にそれを上書きするものとして、BIP-173が提案された。
BIPは提案なので、実際にBitcoinがSegwitを導入できていない今、BIP-142とBIP-173のどちらが採用されることになるかは、正直わからないのだが、先にSegwitを導入しているLitecoinを見るに、BIP-173が採用される確率が高いと思うので、BIP-173について書く。
LitecoinではBIP-173の導入を決定しているようで、次の大きなバージョンアップの時に導入するとかしないとか（現時点で導入はされていない）
https://github.com/litecoin-project/litecoin/issues/312
（何かその辺りの会話してるね・・・）
BIP-173
GithubにアップされたBIP-173はこちら
BIP-173はSegwitのアドレスフォーマットを定めたもので、大まかな流れは以下のとおりである
- witnessProgramにhuman-readable partと呼ばれるデータを付ける
- 1のデータに間違い検証用のデータである"チェックサム"を付ける
- 2のデータ部分をBIP-173で定められた方法で32文字を使用したデータにエンコードする
では、まず最初にBech32から説明していく。
Bech32
BIP-173では、Base58を用いたレガシーなアドレスエンコードに対して、Bech32と呼ばれるエンコードを提案している。
このBech32は、「human-readable part（人が読む部分）」と「data part（データ部分）」とに分かれており、それらを区切るものとして「separator（セパレーター）」と呼ばれる特定の文字を使用する。
各パートの意味するところは上記図を見て欲しい。セパレーターは「1」で固定されており、もし、human-readable partに1が複数回出てくる場合は、その一番後ろのものをセパレーターと認識する。（Bech32エンコード後のdata partには1は使われない）
data part（以下 "データ部分"）はバイナリデータをBech32で定められる32文字のデータでエンコードされる。
ここで注意しておきたいのが、Bech32に使われる文字表は通常のBase32と文字の並びが違うということだ。実際にはBIP-173にかかれている表を見て欲しいが、通常のBase32が「a,b,c...」と始まるところを「q,p,z...」となっている。
BIP-173より引用
都合上表にしているだけで、単に連なった32文字だと思えば良い。（q,p,z...x,8,g,f...）
次に、チェックサムについて説明をする。
チェックサム
チェックサムはデータ部分に含まれる。
チェックサムは、下記Pythonで書かれたコードの「bech32_verify_checksum」メソッドがtrueを返すことでその検証が成功したものとみなす。
BIP-173より引用
生成に関しては、下記Pythonのコードに従って生成を行う。
BIP-173より引用
この辺りのプロセスは実際にコードを読んでその手順を追って欲しい。
BIP-173にもその説明が簡単にされているが、この計算は「BCH符号」と呼ばれるデータの符号化の計算として最も研究がされているものの一つを利用した計算のようだ。
Sgwitのアドレスフォーマット
以上を踏まえて、Segwitのアドレスフォーマットに関わる規則は下記のとおりとなっている。
■human-readable part
各通貨に依る（Bitcoinであればbc,Litecoinであればltcなど）
■data part
1文字目はwitnessVersionになる。
（version0だと上記で引用した表より"q"となる）
残りのwitnessProgramとチェックサムの部分は0と1のバイナリデータとして見て5bit毎に区切り（端数はパディングする）、それらを表に記された32個の文字に当てはめていく。
（2の5乗は32なので、5bit毎に区切れば32個の文字列に当てはめることが出来る）
BIP-173のサンプルを見ると分かるが、例えば"Bitcoin(mainnet)"の"version0"の"WitnessProgram"のアドレスは、必ず「bc1q」から始まる。この時、"bc"がhuman-readable partで"1"がseparator、"q"がversion0の"0"を示している。この後に、witnessProgramとチェックサムを32文字でエンコードした文字が続く。
このパートの最後に
以上がBIP-173で定められた新しいアドレスフォーマットの詳細になる。正直、実際に自分で実装してみないと分からないと思う。サンプルもあるので実際に自分で生成したほうが良いと思う。また、実装しているうちに新たにわからないところが出てくると思う。（私はそもそもBCH符号化の操作に関してその根拠がよく分かっていない）
なんだか良く分からないチェックサムの計算だが、SHA-256doubleHashしたデータの頭4byteを抜き出すよりは素早く、より厳密に間違い検証が出来るようだ。
また、定義が曖昧になってしまったがBech32は表で指定された32文字を用いたデータのエンコードそのものを指すのではなく、チェックサムの計算方法やアドレスフォーマットなど、BIP-173で定められた全ての操作をまとめてBech32と呼ぶようなので、注意して欲しい。
最後に（全体的に）
今回を含む全6回分の記事に書いてあることがSegwitについて私が調べたことだ。なので今回でおわり。
正直後半は息切れしながら書いたので説明が雑になってしまったがまぁ仕方ない。
