有償のカンファレンスなので経緯を詳しく説明できないのですが、当業者BOTのなかのひとの登壇のあと、このような質問を受けました。

なぜ Lightning Network は invoice を起点とする決済となっているのか？ 
そのようになっていることでどのようなメリットがあるのか？

これは想定問答にありませんでした。困った…困った…急所だぞ。

...

助け舟を頂いておりますが、可能な限り"ゆるふわ"を標榜している手前、いきなり真顔になって「プリイメージのハッシュ」と言い出したら(なかのひと的には)敗北なわけです。困った…

(注: ノードの中身 (オフチェーンにあるトランザクション群のコントラクトなど) が思い浮かぶ場合には、プリイメージのハッシュで説明していくのが正道です。ここでは、なかのひとが無理な縛りを自分にかけているだけ)

この助け舟も重要です。Lightning Network はオフチェーンで小額決済を重ねていく…その際にトランザクションを上書きしていきます。履歴は残らないので、紛争になったときのために、何らかの証拠が要ります。

しかし、もうすこし深く考え過ぎてみると、送金側が証拠を残しても構わないのではという気もしてきます。invoice (請求書)ではなく、振込伝票というか出金伝票というか、そういうものでも良いのでは…。困った。

実際、Lightning Network にある欠点の幾つかを解決するとされる「Atomic Multi-Path Payments（AMP）」では、 送金を確実なものとするためのベースプリイメージの作成は(invoice を発行する着金側ではなく)送金側が作ります。(AMP が何なのかを知りたい技術勢は安土さんの解説記事をどうぞ)

「じゃあなんで invoice なんだよ？ 無駄に複雑にしているだけじゃないのか？w」ってビッグブロック派から、からかいの言葉が飛んできそうです。

...

ここから先は、当業者BOTの中の人の推測です。Lightning Network が invoice 起点であるべき、排他ではない 2 つの可能性が思い浮かんでいます。

...

一つ目は、送金の確実性を少しでも上げたい、という目論見です。

Bitcoin のオンチェーン送金のイメージ図は、たいてい下図のように示されます。

しかし、実際のところ、これはあまりに簡略化されすぎています。

ウォレットの中では、送金元がトランザクションを作成し、署名し、ノードにブロードキャストします。トランザクションは、採掘者によりブロックに取り込まれる(=承認される)までの間、mempool という領域に保持されます。ビットコインのネットワークには多数のノードがありますが、未承認のトランザクションは各ノードにコピーされて保存されます。

つまり、一旦ビットコインのネットワークにブロードキャストしたトランザクションは、いつかブロックに取り込まれます。送信者は、ブロードキャストした時点で、トランザクションのことは忘れて構いません。

一方、Lightning Network は、ノード対ノードのオフチェーン・ネットワークであり、ブロードキャストという概念はありません。mempool に相当する概念もありません。実際には協力するノードが中継することはあります。しかし本質としては、送金ノードと着金ノードのやりとりです。

このような構成では、一方的に送りつけるモデルは上手く動きません。着金ノードに到達できるかどうか事前に判らないからです。

invoice を発行させても、その直後に着金ノードまたはその経路が消失する可能性は常にあります。しかし、事前確認なく着金ノードへ投げつけるよりは、何が起こっているのかユーザに理解しやすいはずです。

着金側が invoice を発行できないとしたら、その時点で着金不可能であることは明らかですから。

...

あともう一つは…

…ちょっと長くなったので、稿を改めます。

上記した理由は、「理由付けとしては割と苦しいな」と、なかのひとも思いながら書いています。

しかし、もう一つのほうは、オンチェーンやビッグブロックでは実現が難しい、Lightning Network ならではのユースケースを示唆するものとなります。

(つづく)