今週のニュースレターでは、ウォレットが作成するトランザクションからオプトイン方式のRBFシグナリングを削除する議論を掲載しています。 また、サービスとクライアントソフトウェアの最近の更新や、人気のBitcoin基盤ソフトウェアの注目すべき更新など、 恒例のセクションも含まれています。

ニュース

• ● ウォレットトランザクションからRBFシグナリングを削除する議論: rkruxは、ウォレットがトランザクションのオプトインRBFシグナリングを停止する提案について Bitcoin-Devメーリングリストに投稿しました。トランザクションは、 BIP125において、インプットの少なくとも1つのnSequenceをMAX-1未満（MAXは0xffffffff）に 設定した場合に置換可能であることをシグナリングします。しかし、フルRBFがデフォルトとなり（ニュースレター #315参照）、 mempoolfullrbfオプトアウトが削除されたため（ニュースレター #329参照）、 このシグナリングはトランザクションの置換可能性に影響を与えなくなりました。Bitcoin Coreのデフォルトリレーポリシーを使用するノードは、 nSequenceの値に関係なくすべてのトランザクションを置換します。現在、シグナリングは主に トランザクションを作成したウォレットを識別するために使用されているため、投稿ではウォレットが単一の値に収束すべきだと主張しています。

  rkruxは、nSequence = MAX - 1を使用してBitcoin Coreウォレットがデフォルトでシグナリングしないよう Bitcoin Core #35405を公開し、他のウォレット開発者にどの値であれば標準化可能かを尋ねました。 MurchとElectrum WalletのコントリビューターであるSomberNightは、 MAX - 2が既に主流の値であり、mainnet Observerによるとトランザクションの約75%、 Electrum Walletのトランザクションほぼすべてで使用されていると指摘しました。ほとんどのトランザクションは、 依然としてシグナルを発信しており、Bitcoin Coreをシグナルを発信しないMAX-1に移行すると、 そのトランザクションは紛れ込むどころかかえって目立ってしまうことになるため、両者ともMAX-2への収束を支持しました。 rkruxはこのフィードバックを受けて、プルリクエストをクローズしました。

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

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

• ● Sparrow Wallet 2.5.0がサイレントペイメントの受信に対応: Sparrow 2.5.0は、エアギャップ環境のハードウェアウォレット署名者を含む サイレントペイメントの受信ウォレットに対応しました。 これは2.3.0で追加された送信サポート(ニュースレター #377 参照)をベースとしています。

• ● BarkがBitcoin mainnetで稼働開始: Secondは、同社のArkプロトコル実装であるBarkがBitcoinのmainnetで稼働を開始したことを発表しました。 公開Arkサーバーに加え、開発者向けのBark SDKとbarkdデーモンが提供されます。Barkは以前 signetで立ち上げられていました(ニュースレター #346 参照)。

• ● Arké Arkウォレットの発表: Arkéは、Arkプロトコルをオンチェーン(BDK)および ライトニング支払いと統合したネイティブiOSウォレットで、3つのレイヤーすべてのトランザクションを単一の統合された履歴として表示します。 現在はsignet上で稼働しており、mainnet対応は開発中です。

• ● Noah Arkウォレットの発表: Noahは、Arkプロトコル上に構築されたクロスプラットフォームのモバイルウォレットで、 ライトニングサポートと信頼を最小に抑えた設計になっています。現在はベータ版です。

• ● Alby Hub v1.23.0のリリース: Alby Hub v1.23.0は、着信支払いを受け入れるために自動的に開かれる JITチャネルや、実験的なArk支払いバックエンドなど、各種の改善を追加しました。

• ● JoinMarket NG 0.32.0のリリース: coinjoin実装のコミュニティ管理フォークであるJoinMarket-NGは、 Neutrinoバックエンド向けのmempoolサポートをリリースしました。 これにより、テイカーがメイカーのブロードキャストを検証できるようになり、フィデリティボンドや信頼性に関する改善も含まれています。

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

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

• ● Bitcoin Core #35221は、BIP434のピア機能ネゴシエーションフレームワーク(ニュースレター #386および #390参照)のサポートを追加します。これは、versionとverackの間で交換され得る feature P2Pメッセージを追加してオプションのピア機能を通知し、P2Pプロトコルバージョン番号を 70017に引き上げます。Bitcoin Coreは現在、ネゴシエーション機構を実装しており、 未知の有効な機能IDは無視し、不正な形式のfeatureメッセージを送信したり、verackの後にそれらを送信したり、 互換性のあるプロトコルバージョンをネゴシエートせずに送信したりするピアを切断します。 ただし、特定のオプション機能はまだ通知していません。

• ● Bitcoin Core #35254は、使用後に追加の鍵導出材料をメモリから消去します。 CHMAC_SHA256とCHMAC_SHA512は、BIP32のチェーンコードや BIP324 HKDF鍵材料から導出されたデータを含む可能性のある一時的なrkey および内部ハッシュ用のtempスタックバッファをクレンジングするようになりました。ChainCodeの型は uint256のtypedefからmemory_cleanse()デストラクタを持つ型に変更され、 これらのオブジェクトが破棄される際に拡張鍵やローカル変数内のBIP32チェーンコードを消去します。

• ● Bitcoin Core #35498は、切断中のピアにブロックを要求する際のFetchBlock RPCパスにおける競合状態を修正します。FetchBlockはcs_mainをロックする前に有効なピア参照を取得できましたが、 BlockRequested()が要求を記録する前にピアのクリーンアップによってピアのCNodeStateが削除される可能性があり、 アサーションエラーを引き起こしていました。この修正では、ピアを検索する前にcs_mainをロックすることで、 ブロック要求が登録されている間にピアの状態が削除されないようにします。

• ● Eclair #3318は、Eclairが新たにロックされたスプライシングファンディングトランザクションのローカル状態を splice_lockedを送信せずに更新してしまう、再接続時のエッジケースを修正します。これは、 Eclairがchannel_reestablishを送信した後、ピアのchannel_reestablishを受信する前に発生する可能性があり、 どのファンディング状態がcommit_sigメッセージを必要とするかについてピア間の同期がずれ、 強制閉鎖を引き起こしていました。Eclairは再接続中に資金ロックイベントを処理し、 必要に応じてsplice_lockedを送信するようになりました。

• ● LND #10789は、BOLT12オファーの実装に向けた基盤を整えます。すなわち、 Offerメッセージ型とそれをサポートするlnwireTLVインフラを備えた、デーモン非依存のbolt12コーデックパッケージです。 新しいコーデックはエンコード前にメッセージを検証し、診断やファジング向けに低レベルのデコードを許容し、 未知の符号付き範囲TLVを保持することで、デコードと再エンコードをまたいでoffer_idが安定するようにします。

• ● Rust Bitcoin #6321は、攻撃者が要素数を操作して過剰なメモリ割り当てが引き起こされるのを防ぐため、 Segwitのウィットネスデコードを堅牢化します。これまでは、 わずか数byteの入力で大きなウィットネススタックを占有し、ウィットネスインデックス領域に約16MBの割り当てを強制できました。 新しいデコーダーは受信したウィットネスbyteをコンテンツバッファに追加し、ウィットネスデータのデコード後に end()で要素インデックスを構築することで、従来の一括割り当てパスを排除します。

• ● LDK #4685は、BOLT12インボイス検証に使用されるナンスを、 インボイスリクエストまたはリファンドのpayerメタデータに戻します。このナンスは以前、 ブラインド応答パスのOffersContextにも保存されていたため削除されていましたが、 それによってインボイスの検証がインボイスリクエストやリファンド自体の外部にある状態に依存することになり、 今後のBOLT12ペイメントプルーフと互換性がありませんでした(ニュースレター #405 参照)。 アウトバウンドのofferおよびリファンドのreply-pathコンテキストは、現在では期待される PaymentIdのみを保存するようになり、これは受信したインボイスのpayerメタデータから復元されたpayment IDと照合されます。

もっと知りたいですか？

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