今週のニュースレターは、LNの確率的な経路選択に関する論文と簡単な議論に、 Bitcoin Stack Exchangeで人気のあった質問と回答および、リリースとリリース候補、 Bitcoinインフラストラクチャソフトウェアの注目すべき変更点などの通常のセクションを掲載しています。

要処置事項

  • ● BTCPay Server 1.0.7.1へのアップグレード: プロジェクトのリリースノートによると、このリリースは、 “BTCPay Serverのバージョン1.0.7.0およびそれ以前のバージョンに影響を与える１つの重要な脆弱性と、 いくつかの影響の少ない脆弱性”を修正しています。

ニュース

  • ● 確率的な経路選択に関する論文: René Pickhardtは、Sergei Tikhomirov、Alex BiryukovおよびMariusz Nowostawskiとの共著の論文を Lightning-Devメーリングリストに投稿しました。 この論文では、それぞれのチャネル・キャパシティの範囲内で残高が一様に分布しているチャネルのネットワークをモデル化しています。 例えば、アリスとボブの間に1億satoshiのキャパシティを持つチャネルがある場合、 論文では、そのチャネルでは次のステートがすべて同じように起こりうると仮定し、 ネットワーク上の他のすべてのチャネルでも同じことが当てはまるとしています:

    アリス ボブ
    0 sat 100,000,000 sat
    1 sat 99,999,999 sat
    … …
    100,000,000 sat 0 sat

    この仮定を立てることで、金額と通過するホップ（チャネル）数に基づいて、 支払いが成功する確率を導き出すことができます。これにより著者は、経路を短くしたり、 マルチパス支払いを利用して大きな金額の支払いを小さな金額の支払いに分割するなどの いくつかの既知ヒューリスティックの利点を（他の仮定の下で）証明することができます。 また、このモデルを使用してbolts #780を使用したJust-In-Time (JIT)リバランシングなどの 新しい提案を評価しています。

    この論文では、その結論を使用して、既存のルーティングアルゴリズムを単純化した場合と比較して、 支払いのリトライを20%削減できるルーティングアルゴリズムを提供しています。 既存のアルゴリズムがヒュリスティックなアプローチをを使用しているのに対し、 このアルゴリズムは、より高い成功確率が計算された経路を優先します。 また、JITリバランシングと組み合わせることで、48%の改善が見込まれています。 リトライには通常数秒、場合によってはそれ以上時間がかかることを考えると、 これはユーザーエクスペリエンスの向上につながる可能性があります。 このアルゴリズムは、約1,000のライブチャネルのスナップショットから抽出されたものを含む、 いくつかのネットワーク例に対してテストされています。

    この論文では、ルーティング手数料を意図的に考慮していないため、メーリングリストでは、 ユーザーが過剰な手数料を支払わないようにしつつ結果をどう利用するかという点に焦点があてられました。

  • ● 支払いバッチについての記事を更新: Optechは、ニュースレター #37で発表した支払いバッチに関する記事を更新して掲載しました。 支払いバッチは、使用者の取引手数料を約80%節約することができる手法です。

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

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

リリースとリリース候補

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

  • ● BTCPay Server 1.0.7.1は、いくつかのセキュリティ上の脆弱性を修正しています。 またいくつかの改善とセキュリティ以外のバグ修正も含まれています。

  • ● HWI 2.0.1は、 Trezor Tのパスフレーズ入力やhwi-qtインターフェースのキーボード・ショートカットに関する小さな問題に対応したバグ修正リリースです。

  • ● C-Lightning 0.10.0-rc2は、このLNノードソフトウェアの次期メジャーバージョンのリリース候補です。

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

今週の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 #17227では、 AndroidOS用のbitcoin-qtをパッケージする新しいmake apkターゲットをビルドシステムに追加しました。 これは、Android NDKのパッケージ化のサポートを追加した以前の作業の続きです。 また、Android用のBitcoin Coreをビルドするためのドキュメントや、 Androidビルドシステムをテストするための継続的インテグレーションのジョブも含まれています。

  • ● Rust-Lightning #849では、チャネルのcltv_expiry_deltaを設定可能にし、 デフォルト値を72ブロックから36ブロックに下げました。このパラメータは、 ノードが下流のピアからの支払いが成功したかどうか確認した後、 上流のピアとの支払いの試行を決済する必要がある期限を設定します。 必要に応じて、トランザクションをオンチェーンで確認するのに十分な長さでなければなりませんが、 可能な限り遅延を最小限に抑えようとしている他のノードと競争できる程度には短くなければなりません。 LNDがその値を40ブロックに下げたニュースレター #40も参照ください。

  • ● C-Lightning #4427では、設定オプション--experimental-dual-fundを使うことで、 デュアル・ファウンドペイメントチャネルの実験が可能になりました。 デュアル・ファンディングでは、チャネルの初期残高を チャネルを開始するノードとチャネルを受け入れるノードの両方から拠出できるようになります。 これはチャネルの開設が終わるとすぐに支払いの受け取りを始めたいマーチャントや他のユーザーにとって便利です。

  • ● Eclair #1738では、 Anchor Outputが使用されている際の、 失効したHTLCのペナルティ実行の仕組みを更新しました。変更はAnchor Outputとは無関係ですが、 Anchor Outputがプロトコルに追加されると同時に導入され、 複数のSIGHASH_SINGLE|SIGHASH_ANYONECANPAYHTLCアウトプットを１つのトランザクションにまとめることができるようになりました（ニュースレター #128参照）。このPRにより、失効鍵で使用可能なすべてのアウトプットを、トランザクション毎に１つだけでなく、 すべてを同じトランザクションで請求することが保証されます。

  • ● BIPs #1080は、指定された高さになるまでノードがロックインされたソフトフォークの適用を開始する時間を遅らせるminimum_activation_heightパラメータでBIP8を更新しました。 これによりBIP8はSpeedy Trialの提案（ニュースレター #139参照）と互換性があり、 マイナーはTaprootをアクティベートできますが、 Speedy Trialを実装したソフトウェアのリリースから約6ヶ月後までTaprootのルールの適用を開始しません。