en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #232

Jan 4, 2023

今週のニュースレターでは、リリースの署名鍵の侵害についてBitcoin Knotsのユーザーへの警告と、 Bitcoin Coreの2つのソフトウェアフォークのリリースの発表、 Replace-By-Feeポリシーに関する継続的な議論の要約を掲載しています。また、新しいソフトウェアリリースとリリース候補の発表や、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

● Bitcoin Knotsの署名鍵の侵害: Bitcoin Knotsフルノード実装のメンテナーは、 Knotsのリリースに署名するために使用するPGP鍵の侵害を発表しました。彼らは、「これが解決されるまで、Bitcoin Knotsをダウンロードし信用しないでください。ここ数ヶ月の間に既にダウンロードして実行している場合は、今のところそのシステムのシャットダウンを検討してください。」と言っています。他のフルノード実装は影響を受けません。
● Bitcoin Coreのソフトウェアフォーク: 先月、Bitcoin Coreを元にした2つのパッチセットがリリースされました：
- ● Bitcoin Inquisition: Anthony Townsは、Bitcoin-Devメーリングリストで Bitcoin Inquisitionを発表しました。これは、Bitcoin Coreのソフトウェアをフォークしたもので、提案されたソフトフォークやその他の重要なプロトコル変更を、デフォルトsignet上でテストできるように設計されています。このバージョンには、SIGHASH_ANYPREVOUTと、 OP_CHECKTEMPLATEVERIFYの提案のサポートが含まれています。 Townsのメールには、signetのテストに参加する人向けの有益な追加情報も含まれています。
- ● フルRBFのピアリングノード: Peter Toddは、ノードがmempoolfullrbfを有効に設定している場合にのみ、ネットワークアドレスを他のノードに配信する際にフルRBFのサービスビットをセットするよう Bitcoin Core 24.0.1にパッチをあてたバージョンを発表しました。このパッチを実行しているノードは、最大4つ、フルRBFのサポートを配信している追加ピアにも接続します。 Peter Toddは、他のフルノード実装であるBitcoin Knotsも、フルRBFのサポートを配信するノードとピアリングするコードは含まれていないものの、サービスビットを配信していることを指摘しています。このパッチは、Bitcoin CoreのPR#25600に基づくものです。
● RBFの継続的な議論: mainnetでフルRBFを実現するための継続的な議論において、先月はメーリングリスト上でいくつかの並行した議論が行われました:
- ● フルRBFノード: Peter Toddは、Bitcoin Core 24.xを実行しており、 IPv4アドレスでインバウンド接続を受け入れることを公表しているフルノードを調査しました。彼は、約17%が、BIP125のシグナルを含まないトランザクションを置換するフルRBFの置換トランザクションをリレーしていることを発見しました。これは、これらのノードが、オプションのデフォルト値がfalseであるにも関わらず、 mempoolfullrbf設定オプションをtrueにセットして実行していることを示唆します。
- ● RBF-FSSの再検討: Daniel Lipshitzは、Bitcoin-Devメーリングリストに、 FSS(First Seen Safe)と呼ばれるタイプのトランザクション置換のアイディアを投稿しました。この置換は、少なくとも元のトランザクションと同じ金額を元のアウトプットに支払い、置換の仕組みが元のトランザクションの受信者から資金を盗むために使用できないことを保証します。 Yuval Kogmanは、2015年にPeter Toddが投稿した以前の同じアイディアのリンクを返信しました。その後の返信で、Toddは、このアイディアがオプトインRBFやフルRBFよりも好ましくないいくつかの点を説明しています。
- ● フルRBFの動機: Anthony Townsは、さまざまなグループがフルRBFを実行する動機についてスレッドに返信しました。 Townsは、マイナーのトランザクションの選択という文脈で、経済合理性が何を意味し、何を意味しないかを分析しています。短期的な利益を最適化するマイナーは、当然フルRBFを好むでしょう。しかし、Townsは、マイニング機器に長期的な資本投資を行っているマイナーは、複数のブロックにわたる手数料収入の最適化を好むかもしれず、その場合、常にフルRBFを好むとは限らないと指摘しています。彼は、考慮すべき3つのシナリオを提示しています。

リリースとリリース候補

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

● Eclair 0.8.0は、この人気のあるLNノード実装のメジャーバージョンリリースです。ゼロ承認チャネルとSCID（Short Channel IDentifier）エイリアスのサポートが追加されました。これらの機能やその他の変更点についての詳細は、リリースノートをご覧ください。
● LDK 0.0.113は、LN対応のウォレットやアプリケーションを構築するためのライブラリの新バージョンです。
● BDK 0.26.0-rc.2は、ウォレットを構築するためのこのライブラリのリリース候補です。

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

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

● Bitcoin Core #26265は、トランザクションリレーポリシーにおいて許容されるトランザクションの非witnessシリアライズサイズの最小値を82バイトから65バイトに緩和しました。たとえば、これまでは小さすぎると拒否されていた、単一のインプットと 4バイトのOP_RETURNパディングの単一のアウトプットを持つトランザクションをノードのmempoolに受け入れ、リレーすることができるようになりました。この変更の背景と動機については、ニュースレター #222を参照ください。
● Bitcoin Core #21576では、外部署名者（例：HWI）を使用するウォレットが、 GUIやbumpfee RPCを使用する際に、オプトインRBFによる手数料の引き上げができるようになりました。
● Bitcoin Core #24865は、ウォレットが作成された後に生成されたすべてのブロックがノードに残っている場合に、古いブロックがプルーニングされるノード上でウォレットのバックアップの復元を可能にしました。これらのブロックは、Bitcoin Coreがウォレットの残高に影響を与えるトランザクションをスキャンするために必要です。 Bitcoin Coreは、バックアップにウォレットが作成された日付が含まれているため、ウォレットの年齢を決定することが可能です。
● Bitcoin Core #23319は、verboseパラメーターに2がセットされている場合に、追加情報を提供するようgetrawtransactionRPCを更新しました。追加情報には、トランザクションが支払った手数料と、そのトランザクションのインプットとして使用された以前のトランザクション（「prevouts」）のアウトプットに関する情報が含まれています。情報の取得方法については、ニュースレター #172を参照ください。
● Bitcoin Core #26628では、同じパラメーター名を複数含むRPCリクエストを拒否するようになりました。これまでは、daemonはパラメーターが繰り返されるリクエストについて、繰り返されるパラメーターの内、最後のものだけを持つかのように扱っていました。たとえば、{"foo"="bar", "foo"="baz"}は、 {"foo"="baz"}として扱われていました。この場合、リクエストは失敗するようになりました。 bitcoin-cliを名前付きパラメーターで使用する場合は、動作は変わりません。同じ名前の複数のパラメーターは拒否されませんが、最後ののものだけが送信されます。
● Eclair #2464では、リモートピアが支払いを処理する準備ができた際に、イベントを発生させる機能を追加しました。これは、ローカルノードがリモートピアのために支払いを一時的に保留し、ピアが接続（または再接続）するのを待ってから支払いを行う非同期支払いの文脈で特に役立ちます。
● Eclair #2482は、最後の数ホップが受信者によって選択されるブラインド・ルートを使用した支払いの送信を許可するようにしました。受信者はオニオンによる暗号化によりホップの詳細を難読化し、暗号化したデータとブラインド・ルートの最初のノードのIDを送信者に提供します。送信者は、その最初のノードへの支払い経路を構築し、最後のいくつかのノードのオペレーターが復号して受信者に支払いを転送するために使用する暗号化された詳細を含めます。これにより、受信者は送信者にノードやチャネルのIDを開示することなく支払いを受け入れることができ、プライバシーを向上させることができます。
● LND #2208では、支払額に対するチャネルの最大キャパシティに応じて、異なる支払い経路を選択するようになりました。支払額がチャネルのキャパシティに近くなると、そのチャネルが経路として選択される可能性は低くなります。これは、Core LightningやLDKで既に使われている経路探索コードとほぼ同じです。
● LDK #1738と#1908は、Offerを処理するための追加機能を提供します。
● Rust Bitcoin #1467は、トランザクションのインプットとアウトプットのweight単位のサイズを計算するメソッドを追加しました。
● Rust Bitcoin #1330は、PackedLockTime型を削除し、下流のコードにほぼ同じabsolute::LockTime型を使用するよう要求しています。コードを更新する人が調査する必要がある2つの型の違いは、 PackedLockTimeがOrdを提供するのに対し、absolute::LockTimeは提供しません（ locktimeはそれを含むトランザクションのOrdで考慮されます）。
● BTCPay Server #4411では、Core Lightning 22.11（ニュースレター #229）を使用するように更新されました。 BOLT11インボイスに注文の説明のハッシュを入れたい人は、 invoiceWithDescriptionHashプラグインを使用することなく、代わりにdescriptionフィールドをセットしてdescriptionHashOnlyオプションを有効にすることができます。