今週のニュースレターでは、Full replace-by-feeをゆっくりと段階的に行う代替案と、 提案中のOP_CHECKTEMPLATEVERIFYのソフトフォークをレビューするための一連のミーティングの発表について掲載しています。 また、リリースおよびリリース候補の発表や人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点のまとめなど、 恒例のセクションも含まれています。

ニュース

  • ● 簡単なFull RBFの次にオプトインRBFへ: Jeremy Rubinは、ニュースレター #154に掲載した、 Bitcoin CoreでFull replace by fee（RBF）を有効にすることについて Bitcoin-Devメーリングリストのスレッドに返信しました。 現在、BIP125に従ってシグナルを送るトランザクションは、 （いくつかの制限付きで）より高い手数料のトランザクションに置き換えることができます。 以前の提案は、置換可能性を示すオプトインのシグナルをセットしたものだけではなく、 最終的にあらゆるトランザクションを置き換え可能にする（Full RBF）というものでした。 一部のマーチャントは、リレーノードが合理的に可能な限り置き換えを困難にし、 少なくともオプションで低コストの商品やサービスに対して 未承認トランザクションを即座に受け入れられるようにすることを望んていると指摘しています。

    Rubinの代替案は、依然Full RBFへの移行を推奨していますが、まずはどのトランザクションについても、 ノードが最初に受信してからn秒間はFull RBFを許可することから始めることを提案しています。 n秒経つと、BIP125のオプトインフラグが現在と同じように尊重されます。 これにより、n秒経てば、マーチャントは現在と同様に未承認のトランザクションを受け入れることができます。 さらに重要なことは、安全性のために置換可能性に依存しているプロトコルが、 プロトコルノードやWatchtowerがトランザクションを最初に知ってからn秒以内に合理的に応答できる限り、 非オプトインのトランザクションについて心配する必要がないことです。

  • ● BIP119 CTVのレビューワークショップ: Jeremy Rubinは、Bitcoin-Devメーリングリストで、 BIP119のOP_CHECKTEMPLATEVERIFYの仕様について、 ネットワークへの展開方法を含め、定期的なミーティングを開催することを発表しました。 最初のミーティングは、1月11日（火）20:00 UTCから、Libera.Chatの##ctv-bip-reviewで開催されます。 その後のミーティングは、2週間ごとに同じ時間に開催される予定です。

リリースとリリース候補

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

  • ● Rust-Lightning 0.0.104は、いくつかのAPIの改善を含む、このLNノードライブラリの最新のリリースです。

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

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

  • ● Bitcoin Core #23789は、新しく作成されたお釣り用のアウトプットを常に送信先のアウトプットのタイプと一致するようにし、 可能な場合はP2TRのお釣り用アウトプットの作成を優先します。 このPRは、Taprootの早期採用者のお釣り用のアウトプットが、 レガシーアドレスに支払う際に簡単に特定されてしまうというプライバシーの懸念に対応するものです。

  • ● Bitcoin Core #23711は、 未承認トランザクションの受け入れとリレーに関するBitcoin Coreのポリシーのいくつかをドキュメント化したものです。 このドキュメントは、受け入れやリレーの動作に依存する必要があるウォレットやコントラクトプロトコルの作者にとって特に役立つでしょう。

  • ● Bitcoin Core #17631は、FilterおよびRESTエンドポイントを有効にしたノード上で、 Compact Block Filterを提供する新しいRESTエンドポイントを追加しました。

  • ● Bitcoin Core #22674は、トランザクションのパッケージを検証し、 ノードのトランザクションリレーポリシーに対してそれをテストするロジックを追加しています。 この場合のパッケージとは、1つの子トランザクションと、そのすべての未承認の親トランザクションを指します。 後続のPRは、CPFPとRBFのサポートを追加することで検証ロジックを拡張する予定です。

    後続のPRでは、現在利用可能なロジックを使用して検証されるトランザクションのパッケージを、 ローカルノードにピアから送信できるようにする方法が追加されるでしょう。 これによりパッケージリレーが可能になり、 LNのようなコントラクトプロトコルの信頼性と安全性が向上します。 このPRでは、パッケージ検証ルールに関するドキュメントも追加されています。

  • ● Bitcoin Core #23718は、PSBTに含まれる すべてのハッシュとプリイメージを保持し表示するためのサポートを追加しました。 HTLCやその他のコントラクトプロトコルのプリミティブで使用されるPSBTには、 PSBTのUpdaterまたはSignerのいずれかがそのプリイメージを知っているハッシュが含まれている場合があります。 このプリイメージは、目的の最終トランザクションを生成するために必要になる場合があります。 このPRは、Bitcoin Coreがそのようなトランザクションの作成、 管理およびファイナライズに効果的に参加しやすくするためのものです。 Bitcoin Coreがminiscriptを採用した場合、さらに改善が期待されます。

  • ● Bitcoin Core #17034は、PSBTバージョン2(ニュースレター #128参照)のサポートと、 ニュースレター #72に掲載した独自のPSBT拡張用のフィールドを含む、追加のPSBTフィールドを追加しました。 Bitcoin Coreは独自拡張を理解しませんが、処理するPSBTでそれらを保持し、 decodepsbt RPCの結果でそれらを表示するようになりました。

  • ● Bitcoin Core #23113は、 ユーザーが非圧縮公開鍵を使用してsegwitのマルチシグアドレスの作成を要求した場合に、 警告フィールドを含むようcreatemultisig RPCとaddmultisig RPCを更新しました。 segwitのオリジナルの実装以来、Bitcoin Coreは、 デフォルトで、非圧縮公開鍵が含まれるsegwitインプットを使用する未承認トランザクションをリレーまたはマイニングしません。 つまり、圧縮されていない鍵を使用してアドレスを作成したユーザーは、 そのアドレスで受け取った資金を使うことができなくなる可能性があります。 そのため、これらのRPCでは、圧縮されていない鍵に対してbech32アドレスは作成されず、 代わりにレガシー（base58check）アドレスが作成されます。 新しい警告フィールドは、このような状況にあるユーザーが、 要求したものとは違うタイプのアドレスを受け取る理由を理解するのに役立つはずです。

  • ● Bitcoin Core GUI #459は、古いアドレスタイプに加えて、 bech32mアドレスを作成する機能を備えたアドレス生成ダイアログを更新しました。

    Screenshot address picker

  • ● Eclair #2090は、max-per-peer-per-second設定オプションで、 Onionメッセージのレートを制限する機能を追加しました。

  • ● Eclair #2104は、オンチェーンで即時に使用可能な残高が、 Anchor Outputを使用したCPFPによる手数料の引き上げを使用して タイムリーにチャネルを閉じるために必要な推定金額以下になった場合に、 ローカルノードオペレーターに警告するログメッセージを追加しています。 LN開発者または独自のリザーブ値を選択するオペレーターは、 Eclairの推定値とLNDで使用される推定値を比較することをお勧めします。

  • ● Eclair #2099は、onion-messages設定オプションを追加し、 Onionメッセージをリレーしない（ただし、ノードがメッセージを送受信することは可能）、 すべてのメッセージをリレーする（新しいピアへの接続を開く必要があるものを含む）、 既存の接続のメッセージのみをリレーするよう設定できるようになりました。

  • ● Libsecp256k1 #964は、libsecp256k1ライブラリのリリースプロセスとバージョン管理方式の概要をまとめています。

  • ● Rust Bitcoin #681は、BIP371のTaproot用のPSBTフィールドのサポートを追加しました。

  • ● Rust-Lightning #1177は、上位レベルのウォレットアプリケーションが受け取りたい支払いに関する情報を、 Rust-Lightning自体が保存する必要性を無くしました。代わりに、支払いに関する重要な情報は暗号化され、 ペイメント・シークレットにエンコードされます。 支払いを受け取ると、暗号化されたペイメント・シークレットは復号され、平文の情報は 支払いのHTLCを保護するために使用されているペイメント・ハッシュを満たす ペイメント・プリイメージを導出するのに使用されます。

    これは、ニュースレター #168に掲載したアイディアの簡略化された実装です。 他のLN実装では、インボイスに関する情報（例えば、マーチャントのショップソフトウェアが提供する任意の注文識別子）を 保存することができますが、Rust-Lightningは上位アプリケーションに直接統合することを想定したライブラリであるため、 上位アプリケーションが自身の支払い要求の詳細を管理できるようにし、これを回避しています。

  • ● HWI #545および#546、#547は、 tr()descriptorのサポート、 BIP371のTaproot用のPSBTフィールドのサポート、 基礎となるハードウェア署名デバイスで利用可能な場合にTaproot Script用のbech32mアドレスをサポートすることで、 Taprootのサポートを追加しています。 これらのPRの時点では、HWIは、Taprootをサポートする一部の署名デバイスのファームウェアを完全にサポートしていないため、 これらのデバイスではまだTaprootのサポートは有効になっていないことに注意してください。

  • ● BIPs #1126は、Bitcoinのハードフォークの変更案であるOptical Proof of Work (OPoW)のBIP52を追加しました。 これは、マイニング機器（資本支出）と電力および運用コスト（運用支出）の間のコスト分担を変更すると主張するものです。 このアイディアはBitcoin-Devメーリングリスト上で以前議論され、支持者と反対者が両方いました。