【後編】試験に出る!最重要 BIP 10 選

こんにちは。フレセッツ株式会社の日向(ひゅうが)です。

花粉症があまりにもつらすぎるので医者に「めっちゃ強い薬オネシャス!!!」と言ったら花粉症の症状がピタッと止まりなかなか快適に生活できています。
ただ目がちょっと痒いくて痛いので、完全に克服できたわけではありませんが。あと薬価がめちゃ高かった……。

近況報告はこのくらいにしておいて、前回(【前編】試験に出る!最重要 BIP 10 選)に引き続き暗号資産やブロックチェーンを学ぶ上で欠かすことの出来ない BIP (Bitcoin Improvement Proposal) を紹介していきます。

BIP 44: Multi-Account Hierarchy for Deterministic Wallets

前編の記事で「BIP32: Hierarchical Deterministic Wallets」(通称: HD ウォレット) を紹介しました。
この仕様を用いると、たった一つのマスター鍵から階層的かつ決定論的に無数の鍵ペア(アドレス)を作成することができます。しかしながら BIP 32 ではその階層構造の使い方までは言及しておらず、異なる実装のウォレット間で互換性を持った形で HD ウォレットを利用できるようにするためには、その階層構造についても何らかのルールを設ける必要があります。
本 BIP では、HD ウォレットを利用する際に推奨される、階層構造を規定しています。

実際の階層構造は以下のようになっております。
ここでアポストロフィ (‘) の付いているものは hardened 鍵、何も付いていないものは non-hardened (normal) 鍵を表しています。

m / purpose’ / coin_type’ / account’ / change / address_index

各階層の内容は以下のとおりです。

  • purpose’ …… BIP 43 で規定されている「目的」フィールドであり、これ以下の階層をどのように利用するのかを指定するフィールドになっています。
    アサインされている BIP 番号である 44 番をもとに、常に purpose’ = 44' を利用することとなっています。
  • coin_type’ …… 利用するコインの種類(ビットコイン、モナーコイン、ライトコイン、テストネットビットコイン、など)を指定します。
    ビットコインの場合には 0' を、テストネットビットコインの場合には 1' を指定するよう規定されています。
    それ以外のコインの coin_type’ 値については「SLIP-0044 : Registered coin types for BIP-0044」で規定されています。
  • account’ …… この番号を変えることで、ひとつのマスター鍵から複数の独立したアカウント(ウォレット)を使えるようになります。
    例えば 0' 番目のアカウントを普段使い用とし、1' 番目のアカウントは会社用、2' 番目のアカウントは長期保管用……といった具合に使い分けることができます。
  • change …… 0 番から派生するアドレスは外部利用(入金)用、1 番から派生するアドレスは内部利用(おつり)用として利用します。
  • address_index …… 最終階層である address_index では、0 番から順番にアドレスを作っていきます。

BIP 45: Structure for Deterministic P2SH Multisignature Wallets

BIP 44 ではシングルシグアドレスの階層構造を規定していますが、こちらの BIP 45 ではマルチシグアドレスを利用する際の階層構造を規定しています。

m / purpose’ / cosigner_index / change / address_index
  • purpose’ …… BIP 44 と同じで、必ず固定値 45' を利用します。
  • cosigner_index …… 複数いるマルチシグの参加者のうち、何番目の参加者であるのかを規定します。
    番号は m / purpose’ から導出される公開鍵を辞書順に並べてアサインします。
  • change …… これも BIP 44 と同じで、0 番を外部利用(入金)用、1 番を内部利用(おつり)用とします。
  • address_index …… アドレスの番号を指定します。

マルチシグは個人ではなかなか利用しませんし、対応しているウォレットもほとんどありませんので、BIP 44 と比べると利用頻度は低いですが、一応把握しておくとよいでしょう。

BIP 141: Segregated Witness

Segregated Witness (SegWit)

トランザクションの中身を大きく分けると、誰から誰にいくらのビットコインを送ったかという送金に関する指示データと、その指示を本人が行ったことを証明する電子署名データに大別することができます。
前者のデータは各アドレスの残高を計算したりするのに必要ですが、後者のデータはブロックチェーンを同期する際に一度だけ参照すればいいものに過ぎず、利用頻度は非常に低いです。
そこで後者のデータをトランザクション本体から分離し、「witness」と呼ばれる領域に分離 (segregate) しましょう、というのがこの BIP の趣旨となります。
なお segregated witness は省略して SegWit (セグウィット) と言ったりします。

ビットコインの利用している ECDSA 署名は、署名として有効となるデータが一つに定まらないため、この電子署名部分のデータを差し替えることでトランザクションの意味論的な内容を変えずに、バイト列だけを変えることができてしまいます。
そうすると一度送ったトランザクションがブロックチェーンに取り込まれる頃には(バイト列として)違うデータになってしまい、様々な問題を引き起こすことが知られています。
このことはトランザクション展性 (malleability) と呼ばれていますが、SegWit を用いると電子署名データをトランザクション本体から分離できるため、実質的にこのトランザクション展性の問題を排除できると考えられます。

SegWit アドレスは大きく分けると 4 種類存在します。

  1. P2WPKH
  2. P2WSH
  3. P2WPKH nested in P2SH
  4. P2WSH nested in P2SH

1, 3 の P2WPKH (Pay-to-Witness-PubKey-Hash) は従来の P2PKH (Pay-to-PubKey-Hash) に対応するアドレスであり、通常のシングルシグアドレスがこれに当たります。
2, 4 の P2WSH (Pay-to-Witness-Script-Hash) については従来の P2SH (Pay-to-Script-Hash) に対応するアドレスであり、マルチシグなどで利用されているアドレス形式となります。

3, 4 については従来から用いられているマルチシグなどで利用するアドレス形態を利用するため、SegWit に対応していない古いウォレットでも扱うことができるという利点があります。
一方 1, 2 については Bech32 と呼ばれる新しいアドレスのエンコーディング方式が採用されており、SegWit に対応したウォレットでしか送金することができません。

BIP 173: Base32 address format for native v0–16 witness outputs

ビットコインの旧来のアドレス形式は Base58check といわれるエンコーディング方式を利用しています。
これは 58 種の英数字からなる文字列の組み合わせからなる SHA-256 ハッシュ値によるチェックサムが付加されたものです。
このエンコーディング形式にはいくつかの問題点が知られており、例えば QR コードにした際に英数字 (alphanumeric) モードを利用できないため QR コードが大きくなる、大文字小文字が入れ混じっているため音声によるアドレスの伝達が困難、処理が必要以上に複雑で計算に時間がかかる、などが挙げられます。

この BIP では新しいアドレスエンコード形式として Bech32 というものを定義しており、(native) SegWit アドレスや Lightning Network のインボイスデータのエンコード形式として採用されています。

Bech32 アドレス文字列は大きく分けると以下の 3 つに分けることができます。

  • 可読パート (human-readable part; HRP) …… アドレスが指し示す内容の種類を識別するための文字列です。例えばメインネットのビットコインでは「bc」、テストネットでは「tb」、Lightning Network のインボイスでは「lnbc」などです。
  • セパレータ …… データを区切るためのものです。常に「1」を利用します。
  • データパート …… 実際のデータにチェックサムを付加したもの。

チェックサムには BCH 符号と呼ばれるエラー検出符号が利用されており、エラー検出確率などが数学的にはっきりと知ることができる(従来の SHA-256 ハッシュサムを利用する方式では非常に低い確率ではありますが、ワンチャン間違ったアドレスでもチェックサムのテストに合格する可能性がありました)というのが大きな特徴となっています。

BIP 174: Partially Signed Bitcoin Transaction Format

入力が複数あるトランザクションやマルチシグアドレスを含むトランザクションなど、一つのトランザクションを送るのに複数人の電子署名が必要な場合、未署名トランザクションを作成し、一人目の署名者は一部のみ署名された (partially signed) トランザクションを作成して二人目の署名者に渡すことが必要になります。
今までは、一部のみ署名されたトランザクションを表す方法には統一的な方法がなく、各ウォレットが独自にプロトコルを定めやり取りしていました。
そのため署名者全体でウォレットソフトウェアを統一する必要があり、署名者ごとの好みや事情に合わせてウォレットを選択することができませんでした。

この BIP (Partially Signed Bitcoin Transaction; PSBT) では、一部のみ署名されたトランザクションのデータ形式を定めており、この仕様に従うことでウォレットの種類を気にすることなく統一的にデータを取り扱うことができます。
PSBT は key-value のペアを複数個連結したようなフォーマットとなっており、比較的柔軟にトランザクションのデータを指定することができます。


以上で、著者が重要と考える 10 個の BIP (Bitcoin Improvement Proposal) を紹介しました。
どれもビットコインや暗号資産、ブロックチェーンを扱う際に必要となる可能性の高い仕様となりますので、ぜひこの機会に抑えておきましょう!


お知らせ

■HashHubでは入居者募集中です!
HashHubは、ブロックチェーン業界で働いている人のためのコワーキングスペースを運営しています。ご利用をご検討の方は、下記のWEBサイトからお問い合わせください。また、最新情報はTwitterで発信中です。

HashHub:https://hashhub.tokyo/
Twitter:https://twitter.com/HashHub_Tokyo

■ブロックチェーンエンジニア集中講座開講中!
HashHubではブロックチェーンエンジニアを育成するための短期集中講座を開講しています。お申込み、詳細は下記のページをご覧ください。
ブロックチェーンエンジニア集中講座:https://www.blockchain-edu.jp/

■HashHubでは下記のポジションを積極採用中です!
・コミュニティマネージャー
・ブロックチェーン技術者・開発者
・ビジネスディベロップメント

詳細は下記Wantedlyのページをご覧ください。

Wantedly:https://www.wantedly.com/companies/hashhub/projects