Rusty Russell はオープンソース開発者で、Lightning Network のノードを動かすソフトウェア Core Lightning に大きく貢献しました。共通仕様 BOLT の策定にも携わり、再利用できるオファーから新しい支払い要求を取得する BOLT 12 を推進しました。Lightning は支払いチャネルを通じて bitcoin を送るネットワークです。
大きなプロジェクトも、静かな試みから始まります。Blockstream の 2026 年6月9日の回顧記事は、Russell が 2015 年5月26日に行った最初のコミットを紹介しています。チャネルを開くメッセージを作る小さな道具でした。コミットとはコードの履歴に記録された変更です。その試みは Core Lightning に育ち、Russell はプログラムやテスト、ほかの開発者への指導に関わりました。記事は十一年後の退任も伝えていますが、今後のオープンソース活動すべての終了を宣言するものではありません。過去の指導的役割がネットワーク全体への恒久的な権限になるわけでもありません。 [1]
カフェと客が別々のプログラムを使っている場面を想像してください。支払いのために同じ提供元を選ぶ必要はないはずです。必要なのは、メッセージとその意味についての共通ルールです。BOLT 仕様は Lightning のこの通信を記述します。Russell は共同の策定作業をまとめ、異なる実装が協力して動く相互運用性を支えました。公開リポジトリは提案や意見を受け付けています。ただし有力な貢献者でも、単独で全ノードに変更を強制できません。共通ルールは実際のソフトウェアと利用に反映される必要があります。 [1] [2]
同じ文章を二つのプログラムが違って解釈することもあります。Russell の lnprototest は、シナリオを書いてプロトコルのメッセージへの反応を試すための Python 製ツールを提供します。入門文書 README は、ダミー実行環境と本物の実装に対するテストを区別しています。模擬実行はテストの準備に役立ちますが、その成功だけでは実ノードの動作を証明できません。何を実行し、どの状況を調べたのかが重要です。一連のテストに通っても、あらゆる欠陥の完全な監査を終えたことにはなりません。 [3]
BOLT 12 では、カフェは QR コードなどで再利用可能なオファーを公開できます。客のウォレットはそれを基に invoice_request を送り、その支払い専用の情報を持つインボイス、つまり支払い要求を受け取ります。支払いはその後です。オファーを繰り返し利用しながら、各回のインボイスを取得できます。使用済みの一つのインボイスを、買い物のたびに新しい要求として扱う意味ではありません。オファー、取得要求、インボイスを分けることで、別々の支払いを混同せずに便利に使えます。 [4]
Core Lightning では、この区別が操作にも表れます。fetchinvoice はオファーの発行者に連絡し、インボイスを取得するコマンドです。changes 欄には、金額や説明など、オファーからの違いが示されることがあります。取得に成功しても送金は行われません。カフェで伝票を受け取り、何にいくら払うか確かめる段階と同じです。ウォレットは返された条件を処理し、別途支払いを開始します。要求の取得完了と支払い完了を取り違えないことが大切です。 [5]
pay の文書では complete、pending、failed を区別します。完了、保留中、失敗という意味で、保留中は支払い成功ではありません。amount_msat は受取人が得た金額、amount_sent_msat は手数料込みの総送金額です。msat は millisatoshi、satoshi の千分の一を表します。そのため客の支出は、カフェの受取額より手数料分だけ多いことがあります。文書では pay はすでに非推奨とされ、xpay への移行が説明されています。これは状態と金額の説明であり、特定版の導入手順ではありません。結果は使っているソフトウェアに合わせて読んでください。 [6]
カフェが返金しても、元の支払いを巻き戻すわけではありません。BOLT 12 は逆方向の流れも定めます。店が送りたい金額を示し、客がインボイスを渡し、店が支払先ノードの識別子 invoice_node_id を確認して、新たに客へ支払います。元の送金の取消しでも、自動的な返金権の発生でもありません。プロトコルが提供するのは実行する方法です。返金の理由や条件は、当事者が別に取り決める必要があります。 [4]
争いになったときは、証明が何を示すのかを知ることが役立ちます。BOLT 12 は、支払い要求のハッシュに対応する秘密の値 preimage により、インボイスが支払われたと示せることを説明しています。しかし公開後は別の人もその値を見せられるため、それだけでは送金した人を特定できません。取得要求に含める鍵は、誰がインボイスを求めたかを示すために使えますが、その人の公的な身元を自動で確認するものではありません。支払い済みであること、鍵を管理していること、客の身元は別の情報です。 [4]
理解を深めるには、この項目とあわせて次もお読みください Andrew Poelstra, Tadge Dryja, Lightning Network. 次の項目からも参照されています Andrew Poelstra, Tadge Dryja.