今週のニュースレターでは、アウトプットがUTXOセットの一部であることをゼロ知識で証明する概念実証の実装のリンクと、 オフラインLN支払いを可能にするための１つの新しい提案と２つの以前の提案、非IPネットワークアドレスのDNSシードに関する研究の概要を掲載しています。 また、クライアントとサービスの変更や、新しいリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも含まれています。

ニュース

  • ● UTXOセットの包含をゼロ知識で証明: Johan Halsethは、 現在のUTXOセット内の１つのアウトプットを管理していることを、どのアウトプットか明かさずに証明できる概念実証ツールの発表を Delving Bitcoinに投稿しました。最終的な目標は、 LNのファンディングアウトプットの共同所有者が、彼らのオンチェーントランザクションに関する具体的な情報を明かすことなく、 チャネルを管理していることを証明できるようにすることです。この証明は、 LNの分散型ルーティング情報を構築するために使用される次世代のチャネルアナウンスメッセージに添付することができます。

    使用される方法は、ニュースレター #303で説明されているaut-ctの方法とは異なり、 一部の議論は、違いを明確にすることに焦点を当てていました。追加の研究が必要で、 Halsethはいくつかの未解決の問題を説明しています。

  • ● LNのオフライン支払い: Andy Schroderは、 LNウォレットがインターネットに接続されたウォレットの支払いのために提供できるトークンを生成するのに使用できる通信プロセスの説明を Delving Bitcoinに投稿しました。たとえば、 アリスのウォレットは通常、アリスが管理するかLSP（Lightning service provider）によって管理されている 常時オンラインのLNノードに接続されます。オンラインの間、アリスは認証トークンを事前生成します。

    その後、アリスのノードがオフラインの状態でボブに支払いをしたい場合、 アリスはボブに認証トークンを渡します。これにより、ボブはアリスの常時オンラインノードまたはLSPに接続して、 アリスが指定した金額を引き出すことができます。アリスはNFCや、 広く使用されている他のデータ転送プロトコルを使用して、ボブに認証トークンを提供することができます。 このプロトコルはアリスがインターネットにアクセスする必要がないため、プロトコルはシンプルになり、 計算リソースが限られているデバイス（スマートカードなど）に簡単に実装できます。

    開発者のZmnSCPxjは、以前説明した代替アプローチについて言及し、Bastien Teinurierは、 この種のシチュエーション向けに設計したノードのリモートコントロール方法について言及しました（ ニュースレター #271参照）。

  • ● 非IPアドレース用のDNSシード: 開発者のVirtuは、 匿名ネットワーク上のシードノードの可用性に関する調査を Delving Bitcoinに投稿し、それらのネットワークのみを使用する新しいノードが DNSシードを通じてピアについて学習できるようにする方法について説明しました。

    背景として、BitcoinノードやP2Pクライアントは、データをダウンロードできるピアのネットワークアドレスを知る必要があります。 新しくインストールされたソフトウェアや、長い間オフラインになっていたソフトウェアは、 アクティブなピアのネットワークアドレスを認識していない可能性があります。 通常、Bitcoin Coreノードは、使用可能な可能性のある複数のピアのIPv4アドレスまたはIPv6アドレスを返す DNSシードに照会することでこれを解決します。DNSシードの照会が失敗した場合、 または使用できない場合（IPv4やIPv6アドレスを使用しない匿名ネットワークなど）、 Bitcoin Coreはソフトウェアのリリース時に利用可能だったピアのネットワークアドレスを含めます。 これらのピアは シードノード として使用され、ノードはシードノードに追加のピアのアドレスを要求し、 それらを潜在的なピアとして使用します。DNSシードはシードノードよりも好まれます。 これは、DNSシードの情報の方が最新であり、グローバルなDNSのキャッシュインフラストラクチャによって、 DNSシードが各照会ノードのネットワークアドレスを学習するのを防ぐことができるためです。

    Virtuは、Bitcoin Coreの過去4つのメジャーリリースにリストされているシードノードを調査し、 十分な数のシードノードがまだ利用可能であることを発見しました。 これは、匿名ネットワークのユーザーがピアが見つけることができるはずであることを示しています。 Virtuと他の議論の参加者は、DNSのNULLレコードを使用するか、 代替ネットワークアドレスを擬似IPv6アドレスにエンコードすることで、 匿名ネットワークのDNSシードを使用できるようにBitcoin Coreを変更する可能性も検討しました。

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

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

  • ● StrikeがBOLT12をサポート: Strikeは、BIP353DNS支払い指示でのオファーの使用を含むBOLT12オファーのサポートを 発表しました。

  • ● BitBox02がサイレントペイメントをサポート: BitBox02は、サイレントペイメントのサポートと ペイメントリクエストの実装を発表しました。

  • ● Mempool Open Source Project v3.0.0リリース: v3.0.0リリースには、新しいCPFP手数料計算、 フルRBFのサポートを含むRBFの追加機能、P2PKのサポート、 mempoolおよびブロックチェーンの新しい分析機能やその他の変更が含まれています。

  • ● ZEUS v0.9.0リリース: v0.9.0の投稿では、LSPの追加機能、参照専用ウォレット、 ハードウェア署名デバイスのサポート、チャネル開設トランザクションを含むトランザクションのバッチ化のサポートおよび、 その他の機能について概説しています。

  • ● Live Walletが統合トランザクションをサポート: Live Walletアプリケーションは、 アウトプットをいつ使用すると経済的に合理的でないかを判断するなど、 異なる手数料率でUTXOセットを使用する事ストを分析します。0.7.0のリリースでは、 統合トランザクションをシミュレートし、統合用のPSBTを生成する機能が含まれています。

  • ● Bisqがライトニングをサポート: Bisq v2.1.0は、ユーザーがライトニングネットワークを使用して取引を決済する機能が追加されました。

リリースとリリース候補

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

  • ● HWI 3.1.0は、複数の異なるハードウェア署名デバイスに共通のインターフェースを提供するこのパッケージの次期バージョンのリリースです。 このリリースでは、Trezor Safe 5のサポートが追加され、その他のいくつかの改善とバグ修正が行われました。

  • ● Core Lightning 24.08.1は、最近の24.08リリースで発見されたクラッシュやその他のバグを修正した メンテナンスリリースです。

  • ● BDK 1.0.0-beta.4は、ウォレットやその他のBitcoin対応アプリケーションを構築するためのこのライブラリのリリース候補です。 元のbdk Rustクレートの名前がbdk_wallet変更され、 低レイヤーのモジュールは、 bdk_chain、bdk_electrum、bdk_esplora、bdk_bitcoind_rpcなどの独自のクレートに抽出されました。 bdk_walletクレートは、「安定した 1.0.0 API を提供する最初のバージョンです」。

  • ● Bitcoin Core 28.0rc2は、主要なフルノード実装の次期メジャーバージョンのリリース候補です。 テストガイドが利用可能です。

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

最近の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へのコミットは、master開発ブランチに適用されるため、 これらの変更がリリースされるのは、次期バージョン28のリリースから約6ヶ月後になると思われます。

  • ● Bitcoin Core #28358は、 UTXOセットをRAMからディスクにフラッシュすることなくIBD（Initial Block Download）を完了するのに（ ディスクへのフラシュを控えることで約25%の速度向上が見込まれます）、 以前の16GBの制限では十分ではなくなったため、dbcacheの制限を撤廃しました。 将来に渡って使用可能な最適値が存在せず、ユーザーに完全な柔軟性を与えることができないため、 制限を上げるのではなく撤廃しました。

  • ● Bitcoin Core #30286は、クラスターリニアライゼーションで使用される候補選択アルゴリズムを、 このDelving Bitcoinの投稿のセクション２で説明されたフレームワークに基づいて最適化しますが、 いくつかの変更を加えています。これらの最適化により、反復が最小限に抑えられ、 リニアライゼーションのパフォーマンスが向上しますが、起動と反復あたりのコストが増加する可能性があります。 これは、クラスター mempoolプロジェクトの一部です。 ニュースレター#315をご覧ください。

  • ● Bitcoin Core #30807は、バックグランドでチェーンを同期しているassumeUTXOノードのシグナリングをNODE_NETWORKからNODE_NETWORK_LIMITEDに変更し、 ピアノードが約1週間以上前のブロックを要求しないようにします。これにより、 ピアが履歴ブロックを要求しても応答がなく、assumeUTXOノードから切断されるというバグが修正されます。

  • ● LND #8981は、paymentDescriptor型をリファクタリングし、lnwalletパッケージ内でのみ使用するようにします。 これは、チャネルコミットメントのアップグレードの一種である 動的コミットメントを実装するPRのシリーズの一部として、後でpaymentDescriptorを LogUpdateと呼ばれる新しい構造に置き換えて、更新のログ記録と処理を簡素化するためのものです。

  • ● LDK #3140は、BOLTs #1149で定義されているように、 常にオンラインの送信者として非同期支払いを送信するために 静的なBOLT12インボイス支払いをサポートしますが、 支払いのOnionメッセージ内でのインボイス要求は含まれません。 頻繁にオフラインになる送信者として送信したり、非同期支払いを受け取ったりすることはまだできないため、 フローをエンドツーエンドでテストすることはできません。

  • ● LDK #3163は、BOLT12インボイス内にreply_pathを導入することでオファーのメッセージフローを更新します。 これにより、インボイスエラーが発生した場合に、支払人が受取人にエラーメッセージを送り返すことができます。

  • ● LDK #3010は、対応するインボイスをまだ受け取っていない場合に、 ノードがオファーのリプライパスにインボイスリクエストの送信を再試行する機能を追加します。 これまでは、単一のリプライパスのインボイスリクエストメッセージがネットワークの切断により失敗した場合、再試行されませんでした。

  • ● BDK #1581は、BranchAndBoundCoinSelection戦略でカスタマイズ可能なフォールバックアルゴリズムを許可することで、 コイン選択アルゴリズムに変更を導入します。coin_selectメソッドのシグネチャが更新され、 コイン選択アルゴリズムに乱数生成器を直接渡すことができるようになりました。 このPRには、追加のリファクタリングや、内部のフォールバック処理、エラー処理の簡素化も含まれています。

  • ● BDK #1561は、依存関係とCIの簡素化のために、bdk_hwiクレートをプロジェクトから削除します。 bdk_hwiクレートにはHWISignerが含まれていましたが、これは現在rust_hwiプロジェクトに移動されています。

もっと知りたいですか？

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