413 / 736HEARN

Mike Hearn

bitcoinj 開発者、ネットワーク・決済提案の著者

Mike Hearn は bitcoinj の開発に携わり、ウォレットがノードや店舗と通信する方法を提案しました。その仕事をたどると、普段のビットコイン決済の裏側と、さまざまな「受け取りました」という通知の違いが見えてきます。

Mike Hearn は Bitcoin の開発者で、技術的な提案を記す BIP のいくつかを執筆した人物です。bitcoinj ライブラリに加え、接続の確認、必要な取引の選別、決済時の通信方法に取り組みました。スマートフォンのウォレットから支払いを待つ店舗までの流れを追うと、その貢献を理解しやすくなります。

ビットコインのウォレットを開発するとき、通信処理をすべて一から書く必要はありません。用意された機能をまとめた「ライブラリ」を使い、その上にアプリを作れます。bitcoinj はその一つです。AUTHORS ファイルには多くの貢献者とともに Mike Hearn の名前があり、Git の変更履歴が案内されています。具体的に誰が何をしたかを追う手掛かりです。Hearn が全機能を単独で書いたことや、現在もプロジェクト全体を率いていることを意味するわけではありません。 [1]

bitcoinj は Java のライブラリで、手元に Bitcoin Core をインストールしなくてもウォレットの管理や取引の送受信ができます。スマートフォンで役立つのが、Simplified Payment Verification を略した SPV、つまり簡易支払い検証です。すべての取引を完全に検証する代わりに、ブロックヘッダーとウォレットに関係する取引を扱い、通信量や端末の資源を節約します。文書には実験的な完全検証モードも記されています。これらは異なる方式であり、軽く動くことは、全規則の同じ検証をただ速く行うことではありません。 [2]

ノートパソコンがスリープから復帰した場面を考えてみましょう。他のノードとの接続が開いて見えても、実際には動かなくなっているかもしれません。Hearn の BIP 31 は、nonce を付けた ping を送れるようにします。ここでの nonce は、個々の問い合わせを見分けるための数字です。相手は同じ数字を pong メッセージで返します。プロトコルバージョンが 60000 を超える場合、問い合わせと応答を対応付け、応答時間を測れます。これは通信の確認であり、返事が来ただけでノードの誠実さや支払いの有効性が証明されるわけではありません。 [3]

スマートフォンが、自分と関係のない取引までダウンロードするのはなぜでしょう。Hearn と Matt Corallo の BIP 37 は、該当する可能性のあるデータを絞る小さな仕組み、Bloom フィルターを説明します。filterload でフィルターを設定し、filteradd で項目を加え、filterclear でフィルターを削除します。無関係な取引が通ることもあり、これは偽陽性と呼ばれます。精度を高めるほど通信量は減りますが、接続先が取引とウォレットの IP アドレスを結び付けやすくなる場合があります。通信量の節約が、そのままプライバシー保護になるわけではありません。 [4]

スマートフォンは、届いた取引が本当に特定のブロックに属するかを確かめる必要があります。BIP 37 の merkleblock メッセージは、Merkle 証明に必要なデータを渡します。データの指紋にあたるハッシュを少数使うことで、取引とブロックヘッダー内のまとめられた指紋とのつながりを検証でき、ブロック全体をダウンロードせずに済みます。ただし、相手が別の取引を隠していないとは証明できません。SPV は取引の有効性を完全に検証する代わりにもなりません。bitcoinj の文書は、攻撃者がウォレットの全接続を支配し、見せる情報を選べる場合の危険を説明しています。 [4] [5]

買い物では、金額と受取先を知る必要があります。Gavin Andresen と Hearn の BIP 70 は、そのために PaymentRequest を導入します。メッセージには、取引が資金をどこに割り当てるかを指定する出力、金額、任意の有効期限といった決済情報が入ります。店舗の身元は、ウェブサーバーと同様に X.509 証明書で認証できます。しかし、認証を行わない要求である pki_type none も許されています。支払い要求の形式を使っているだけでは、店舗の身元が認証済みだとは言えません。 [6]

要求に決済サーバーが指定されていれば、支払いを承認した後にウォレットはそこへ Payment メッセージを送ります。応答の PaymentACK は、店舗が処理のために支払いを受け付けたという意味かもしれません。利用者には役立ちますが、あくまで店舗のサーバーからの通知であり、ブロック承認の証拠ではありません。同じように refund_to は、必要なら店舗が返金する先を示すだけで、その項目自体が返金することはありません。アプリは決済についての通知と、実際の資金移動を区別する必要があります。 [6]

古い解説を読むと、その手順がどこでも使えるように思えるかもしれません。BIP 70 は登録上 Deployed、つまり実装・導入済みです。一方、Bitcoin Core 0.20.0 のリリースノートには、このプログラムから対応を完全に削除したことが記されています。矛盾ではありません。過去に使われた仕様を、現在のすべてのクライアントがサポートしているとは限らないのです。Hearn の仕事はウォレットの発展を理解する手掛かりになりますが、実際に使う際は、個々のソフトウェアとそのバージョンの機能も確かめる必要があります。 [6] [7]

理解を深めるには、この項目とあわせて次もお読みください Jeff Garzik, Gloria Zhao, Merkle Tree. 次の項目からも参照されています Jeff Garzik, Gloria Zhao.

DOC · 001bitcoinj — recorded contributors文書 DOC · 002bitcoinj — library and verification modes文書 DOC · 003BIP 31 — Pong message文書 DOC · 004BIP 37 — connection Bloom filtering文書 DOC · 005bitcoinj — security model文書 DOC · 006BIP 70 — Payment Protocol文書 DOC · 007Bitcoin Core 0.20.0 — BIP70 removal文書
改訂日: 一次資料を優先 · 投資助言ではありません