今週のニュースレターでは、さまざまなクラスターリニアライゼーション手法の比較のリンクと、 Bitcoin CoreのOP_RETURNサイズ制限の増加または撤廃に関する議論の簡単な要約を掲載しています。 また、新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべきの変更点など、 恒例のセクションも含まれています。

ニュース

  • クラスターリニアライゼーション手法の比較: Pieter Wuilleは、3つの異なるクラスターリニアライゼーション手法間のトレードオフについてDelving Bitcoinに投稿し、 それぞれの実装のベンチマーク結果を共有しました。 他の複数の開発者がその結果について議論し、質問を投げかけ、それにWuilleが回答しています。

  • Bitcoin CoreのOP_RETURNサイズ制限の引き上げまたは撤廃: Bitcoin-Devメーリングリストのスレッドでは、 複数の開発者がBitcoin CoreのOP_RETURNデータキャリアアウトプットのデフォルト制限の変更または撤廃について議論しています。 その後のBitcoin Coreのプルリクエストでもさらに議論されました。 ここでは、膨大な議論全体を要約するのではなく、変更に反対する賛否両論の意見の中で最も説得力のある議論要約します。

    • 制限の引き上げ(または撤廃)に賛成: Pieter Wuilleは、トランザクションの標準ポリシーが、 資金力がありマイナーに直接トランザクションを送信する組織によって作成された データキャリアトランザクションの承認を妨げる可能性は低いと主張しました。 さらに、データキャリアトランザクションが含まれているかどうかに関わらず、 ブロックは通常いっぱいであるため、ノードが保存する必要があるデータの総量はどちらの場合もほぼ同じであると主張しています。

    • 制限の引き上げに反対: Jason Hughesは、制限を引き上げることで、フルノードを実行するコンピュータに任意のデータを保存しやすくなり、 そのデータの一部は非常に好ましくない(多くの地方で違法となる)可能性があると主張しました。 ノードがディスク上のデータを暗号化したとしても(ニュースレター #316参照)、 データの保存とBitcoin Core RPCを用いたデータの取得は、多くのユーザーにとって問題となる可能性があります。

リリースとリリース候補

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

  • LND 0.19.0-beta.rc3は、この人気のLNノードのリリース候補です。 おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。

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

最近のBitcoin CoreCore LightningEclairLDKLNDlibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin Improvement Proposals(BIP)Lightning BOLTsBitcoin InquisitionおよびBINANAsの注目すべき変更点。

  • Bitcoin Core #31250は、レガシーウォレットの作成と読み込みを無効化し、 2021年10月以降(ニュースレター#172参照)デフォルトとなっている ディスクリプターウォレットへの移行を完了します。 レガシーウォレットで使用されていたBerkeley DBファイルは読み込みできなくなり、 レガシーウォレットのすべての単体テストと機能テストは削除されます。 一部のレガシーウォレットコードは残っていますが、後続のPRで削除される予定です。 Bitcoin Coreは、レガシーウォレットを新しいディスクリプターウォレット形式に移行することも可能です(ニュースレター #305参照)。

  • Eclair #3064は、ChannelKeysクラスを導入することで、チャネルの鍵管理をリファクタリングします。 各チャネルは独自のChannelKeysオブジェクトを持つようになり、 このオブジェクトはコミットメントポイントと組み合わせて、リモート/ローカル コミットメントおよび HTLCトランザクションの署名に使用するCommitmentKeysを導出します。 強制閉鎖ロジックとスクリプト/witnessの作成もCommitmentKeysを使用するように更新されました。 これまでは、外部署名者をサポートするために鍵生成がコードベースの複数のパーツに分散されていましたが、 正しい公開鍵が提供されるようにするために型ではなく名前に依存していたため、エラーが発生しがちでした。

  • BTCPay Server #6684は、BIP388ウォレットポリシーディスクリプターのサブセットをサポートし、 シングルシグとk-of-nの両方のポリシーのインポートおよびエクスポートを可能にします。 これには、SparrowがサポートするP2PKH、P2WPKH、P2SH-P2WPKHおよびP2TRといったフォーマットと、 P2TRを除くマルチシグ版が含まれます。このPRの目標は、マルチシグウォレットの利用を改善することです。

  • BIPs #1555は、BIP21を最新化し拡張したビットコインの支払い指示を記述するためのURIスキームを提案する BIP321をマージしました。従来のパスベースのアドレスは維持しつつ、 新しい支払い方法を独自のパラメーターで識別できるようにすることでクエリパラメーターの使用を標準化し、 クエリパラメーターに少なくとも1つの指示が含まれる場合は、アドレスフィールドを空にできるようにします。 また、受取人に支払いの証明を提供するためのオプションの拡張機能を追加し、 新しい支払い指示を組み込む方法に関するガイダンスを提供します。

もっと知りたいですか?

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