今週のニュースレターでは、ブロックの伝播時間がマイナーの収益に及ぼす影響の分析と、 複数の当事者が資金を共有するプロトコルを解決するための新しいアプローチを取り上げています。 また、サービスとクライアントソフトウェアの最近の更新や、 人気のBitcoinインフラストラクチャソフトウェアの最近のマージの概要など、 恒例のセクションも含まれています。

ニュース

  • ● 伝播遅延とマイニングの集中化によるステイル率のモデル化: Antoine Poinsotは、ステイル（古くなった）ブロック率のモデル化と、 伝播時間がゼロの場合のハッシュレートの関数として、ブロック伝播時間がマイナーの収益にどのような影響を与えるかについて Delving Bitcoinに投稿しました。彼は、すべてのマイナーが現実的に（デフォルトのBitcoin Coreノードで） 行動するベースケースシナリオを設定しました： 新しいブロックを受信したら、すぐにその上でマイニングを開始し、それを公開します。 これにより、ハッシュレートのシェアに比例した収益が得られます。

    均一なブロックの伝播を想定した彼のモデルでは、ブロックが古くなる2つの状況がありました。

    1. 別のマイナーが我々よりも先にブロックを発見しました。他のすべてのマイナーは、 競合するマイナーのブロックを先に受信し、その上でマイニングを開始しました。 これらのマイナーのいずれかが、受信したブロックに基づいて２つめのブロックを見つけることができます。

    2. 別のマイナーが我々よりも後にブロックを発見しました。そのマイナーはすぐにその上でマイニングを開始します。 次のブロックも同じマイナーによって発見されました。

    Poinsotは、これらの状況のうち、最初の状況でブロックが古くなる可能性が高いことを指摘しています。 これは、マイナーは自分のブロックを公開することよりも、他者のブロックをより早く受け取ることを重視している可能性を示唆しています。 また、2つめの状況の確率は、マイナーの集中化と共に大幅に増加すると示唆しています。 両方の状況で、マイナーのハッシュレートが増加するにつれて確率が増加することは分かっていますが、 Poinsotはどの程度増加するかを計算したいと考えました。

    このために、彼は以下の2つのモデルを作成しました。

    ここで、hはネットワークハッシュレートのシェア、sはネットワークの残りが先に競合ブロックを発見するまでの秒数、 Hはネットワーク上のハッシュレートの分布を表すセットです。

    状況1のモデル: Illustration of P(another miner found a block before)

    状況2のモデル: Illustration of P(another miner found a block after)

    彼はさらに、ハッシュレートの分布のセットが与えられた場合に、 マイナーのブロックが古くなる確率を伝播時間の関数としてグラフに示しました。 グラフは、伝播時間が長いほど、規模の大きいマイナーがより多くの利益を得ることを示しています。

    たとえば、5EH/sのマイニングオペレーションでは、9,100万ドルの収益が見込まれ、 ブロックの伝播に10秒かかった場合、収益は10万ドル増加します。9,100万ドルは収益であって利益ではないことに留意してください。 したがって、10万ドルの収益増加は、マイナーの純利益という点でより大きな要因となります。

    グラフの下には、グラフの作成方法と、グラフ作成に使用したモデルの結果を裏付ける シミュレーションのリンクが記載されています。

  • ● 共同クローズのための秘密鍵のハンドオーバー: ZmnSCPxjは、秘密鍵のハンドオーバーについてDelving Bitcoinに投稿しました。 これは、以前2人の当事者によって所有されていた資金を単一の当事者に払い戻す必要がある場合に、プロトコルが実装できる最適化です。 この機能強化を最も効率的に動作させるためには、TaprootとMuSig2のサポートが必要です。

    このようなプロトコルの一例として、HTLCが挙げられます。 HTLCでは、プリイメージが明らかになった場合、一方の当事者が他方の当事者に支払いをし、 両当事者の署名が必要な返金トランザクションを作成します。秘密鍵のハンドオーバーでは、 プリイメージが明かされた後、エンティティは単純に一時的な秘密鍵を相手に引き渡すことができ、 これにより受信者は資金への完全かつ一方的なアクセスを得ることができます。

    秘密鍵のハンドオーバーは以下のように機能します:

    • HTLCをセットアップする際、アリスとボブはそれぞれ一時的な公開鍵と永続的な公開鍵を交換します。
    • HTLC Taprootアウトプットのkeypath支払いのブランチは、アリスとボブの一時的な公開鍵のMuSig2として計算されます。
    • プロトコル操作の終了時に、ボブはアリスにプリイメージを提供し、アリスは引き換えに一時的な秘密鍵を渡します。
    • ボブは、MuSig2の合計となる結合秘密鍵を導出でき、資金を完全に管理できるようになります。

    この最適化にはいくつかの具体的なメリットがあります。まず、オンチェーン手数料が急上昇した場合、 ボブは相手の協力なしにトランザクションをRBFできます。 この機能は、簡単な概念実証でRBFを実装する必要がなくなるため、プロトコル開発者にとって特に有用です。 2つめに、受信者は資金を請求するトランザクションを他の操作とバッチ処理できます。

    秘密鍵のハンドオーバーは、残りの資金のすべてを単一の受益者に一括で送信することを要求するプロトコルに限定されます。 したがって、ライトニングチャネルのスプライシングや協調クローズはこれから恩恵を受けることはありません。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● Arkadeのリリース: ArkadeはArkプロトコルの実装であり、 複数のプログラミング言語用SDK、ウォレット、BTCPayServerプラグイン、その他の機能が含まれています。

  • ● Mempoolモニタリングモバイルアプリケーション: Mempal Androidアプリケーションは、セルフホスト型のmempoolサーバーからデータを取得し、 Bitcoinネットワークに関するさまざまなメトリックとアラートを提供します。

  • ● Webベースのポリシーおよびminiscript IDE: Miniscript Studioは、miniscriptおよび ポリシー言語を操作するためのインターフェースを提供します。 機能についてはブログ記事で解説されており、 ソースも公開されています。

  • ● Phoenix WalletがTaprootチャネルをサポート: Phoenix WalletはTaprootチャネル、既存チャネルの移行ワークフロー、 マルチウォレット機能のサポートを追加しました。

  • ● Nunchuk 2.0のリリース: Nunchuk 2.0は、マルチシグ、タイムロック、 miniscriptを使用したウォレットの設定をサポートします。また、デグレードマルチシグ機能も含まれています。

  • ● LNゴシップトラフィック分析ツールの発表: Gossip Observerは、複数のノードからライトニングネットワークのゴシップメッセージを収集し、 要約メトリクスを提供します。この結果は、ライトニング用のminisketchのようなセット調整プロトコルに活用される可能性があります。 Delving Bitcoinのトピックでは、このアプローチに関する議論が行われています。

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

最近の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 #33745は、新しいマイニングプロセス間通信（IPC）submitSolution() インターフェース（ニュースレター #325参照）を介して 外部のStratumV2クライアントによって提出されたブロックのwitnessコミットメントが再検証されることを保証します。 これまでは、Bitcoin Coreは元のテンプレート構築時にのみこれをチェックしていたため、 無効またはwitnessコミットメントが欠落したブロックがベストチェーンの先端として受け入れられる可能性がありました。

  • ● Core Lightning #8537は、MPPを使用して非公開ノードに最初に支払いを試みる際、 xpayのmaxparts制限（ニュースレター #379参照）を6に設定します。これは、 JITチャネルの一種であるオンザフライ・ファンディング（ニュースレター #323参照）における Phoenixベースノードの6 HTLC受信制限に準拠しています。この制限値未満でルーティングが失敗した場合、 xpayは制限を解除して再試行します。

  • ● Core Lightning #8608は、既存のチャネルバイアスに加えてaskrene（ニュースレター #316参照）に ノードレベルのバイアスを導入します。指定されたノードのすべての送信チャネルと受信チャネルを優先または非優先にするために 新しくaskrene-bias-node RPCコマンドが追加されました。バイアスにはtimestampフィールドが追加され、 一定期間後に有効期限が切れます。

  • ● Core Lightning #8646は、BOLTs #1160およびBOLTs #1289で提案されている仕様変更に合わせて、 スプライシングチャネルの再接続ロジックを更新します。具体的には、 channel_reestablish TLVを拡張することで、ピアがスプライス状態を確実に同期し、 再送信が必要な情報を通信できるようにします。この更新はスプライシングチャネルにとって互換性のない変更であるため、 中断を回避するには両側で同時にアップグレードする必要があります。LDKにおける同様の変更は、 ニュースレター #374をご覧ください。

  • ● Core Lightning #8569は、BLIP52（LSPS2）で規定されているJITチャネルを、 lsp-trusts-clientモードでMPPをサポートせずに試験的にサポートします。 この機能は、experimental-lsps-clientおよびexperimental-lsps2-serviceオプションの背後で制御されており、 JITチャネルの完全なサポートに向けた第一歩となります。

  • ● Core Lightning #8558は、ピアの接続、切断、失敗、ping遅延の履歴を表示するlistnetworkevents RPCコマンドを追加します。また、ネットワークイベントログの保存期間（デフォルト30日）を制御する autoclean-networkevents-age設定オプションも導入されました。

  • ● LDK #4126では、ブラインドペイメントパスにおけるReceiveAuthKey ベースの認証検証が導入され、従来のホップ毎のHMAC/nonceスキーム（ニュースレター #335参照）が置き換えられました。 これは、ブラインドメッセージパス用にReceiveAuthKeyを追加したLDK #3917を基盤としています。 ホップごとのデータを削減することでペイロードが削減され、将来のPRでダミーメッセージホップと同様に ダミーペイメントホップ（ニュースレター #370参照）が使用できるようになります。

  • ● LDK #4208は、ウェイトの推定を更新し、DERエンコードされた署名を常に72 byteと想定するようにしました。 以前は、一部で72 byteを使用し、他の部分では73 byteを使用していました。73 byteの署名は非標準であり、 LDKはそれを生成することはありません。Eclairの関連する変更については、 ニュースレター #379をご覧ください。

  • ● LND #9432は、新しいグローバル設定オプションupfront-shutdown-addressを追加しました。 これは、特定のチャネルを開設または受け入れる際にオーバーライドされない限り、 協調チャネルクローズ時のデフォルトのBitcoinアドレスを指定します。これは、BOLT2で指定された アップフロント・シャットダウン機能に基づいています。LNDの実装に関する以前の記事については、 ニュースレター #76をご覧ください。

  • ● BOLTs #1284は、BOLT11を更新し、インボイスにnフィールドが存在する場合、署名は正規化されたLow-S形式でなければならず、 存在しない場合は、公開鍵の復元でHigh-SとLow-Sのどちらも受け入れることができることを明確にしました。 この動作を実装するLDKとEclairの最近の変更については、ニュースレター#371および #373をご覧ください。

  • ● BOLTs #1044は、オプションの失敗の帰属機能を定義しています。 この機能は失敗のメッセージに帰属データを追加することで、ホップが送信したメッセージにコミットできるようにします。 ノードが失敗のメッセージを破損した場合、送信者は後でそのノードを特定し、ペナルティを課すことができます。 この仕組みとLDKおよびEclairの実装の詳細については、ニュースレター#224、 #349および#356をご覧ください。

もっと知りたいですか？

このニュースレターで言及されたトピックについてもっと議論したい方は、 16:30 UTCに Riverside.fmで毎週配信されているBitcoin Optech Recapにご参加ください。 この議論は録画もされ、ポッドキャストページからご覧いただけます。