今週のニュースレターでは、LNのチャネルの基本手数料（Base fee）をゼロにすることについての議論の要約と、 Bitcoin Stack Exchangeの人気のある質問と回答、Taprootへの準備方法、新しいリリースとリリース候補、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションを掲載しています。

ニュース

  • ● 基本手数料ゼロに関するLNの議論: LNプロトコルでは、 支払人は、支払いを最終的な宛先までうまくルーティングしてくれる各ノードに支払う金額を選択できます。 一方、ルーティングノードは、十分な手数料を提供しない支払いの試みを拒否することができます。 このような役割分担を実現するために、ルーティングノードは期待する手数料を支払人に伝える必要があります。 そのためBOLT7では、fee_base_msat（基本手数料）と fee_proportional_millionths（金額に比例する手数料）という2つの手数料関連のパラメータを、 ルーティングノードが配信する機能を提供しています。

    René PickhardtとStefan Richterによる最近の論文では、 支払人が手数料と支払い成功するために必要な支払いの試行回数を最小限に抑えるために利用できる 新しい経路探索手法が提案されています（他の利点もあります）。しかし、現在のネットワークにこの手法を導入すると、 LNの基本手数料とマルチパス支払いに関連する2つの問題が発生します:

    • ● より多くの分割、より多くの手数料: 1つの経路での支払いと、 2つの同等の経路での同じ金額の支払いを比較してみてください: どちらも比例手数料は同額ですが（全体の支払い額は同じなので）、 2つの経路での支払いの基本手数料の合計は2倍になります（2倍のホップを使用するため）。 経路がx個の場合、基本手数料はx倍になります。 このため、マルチパス支払いの使用はコスト高になり、提案された手法など、 マルチパス支払いを使用する手法にはペナルティが課せられます。

    • ● 計算の難しさ: 論文の2.3節で述べられているように、 提案された経路探索アルゴリズムは、基本手数料がある場合、 経路と支払いの分割を容易に計算できません。 長期的にはこの問題をアルゴリズムで解決することができるかもしれませんが、 アルゴリズムの実装者にとって最も簡単な解決策は基本手数料を無くすことでしょう。

    著者は、ポッドキャストやTwitterで、 ノード運用者が基本手数料をゼロにすれば、LNプロトコルにすぐに変更を加えることなくこの問題に対処できると提案しました。 さらに、ノード運用者はこれらの研究がまだプロダクションに展開されてないにも関わらず、 これをすぐに始めることができると提案しました。 これをきっかけに、Twitter上でLN開発者同士の議論が行われ、 Anthony TownsがLightning-Devメーリングリストへの投稿と共に議論の移行を支援しました。

    Townsは、ユーザーが基本手数料をゼロにすることに賛成し、マルチパスによる分割の利点と、 ノード運用者が残り1つの手数料パラメータである比例手数料を最適化することが容易になることを指摘しました。

    Matt Coralloは、支払いをルーティングするためのHTLCを作成すると、 支払い金額に関わらず一定の負担がノードにかかるという懸念を応えました。 基本手数料を設定することで、ノードはこれらのコストの補償を要求することができます。 しかしTownsが反論したように、これらのコストはルーティングに成功した場合も失敗した場合も同じであるにも関わらず、 LNノードには成功した場合にのみ支払われます。ノードが一部のケースで補償なしにこれらのコストを受け入れるのであれば、 すべてのケースでそれを受け入れないのはなぜでしょうか？ただし、比例手数料についても同じことが言えます。 そこで、支払いに失敗した場合でもノードに補償を与えることができるUpfront fee についての簡単な議論が行われました。

    Townsはまた、基本手数料がなくても、一定額以下の支払いのルーティングを拒否するだけで、 ノードが最低限の手数料を受け取れるようにすることも可能だと提案しました。 例えば、現在基本手数料が1 satのノードは、0.1%の比例手数料と最低金額1,000 satを設定することで、 最低でもその金額を受け取ることができます。これはマイクロペイメントを阻害することになりますが、 LNノードはすでにHTLCを使わずに小額の支払いを処理しているため、固定コストの一部がなくなり、 純粋な比例コストがより適切になるかもしれませんが、これについては議論が残ります。

    議論の後半では、Olaoluwa Osuntokunが、ノード運用者が 現在プロダクションで使用する準備ができていない新しい経路探索アルゴリズムのパラメーターを変更する明白な必要性はないという先程の指摘を強調しました。 彼とCoralloは、基本手数料がゼロ以外の場合でも、 今後の研究開発によりこのアルゴリズム（もしくは異なる原理に基づく同様のアルゴリズム）が、 ほぼ同等に機能するようになるかどうかを確認したいと考えています。

    この記事の執筆時点では、この議論に明確な結論はでていません。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

Taprootの準備 #10: PTLC

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

先週のコラムでは、署名アダプターと Schnorr署名をサポートするTaprootのアクティベーションにより、 アダプターを非公開で効率的に使用することが簡単になることを紹介しました。 署名アダプターをBitcoinで使用する方法はいくつかありますが、最もすぐに役立つものの１つは、 長年使用されてきた歴史あるHash Time Locked Contracts (HTLC)に代わる Point Time Locked Contracts (PTLC)です。 これにはいくつかの利点がありますが、同時にいくつかの課題もあります。 両方を理解するために、まず現在使用されているHTLCの簡単な例から説明します。 以下の例では、オフチェーンのLN支払い、オンチェーンのcoinswap、 Lightning Loopのようなオンチェーン/オフチェーンのハイブリッドシステムが考えられます。 この柔軟性により、HTLCは広く利用されています。

アリスは、アリスもキャロルも信頼をしないボブを経由して支払いをルーティングすることで、キャロルに支払いをしたいと考えています。 キャロルはランダムなプリイメージを作成し、SHA256アルゴリズムでハッシュします。 キャロルはそのハッシュをアリスに渡し、プリイメージは秘密にしておきます。 アリスは、ボブへの支払いを開始し、ボブは自身の公開鍵に対する署名とプリイメージを使って支払いを受け取れます。 または、アリスは10ブロック経過したら自分の公開鍵に対する署名を使ってトランザクションを自分自身に戻すことで払い戻しをすることが可能です。 このポリシーをMinsc言語で定義すると以下のようになります:

(pk($bob) && sha256($preimage)) || (pk($alice) && older(10))

ボブは、参加者が更新され払い戻しのタイムアウトが小さくなるものの基本的に同じScriptを使って、 キャロルに同じ金額（おそらく手数料を差し引いた金額）の支払いを開始することができます。

(pk($carol) && sha256($preimage)) || (pk($bob) && older(5))

これでキャロルは、プリイメージを使って5ブロック以内にボブからの支払いを受け取ることができ、 これによりプリイメージが明らかになり、ボブは同じく5ブロック以内にアリスからの支払いを受け取ることができます。

HTLCのプライバシーの問題

上記のScriptがオンチェーンで公開された場合、同じハッシュとプリイメージが再利用されていることで、 AがBを経由してCに支払ったことが一目瞭然になります。 これは同じチェーンおよびクロスチェーンのcoinswapにとって重要な問題となります。 あまり明白ではありませんが、これはLNのようなオフチェーンのルーティングプロトコルにとっても問題です。 ある人が経路上の複数のホップを管理している長いルーティング経路を想像すると、 同じハッシュとプリイメージが再利用されていることを確認し、 一部のノードがルーティングノードであることを判断し、残りのノードが送信者か受信者のどちらかである確率を高めることができます。 これはLNの現在のプライバシー上の弱点であるリンク可能性問題の１つです。

Illustration of HTLC linkability problem

マルチパス支払いは、LNのリンク可能性問題の他の側面（支払い額のリンク可能性など）を部分的に軽減しますが、 監視ルーティングノードにハッシュを相関させる機会を与えることで、ハッシュのリンク可能性問題を悪化させる可能性があります。

現在のHTLCのもう１つの問題は、オンチェーンにする必要のあるScriptが通常の支払いのScriptとは明らかに異なることです。 これにより監視者は使用パターンを特定しやすくなり、おそらく個々のユーザーに特有の情報を効果的に推測することができます。

PTLCソリューション

これまでのMinscスタイルのScriptでは、事前に選択した特定の値（プリイメージ）が渡された場合にのみtrueを返す関数がありました。 署名アダプターも同様で、関数に公開された値（スカラー）が渡された場合のみ、有効な署名に変換することができます。 とりあえずマルチシグを無視すると、先程のHTLC Scriptは以下のPTLCに変換することができます:

(pk($bob) && pk($alice_adaptor)) || (pk($alice) && older(10))

(pk($carol) && pk($bob_adaptor)) || (pk($bob) && older(5))

つまり、キャロルはアリスに隠されたスカラーに対するECポイントを渡し、 アリスはそのECポイントと自身が選択した公開鍵を一緒に使用して、ボブに渡す署名アダプターを作成します。 ボブは、自身が選択した公開鍵と同じポイントを使用してキャロルに渡す署名アダプターを作成できます。 キャロルは、ボブのアダプターを有効な署名に変換することでスカラーを公開し、ボブのコインを受け取ります。 ボブは有効な署名からスカラーを復元し、アリスのアダプターを自分の有効な署名に変換し、アリスのコインを受け取ります。

これにより、誰もがブロックチェーンを確認しても個別の公開鍵に対する有効な署名の束があるだけなので、 オンチェーン監視に対するリンク可能性問題が解決されます。 第三者は、アダプターが使用されたことや、そのアダプターがどのスカラーに基づいているかを知ることはできません。

しかし、上記の手順では、ルーティングに参加している監視ノードが支払いをリンクするのを防ぐことはできません。 すべての支払いが同じスカラーに基づいている場合、すべての支払いはハッシュロックとプリイメージを使用した場合と同様リンクされます。 これは、各ルーティングノードが独自のスカラーを選択し、支払いがそのノードを通過する際に対応するポイントを削除することで解決できます。 それでは例を修正してみましょう:

前と同様に、キャロルはアリスに彼女のスカラーに対応するポイントを与えますが、 今回はアリスはボブにもポイントを要求します。アリスは、 キャロルのポイントとボブのポイントの両方を集約したものを使ってボブに渡すアダプターを構築します。 ボブは自分のポイントを知っているので、アリスから受け取ったアダプターからその点を引くことができます。 その結果得られた点（ボブはこれがアリスがキャロルから最初に受け取った点であることを知らない）を使って、 ボブはキャロルに渡すアダプターを構築します。キャロルはその最終的なポイントのスカラーを知っているので、 ボブのアダプターを有効な署名に変換します。前述のように、ボブはキャロルの署名からスカラーを復元し、 それと自分のスカラーを使ってアリスのアダプターを有効な署名に変換します。

この経路の２つのホップ（アリス→ボブとボブ→キャロル）では、２つの異なるECポイントとスカラーが使用されており、 リンク可能性を排除します。これをHTLCで検討した時より長い経路に拡張し、これによりプライバシーがどう改善されるか確認できます:

Illustration of PTLC lack of linkability problem

先週述べたように、Schnorr署名を使うとマルチシグのアダプター署名を簡単に構成することができます。 一般的なPTLCの場合、これによりオンチェーンScriptを以下のように削減することができます:

pk($bob_with_alice_adaptor) || (pk($alice) && older(10))

pk($carol_with_bob_adaptor) || (pk($bob)   && older(5) )

Taprootでは、左の分岐がkeypathになり、右の分岐がtapleafになります。 支払いのルーティングが成功すると、ボブとキャロルは相手の協力を得ること無く、 それぞれのパートをオンチェーンで決済することができます。 これにより、このルーティングされた支払いは、シングルシグの支払い、通常のマルチシグの支払い、 協調的に解決されたコントラクトと区別がつきません。また、ブロックスペースの使用を最小限に抑えることができます。 払い戻し条件の１つを実行する場合でも、それはかなり効率的でかなりプライベートなものです—pk(x) && older(n)は、 デグレード・マルチシグやHODLの強制、 その他のさまざまなScriptと区別がつきません。

来週のコラムでは、私たちのお気に入りのLN開発者の１人によるゲスト投稿で、 LNがkeypathによる使用やマルチシグ、PTLCおよびTaprootで可能になるその他の機能を採用するために必要な変更点について説明します。

リリースとリリース候補

人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。

  • ● Rust-Lightning 0.0.100は、keysend支払いの送受信をサポートした新しいリリースで、 成功したルーティング支払いの追跡と、ノードがそこから得た手数料収入の記録が容易になりました。

  • ● Bitcoin Core 22.0rc2は、 このフルノード実装とそれに付随するウォレットおよび他のソフトウェアの次のメジャーバージョンのリリース候補です。 この新バージョンの主な変更点は、I2P接続のサポート、 Tor v2接続の廃止、ハードウェアウォレットのサポートの強化などです。

  • ● Bitcoin Core 0.21.2rc1は、 Bitcoin Coreのメンテナンス版のリリース候補です。 いくつかのバグ修正と小さな改善が含まれています。

注目すべきコードとドキュメントの変更

今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 Bitcoin Improvement Proposals（BIP）、および Lightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #22541では、ウォレットバックアップをロードするために使用できる 新しいrestorewallet RPCコマンドが追加されました。restorewalletは、 現在ロードされているウォレットのコピーをエクスポートする既存のbackupwalletコマンドを補完します。 backupwalletとrestorewalletは、 別のファイルを使用する古いdumpwalletとimportwallet RPCの代替となることに注意してください。 この作業は、Bitcoin Core #22523のウォレットのバックアップおよび復元のためドキュメントの包括的な更新を伴っています。

  • ● LND #5442では、新しいアウトプットを追加することなくPSBTにインプットを追加するこができるようになり、 これはCPFPによる手数料の引き上げを作成するのに便利です。

  • ● Rust-Lightning #1011は、まだマージされていないBOLTs #847のサポートを追加しました。 これにより、2つのチャネルピアが協調クローズトランザクションで支払うべき手数料を調整することができます。 現在のプロトコルでは、１つの手数料のみが送られ、相手はその手数料を受け入れるか拒否しなければなりません。

  • ● BOLTs #887では、BOLT11を更新し、受信者のpayment_secret feature bitに関係なく、 送信者が支払いの際にpayment secretを指定することを要求します。 簡略化されたマルチパス支払いにおけるプロービング攻撃を防ぐために、payment secretを検証する必要があります。 この検証は、これまで取り上げた4つのLN実装すべてで以前から実装されています。