今週のニュースレターでは、LNが焼却可能なアウトプットを基に前払い手数料と保留手数料をサポートできるようにする提案と、 testnet 3と4に関する議論（ハードフォークの提案を含む）の要約、 Taproot annexを含む特定のトランザクションのリレーを開始する計画の発表を掲載しています。 また、Bitcoin Stack Exchangeから選択した質問と回答や、新しいリリースとリリース候補の発表、 人気のBitcoinインフラストラクチャプロジェクトの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● 焼却可能なアウトプットを使用したLNの前払い手数料と保留手数料: John Lawは、 転送支払いに対して2種類の追加手数料を請求するためにノードが使用できるプロトコルについて書いた 論文の要約をDelving Bitcoinに投稿しました。 前払い手数料 は、転送ノードが HTLCスロット（HTLCを適用するためにチャネル内で利用できる限られた数の同時割り当ての１つ） を一時的に使用することに対する補償として、最終的な支払人が支払います。 保留手数料 は、HTLCの決済を遅らせるノードが支払います。この手数料の金額は、 HTLCの有効期限が切れたときに最大額となるまで、遅延の長さに応じて変化します。 彼の投稿と論文では、ニュースレター#86、#119、 #120、#122、#136、 #263にまとめられているような、 前払い手数料と保留手数料に関するこれまでの議論がいくつか引用されています。

    提案されているプロトコルは、Lawの オフチェーン支払い解決 （OPR）プロトコル（ニュースレター #329参照）のアイディアに基づいています。 このプロトコルでは、チャネルの共同所有者がそれぞれ、掛け金の100%（つまり合計200%）を、 どちらかが一方的に破壊できる焼却可能なアウトプットに割り当てます。 この場合、掛け金は前払い手数料と保留手数料の最大額です。両当事者が後でプロトコルが正しく遵守された（ すべての手数料が正しく支払われたなど）ことに満足した場合、 オフチェーントランザクションの将来のバージョンから焼却可能なアウトプットを削除します。 どちらかの当事者が満足していない場合、チャネルを閉じて焼却可能な資金を破壊します。 この場合、満足していない当事者は資金を失いますが、もう一方の当事者も資金を失うため、 どちらもプロトコル違反から利益を得ることはできません。

    Lawは、このプロトコルをチャネルジャミング攻撃のソリューションであると説明しています。 チャネルジャミング攻撃は、約10年前に初めて説明されたLNの弱点で、 攻撃者がほぼコストをかけずに他のノードが資金の一部またはすべてを使用するのを阻止できます。 返信では、保留手数料の追加により、 インボイスの保留がネットワークによってより持続可能になる可能性があると指摘されました。

  • ● testnet3と4の議論: Sjors Provoostは、 testnet4が利用可能になってから約半年が経過した現在（ニュースレター #315参照）、 testnet3をまだ使用している人がいるかどうかをBitcoin-Devメーリングリストで尋ねました。 Andres Schildbachは、少なくとも1年間は彼の人気のウォレットのtestnet版でtestnet3を使い続けるつもりだと 返信しました。Olaoluwa Osuntokunは、 testnet3は最近testnet4よりはるかに安定していると述べました。 彼は、Fork.ObserverのWebサイトから取得した両方のtestnetのブロックツリーのスクリーンショットを添付して、 自分の主張を説明しました。以下は、執筆時点でのtestnet4の状態を表す独自のスクリーンショットです:

    2025-03-25 の testnet4 のブロックツリーを表示するフォークモニター

    Osuntokunの投稿後、Antoine Poinsotはtestnet4の問題にフォーカスした別のスレッドを開始しました。 彼は、testnet4の問題は、難易度リセットルールの結果であると主張しています。 このルールは、testnetにのみ適用され、ヘッダーの時間が親ブロックより20分遅い場合、 ブロックは最小難易度で有効になります。Provoostは、この問題についてさらに詳しく説明しています。 Poinsotは、このルールを削除するためにtestnet4のハードフォークを提案しています。 Mark Erhardtは、フォークの日付として2026-01-08を提案しています。

  • ● 特定のTaproot annexをリレーする計画: Peter Toddは、Bitcoin-Devメーリングリストで、 Bitcoin CoreベースのノードであるLibre Relayを更新して、 Taprootのannexを含むトランザクションが以下の特定のルールに従う場合にリレーを開始する計画を発表しました:

    • 0x00プレフィックス: 「すべての空でないannexは0x00で始まり、 [将来の]コンセンサス関連のannexと区別します」

    • オール・オア・ナッシング: 「すべてのインプットがannexを持ちます。 これにより、annexの使用がオプトインになり、マルチパーティプロトコルでの トランザクションピンニング攻撃を防止できます。」

    この計画は、Joost Jagerによる2023年のプルリクエストに基づいています。 このプルリクエスト自体は、Jagerが始めた以前の議論に基づいています（ニュースレター #255参照）。 Jagerの言葉を借りれば、以前のプルリクエストでは、「非構造化annexデータの最大サイズを256 byteに制限し、 […] annexを使用するマルチパーティトランザクションの参加者をannexのインフレーションからある程度保護しました。」 Toddのバージョンでは、このルールは含まれていません。彼は、「annexの使用にオプトインする要件で十分なはずだ」と考えています。 そうでない場合、彼は取引相手のピンニングを防止できる追加のリレーの変更について説明しています。

    この記事の執筆時点で、現在のメーリングリストのスレッドでは、 annexがどのように使用されることを期待しているのか説明している人はいません。

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

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

リリースとリリース候補

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

  • ● Bitcoin Core 29.0rc2は、ネットワークの主要なフルノードの次期メジャーバージョンのリリース候補です。 バージョン29のテストガイドをご覧ください。

  • ● LND 0.19.0-beta.rc1は、この人気のLNノードのリリース候補です。 おそらくテストが必要な主な改善の1つは、以下の注目すべきコードの変更セクションで説明する、 協調クローズにおける新しいRBFベースの手数料引き上げです。

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

最近の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 #31603は、ParsePubkeyInnerパーサーを更新し、 先頭または末尾に空白がある公開鍵を拒否するようになりました。これは、 rust-miniscriptプロジェクトのパース動作と一致します。 これまでは、ディスクリプターのチェックサムの保護により、誤って空白を追加することは不可能でした。 getdescriptorinfoおよびimportdescriptors RPCコマンドは、 ディスクリプターの公開鍵の断片にそのような空白が含まれている場合、 エラーを投げるようになります。

  • ● Eclair #3044は、ブロックの再編成に対するチャネルの安全性のデフォルトの最小承認数を6から8に増やしました。 また、チャネルの資金量に基づいてこの値をスケーリングしないようにしました。 これは、スプライシング中にチャネルキャパシティが大幅に変更される可能性があるためです。 これにより、実際には多額の資金が預けられているのに、ノードが低い承認数を受け入れることになります。

  • ● Eclair #3026は、Simple Taproot Channelを実装するための基盤として、 Eclairが管理する監視専用ウォレットを含む、P2TR（Pay-to-Taproot）アドレス使用する Bitcoin Coreウォレットのサポートを追加します。P2TRウォレットを使用している場合でも、 一部の協調クローズトランザクションではP2WPKHスクリプトが依然として必要です。

  • ● LDK #3649では、必要なフィールドを追加して、 BOLT12オファーでLSP（Lightning Service Provider）に支払うためのサポートが追加されました。 これまでは、BOLT11とオンチェーン支払いオプションのみが有効になっていました。 これは、BLIPs #59でも提案されています。

  • ● LDK #3665では、QRコードに収まる最大バイト数に基づくLNDの制限に合わせて、 BOLT11インボイスのサイズ制限を1,023 byteから7,089 byteに増やしました。 PRの作者は、BOLT11インボイスで使用されるエンコーディングと互換性のあるQRコードは 実際には4,296文字に制限されているが、LDKでは「システム全体の一貫性の方がおそらく重要」であるため、 7,089という値が選択されたと主張しています。

  • ● LND #8453、#9559、#9575、#9568およびLND #9610は、 BOLTs #1205（ニュースレター #342参照）に基づく RBF協調クローズフローを導入し、どちらのピアも自身のチャネル資金を使用して手数料率を引き上げることができます。 これまでは、ピアは相手に手数料の引き上げを説得しなければならないことがあり、 その結果、試行がよく失敗しました。この機能を有効にするには、protocol.rbf-coop-close設定フラグをセットする必要があります。

  • ● BIPs #1792は、OP_CHECKTEMPLATEVERIFYを定義するBIP119を更新し、 より明瞭になるように文言を修正し、アクティベーションロジックを削除し、EltooをLN-Symmetryに名称変更し、 新しいコベナンツ提案や、OP_CTVを使用するArkなどのプロジェクトについての言及を追加しています。

  • ● BIPs #1782は、testnet4のコンセンサスルールを概説する BIP94の仕様セクションを、より明瞭で読みやすくなるように修正しました。