今週のニュースレターでは、LN支払いが実現可能である可能性を推定する調査のまとめを掲載しています。 また、Bitcoin Stack Exchangeで人気の質問とその回答や、 新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● LN支払いが実現可能である可能性の推定: René Pickhardtは、 チャネルの最大容量が公開されているものの、現在の残高の分布が不明な場合に、 LN支払いが実現可能である可能性を推定する方法についてDelving Bitcoinに投稿しました。 たとえば、アリスはボブとのチャネルを持っていて、ボブはキャロルとのチャネルを持っています。 アリスはボブとキャロルのチャネルの容量を知っていますが、その残高の内ボブがどれだけ管理し、 キャロルがどれだけ管理しているかは知りません。

    Pickhardtは、ペイメントネットワークでは、不可分な資金の分配もあると指摘しています。 たとえば、キャロルはボブとのチャネルで、そのチャネルの容量を超える金額を受け取ることはできません。 不可能な分配をすべて除外すると、残りの資金の分配はすべて発生する可能性が同等であると考えることができます。 これにより、支払いが実現可能である可能性の指標を作成することができます。

    たとえば、アリスがキャロルに1 BTCの支払いをしたい場合、 その支払いが通過可能なチャネルがアリス-ボブとボブ-キャロル間だけであれば、 アリス-ボブのチャネルとボブ-キャロルのチャネルの資金配分の何%がその支払いを成功させるかを調べることができます。 アリス-ボブのチャネルの容量が数BTCの場合、考えられる資金配分のほとんどで支払いは成功するでしょう。 ボブ-キャロルのチャネルの容量が1 BTCをわずかに超える程度であれば、 考えられる資金配分のほとんどで支払いは成功しないでしょう。これにより、 アリスからキャロルへの1 BTCの支払いの実現可能性の全体的な可能性を計算できます。

    実現可能性により、単純に可能だろうと考えた多くのLN支払いが実際には成功しないことが明確になります。 これは比較を行うための有用な基盤も提供します。Pickhardtは、返信で、 ウォレットやビジネスソフトウェアが可能性の指標を使用して、 ユーザーに代わってインテリジェントな決定を自動的に行う方法について説明しています。

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

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

リリースとリリース候補

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

  • ● LND v0.18.1-betaは、「旧バージョン（v0.24.2より前）のbtcdバックエンドが使用されている場合に、 トランザクションをブロードキャストしようとした後のエラー処理時に発生する問題」を修正したマイナーリリースです。

  • ● Bitcoin Core 26.2rc1は、Bitcoin Coreの旧リリースシリーズのメンテナンスバージョンのリリース候補です。

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

最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals（BIP）、Lightning BOLTs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • ● Bitcoin Core #29575は、ピアの不正行為のスコアリングシステムを簡素化し、 2つのインクリメントのみを使用するようにしました：100ポイント（即時切断と推奨されない動作）と 0ポイント（許可された動作）のみです。ほどんどの種類の不正行為は回避可能でスコアが100に引き上げられましたが、 誠実で正しく機能しているノードが特定の状況下で実行する可能性のある2つの動作は0に削減されました。 このPRでは、最大8つのブロックヘッダーを含むP2Pのheadersメッセージのみを 新しいブロックのBIP130通知の可能性として考慮するヒューリスティックも削除されました。 Bitcoin Coreは、ノードが認識しているブロックツリーに接続していないすべてのheadersメッセージを 潜在的な新しいブロックの通知として扱い、不足しているブロックを要求します。

  • ● Bitcoin Core #28984は、サイズが2（1つの親と1つの子）のクラスターを持つパッケージに対して、 （v3トランザクションと呼ばれる）TRUC （Topologically Restricted Until Confirmation）トランザクションを含む RBF（replace-by-fee）の限定バージョンのサポートを追加します。 これらのクラスターは、同じサイズ以下の既存のクラスターのみを置き換えることができます。 関連するコンテキストについては、ニュースレター #296をご覧ください。

  • ● Core Lightning #7388は、2021年に行われたBOLT仕様の変更（ニュースレター #165参照）に準拠するため、 手数料がゼロでないアンカー形式のチャネルを作成する機能を削除します。 しかし、既存のチャネルのサポートは維持されます。Core Lightningは、これを完全に追加した唯一の実装であり、 実験モードでのみ実行されましたが、安全でないことが判明し（ニュースレター #115参照）、 ゼロ手数料のアンカーチャネルに置き換えられました。その他の更新には、 scidとnodeを両方含むencrypted_recipient_dataの拒否や、 Onion仕様に追加されたLaTeXフォーマットの解析、ニュースレター#259と#305で言及されている その他のBOLT仕様の変更が含まれています。

  • ● LND #8734は、支払いのループ中にクライアントのストリーミングコンテキストを認識させることで、 ユーザーがlncli estimateroutefee RPCコマンドを中断した際の支払いのルート推定の中止プロセスを改善します。 以前は、このコマンドを中断すると、サーバーが不要な支払いのプローブを続行していました。 このコマンドの以前の参照については、ニュースレター#293をご覧ください。

  • ● LDK #3127は、BOLT4で指定されているように、支払いの信頼性を向上させるために非厳密な転送を実装し、 HTLCをOnionメッセージのshort_channel_idで指定されたチャネル以外のチャネルを介してピアに転送できるようにします。 HTLCを通過できるアウトバウンドの流動性が最も少ないチャネルが選択され、 後続のHTLCの成功確率が最大化されます。

  • ● Rust Bitcoin #2794は、ScriptHashとWScriptHashにエラーが発生する可能性のあるコンストラクタを追加することで、 P2SHのredeem scriptの520バイトのサイズ制限とP2WSHのwitness scriptの10,000バイトのサイズ制限の強制を実装します。

  • ● BDK #1395は、明示的な使用と暗黙的な使用の両方でrandへの依存関係を削除し、 rand-coreに置き換えて依存関係を簡素化し、thread_rngおよびgetrandomの複雑さを回避し、 ユーザーが独自の乱数生成器（RNG）を渡すことができるようにすることで柔軟性を高めます。

  • ● BIPs #1620とBIPs #1622は、サイレントペイメントのBIP352仕様に変更を加えます。 secp256k1ライブラリでサイレントペイメントを実装するPRの議論では、 BIP352にコーナーケースの処理を追加することが推奨されています。具体的には、 送信とスキャンにおいて無効な秘密鍵/公開鍵の合算処理で、 （送信者の場合）秘密鍵の合算値がゼロの場合は失敗し、（受信者の場合）公開鍵の合算値が無限遠点の場合は失敗します。 #1622では、鍵の集約の前ではなく後でinput_hashを計算するようにBIP352が変更され、 これにより冗長性を減らし、送信者と受信者の双方にとって処理が明確になるようにします。

  • ● BOLTs #869は、BOLT2に新しいチャネル静止プロトコルを導入します。 このプロトコルは、プロトコルのアップグレードや ペイメントチャネルの大きな変更を、そのプロセス中に安定したチャネル状態を確保することで、 安全かつ効率的にすることを目的としています。このプロトコルは、 option_quiesceがネゴシエートされた場合のみ送信できる新しいメッセージタイプstfu（SomeThing Fundamental is Underway）を導入します。stfuが送信されると、送信者はすべての更新メッセージを停止します。 受信者は、更新の送信を停止し、可能であればstfuで応答し、チャネルが完全に静止するようにする必要があります。 ニュースレター#152および#262をご覧ください。