BIP322について

前書き

宮本です。12月に入ってから寒すぎて鬱が加速しています。サウナで自律神経を整えることで乗り切ろうとしています。いいですねサウナ。この間初めてロウリュというのを体験したんですが、大量のおっさんが熱風を受けて「ｯｼｬｱ…」 「ｯｴｪｲ…」などと鳴き声をあげる様は中々の迫力で見応えがありました。

そんなことは置いといて、今回は最近出たあたらしいBIPについて書きます。汎用メッセージ署名フォーマットというものです。地味だけど超重要なやつです。日本語情報がないので書きます。

前提知識

もともとBitcoinにはsignmessageというRPCがあります。これは、「自分の保持するアドレスと任意のメッセージを引数にとってアドレスに対応する秘密鍵でメッセージに署名する」という機能です。検証はverifymessageというRPCで行います。いずれもバージョン0.5.0 からあるものです。

これの何が嬉しいかというと、支払いの理由を書いたメッセージに署名することでレシートのように使ったり、「自分はこのアドレスを所有している」という証明を(実際に支払いを行うことなく)行ったりすることができるという点です。

前者は多くの点でPay-To-Contractなどの別のスキームに対する優位性がそんなにないのですが(多分)、後者はCoinJoin、Colored CoinでのStakeを用いた投票、Web Serviceにおける認証などで様々な応用の可能性があります。この点が自分がこのBIP(あるいは、後続の類似BIP)に注目している理由です。

ここでの処理は全くブロックチェーンにもmempoolにも関係しないので、オフチェーンプロトコルの一種です。オフチェーンというとLightning Networkを想像する方が多いですが、後述のBitAuthのようにブロックチェーンにトランザクションを取り込ませないようなプロトコルでも重要なものは多くあります。

機能の目的そのものと直接の関係はありませんが、このスキームのユニークな点に、署名から公開鍵を作るというECDSA特有の機能を使っている点があります。通常scirptsig (あるいは)witnessには署名検証に必要な公開鍵が入っていますが、署名対象のメッセージが判明している場合に限り、公開鍵を復元できるので、公開鍵の分少しだけデータの容量を削減できます。ブロックチェーンに取り込まれる通常のトランザクションでもこの特徴を利用しようとしたことがあったようですが、検証コストが増えるので断念したようです。

ただ、現状利用しているwalletやサービスが少ないせいか、Bitcoin Coreでの機能のサポートは放置されており、P2PKHでしか使えない状態でした。これをP2WPKHはもちろん、スクリプトベースの認証(P2SH, P2WSH)にも使えるようにしようというのがBIP322の目的です。

BIP322

BIPはこちら

イメージとしては、

1. 普通に自分のUTXOから支払うトランザクションを相手に渡す。
2. ただし、そのTXにはインプット以外の部分がないためブロックチェーンに取り込まれることはできない。
3. そのスクリプトを通常のビットコインのスクリプトインタープリタで実行し、検証に成功すれば有効なものとみなす。

みたいな感じです。厳密にはscriptSigやwitnessを複数個含めることができたり、script verification flag (Scriptの実行時の挙動を指定したフラグ) を指定できたりするという点が通常のTXのインプットとは異なります。より詳細な仕様についてはBIPを参照してください。

ただの署名ではなく、スクリプトを使えるようになったので、たとえばマルチシグの場合でも使う権利があることを証明できたりします。便利ですね。

なお、メッセージへの署名と、資産の保有の証明は別の概念なので、後者は別のBIPになるようです 。他にも細かい点はまだ変更の可能性が高いです。

応用例

自分が思いつく応用例について書きます。この内容はBIPに書いてある訳ではないので、間違っていたらごめんなさい。

1. Chaumian CoinJoin

匿名性にフォーカスしたビットコインwalletの一種、WalletWasabiの採用してるChaumian CoinJoinでは、参加者が最初にfundの証明とブラインドされたアウトプットをTumblerに渡します。その際にフォーマットが固定されているとWallet間の相互運用性が高まります。

2. Colored Coinでの投票

Colored Coinを使い、ブロックチェーン上で改ざん不可能かつパブリックに検証可能な投票を行おうというのは古くからあるアイディアですが、実際にはブロックチェーンの容量を多く消費するため、ビットコインのメインチェーンの場合は現実的ではないアイディアでした。

そこで、Colored CoinのUTXOを投票券とみなし、その保持の証明と、投票先の情報に署名して、渡せばオフチェーンで投票を行うことができます。

3. ビットコインのスクリプトシステムによる認証

Webサービスの認証をパスワードで行うというのは気が狂っているとしか思えないアイディアですが、世の中ではそれがスタンダードになっています。ユーザーがwalletを持っていると仮定すれば、そのwalletの秘密鍵で署名してログインできるので、web serviceからの認証情報の漏洩の危険性がなくなり、ユーザーが自身の認証情報を自分で管理することができます。

このアイディアも古く、様々なものがありますが、現状のスタンダードは1. 認証権限の移行をオンチェーンで行い、2. その権限を仕様した認証をオフチェーンで行う。というものです。(詳しくはBitAuthのREADMEがわかりやすいです。)あるUTXOの保持を(当該Web Service内で)特定の権限と結びつければ、「そのUTXOを使う権利の証明」がそのままログインなどに使えます。

まとめ

サウナのおかげでいつもよりも短時間で記事を書くことができました。みんなもサウナに入りましょう。

執筆者: 宮本 丈

お知らせ
■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