BitcoinのSegWitアドレスフォーマットBech32のデータ構造について

Bitcoin Bech32 address format




Bitcoinは2017年8月にSegWitがアクティベートされました。SegWitはBIP141で定義されています。

 

SegWitに対応したアドレスの初期フォーマットはBIP142で定義されていたのもでしたが、BIP173が新仕様として採用されています。これがBech32フォーマットです。

 

そもそもSegWitとは

SegWit導入前の問題点

SegWit導入以前のトランザクションはトランザクション展性(マリアビリティ)があるため問題がありました。

 

マリアビリティはトランザクションに含める署名データを署名検証が通るものに変更することでトランザクションIDが変更される問題です。

 

この問題を解決するために、SegWitはトランザクションインプット(txins)に含まれる署名データを新たに作ったwitness部分に移し、署名部分は改ざんされないように常に空にします。txidはwitness部分を使わない以前と同じ方法で導出するので改ざんされなくなります。

 

詳細なSegWitの説明は下記スライドを見るのが一番理解が早いのでおすすめです。

 

SegWitは何を解決するのか

上記で説明したマリアビリティの他に、1ブロック当たりに含められるトランザクション数の増加、未署名トランザクションが作れることによるLightningNetworkの実現が可能になりました。

 

SegWit導入前はブロックのデータサイズが1MBまでしかはいりませんでしたが、SegWit導入後はブロックサイズではなくBlock Wightというものが導入されました。

 

BlockWeightの計算式は(Witness部分を含まないトランザクション×3) + Witnessを含むトータルのブロックサイズとなりました。これによりWitnessに署名を移すSegWitはトランザクションあたりのweightを抑えてBlock Wightを小さくすることができます。

 

これはなぞなんですが、最終的なブロックサイズって変わらないんじゃなかと思ったりしてるんですが、Block Weightを基準に考えることでブロックサイズを削減できる理由を説明できる方がいたら教えていただきたいです。

 

Bech32のフォーマット

本題のBech32ですが、フォーマットの構成はシンプルで下記二つに分けられます。この二つはアドレス内の最後に現れた1をセパレータとして2つに分けます。

  • Human Readable Part:mainnetはbc、testnetはtb固定
  • Data Part:1文字目がwitness version、最後の6文字がchecksum、それ以外がwitness programといいBIP141で定義されています。

 

bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 ← このアドレスを例にするとbcがHuman Readable Part、qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4がData Partです。

 

さらにqがwitness version、w508d6qejxtdg4y5r3zarvary0c5xw7kがwitness program、v8f3t4がchecksumになります。

 

エンコード、デコード、checksumの計算方法は後日まとめたいと思います。

The following two tabs change content below.

髙妻智一

2013年CyberAgent新卒入社 スマホゲームを作る子会社に所属し、サーバーサイドのエンジニアを担当。2年目の終わりから新規子会社の立ち上げに参加し、サーバーサイドのエンジニアリーダーとしてサービースのリリースから運用までを担当。 2018年仮想通貨のスマホウォレットを提供するGinco Incにブロックチェーンエンジニアとして入社。






よく読まれている関連記事はこちら



コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です