今週のニュースレターでは、内密の賭けを装った確率的なCoinjoinプロトコルの提案と、 軽量クライアント向けのサイレントペイメントインデックスサーバーとコンパクトブロックフィルターのベンチマーク結果について掲載しています。 また、新しいリリースとリリース候補の発表、人気のあるBitcoin基盤ソフトウェアへの注目すべき更新など、恒例のセクションも含まれています。

ニュース

  • ● 確率的Coinjoinと秘匿ベッティングプロトコル: Adam Gibsonは、 新たな確率的Coinjoinおよび秘匿ベッティングのプロトコル案であるBabiloniaについて Delving Bitcoinに投稿しました。この提案の狙いは、 プライバシーを求める行為に「もっともらしい否認可能性」を持たせることです。追跡やフラグ付け、 あるいは犯罪視されたりする識別可能な行動をとる代わりに、Gibsonは秘匿型のベッティングプロトコルを提案しています。 ユーザーはこのプロトコルに参加することで、共通インプット所有ヒューリスティックを崩すことができます。 この賭けは、資金の持ち主が入れ替わるオンチェーンのコイントスに似ていますが、外部からは通常の支払いに見えます。

    論文で説明されているプロトコルの流れは次のとおりです:

    • アリスとボブはそれぞれのインプットを提供し、共有UTXOを構築します。また、 長いタイムアウト後に資金を所有者に返金する返金トランザクションと、 賭けを精算するペイアウトトランザクションにも署名します。

    • アリスは2つの秘密の数値a_1とa_2を生成し、そのうち1つを自分の選択とし、対応する公開鍵A_1とA_2を公開します。

    • ボブはどちらか1つを予想として選び、自分の予想とアリスの選択が一致した場合にのみ使用可能な公開鍵Kを構築します。

    • ペイアウトトランザクションは、Kで使用可能なアウトプットに資金を送ります。 アリスはこのトランザクションに部分的なアダプター署名を行います。 ボブが自身の部分署名を行い、ファンディングトランザクションが承認された後、 アリスはアダプターに隠された秘密値を帯域外で提供し、ボブはアリスが選択した数値を復号できるようになります。 ボブが勝った場合、ボブはペイアウトトランザクションを完成させてブロードキャストし、資金を受け取ります。

    著者によると、プロトコルを複数回実行すれば、統計的にはユーザーは手数料を除いて当初の資金を維持しつつ、 プライバシーを向上させることができます。これは平均的には成り立ちますが、 個々のユーザーについては乖離する可能性があります。ただしGibsonは論文の中で、 このプロトコルの実際の有効性を示す明確な指標はまだないと述べています。 Gibsonはその後のフォローアップ投稿で、 勝者のペイアウトが自身のプール拠出額の整数倍になるため単発の賭けではその賭けの規模が漏洩することを指摘し、 各賭けを不均等な複数のサブ賭けに分割する論文の第2版を公開しました。

  • ● サイレントペイメントの軽量クライアントに関する最新情報: Rob Segersは、Delving Bitcoinでの以前の議論（ニュースレター #305参照）の進展について Bitcoin-Devメーリングリストに投稿しました。2024年6月に停滞していたこの議論は、 サイレントペイメントの軽量クライアントの仕様策定と、 ブロックからデータを取得するさまざまな方法のパフォーマンス測定に焦点を当てていました。

    Segersは、BIP352のインデックスサーバーの実装であるBlindBit Oracle v2のインスタンスを稼働させました。 この実装はフィルターを完全に廃止し、代わりにアウトプットごとのデータ（txid、tweak、および8 byteのアウトプットプレフィックス）をストリームします。 SegersはそのパフォーマンスをBIP158のコンパクトブロックフィルターおよび Taproot専用フィルターと比較しました。比較は、Taprootのアクティベーションからブロック965,089まで（合計 255,434ブロック）を対象に行われました。結果によると、BlindBit Oracleのアプローチは、 偽陽性がなく一致ごとにブロックを取得する必要もないという利点がある一方で、 Taproot専用フィルターに加えフィルタークライアントが依然として必要とする生tweakデータのバイト数と比較して、 約2.1倍のバイト数をダウンロードします（フィルタークライアントが一致ごとに取得する必要のあるフルブロックは含まない）。

    Segersはまた、軽量クライアントは現状、サーバーがあるブロックのtweakを省略したかどうかを判別できず、 結果として受信者が資金を密かに失う可能性があることを指摘しました。 彼のサーバーは、ソートされたtweakセットに対するブロックごとのコミットメントを公開し、 それを6時間ごとにnostrにチェックポイントすることで、事後に省略の責任を追跡できるようにしています。 ただしクライアントは、一致した場合には依然としてフルブロックを取得すべきです。

    最後にSegersは、BlindBit Oracleの新バージョンが当初の仕様から大きく乖離していることを指摘しました。 そのため作者は、仕様を整合させるためのドラフトを公開し、議論を呼びかけています。

リリースとリリース候補

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

  • ● LDK v0.3-rc1は、LN対応のウォレットやアプリケーションを構築するためのこのライブラリの次期メジャーバージョンのリリース候補です。 保留中のスプライスに対するRBFによる手数料の引き上げと、 同一のスプライスでの資金の追加と削除のサポートが追加されています。また、 デフォルトでアンカーチャネルをネゴシエートするようになり、 アプリケーションは受信チャネルを明示的に承認するのが必須となりました。アップグレードすると、 ペイメントメタデータを含む以前に発行されたBOLT11インボイスは無効になります。 開発者はテストの前にAPIと後方互換性に関する変更を確認してください。

  • ● LDK v0.2.6は、LN対応のウォレットやアプリケーションを構築するためのこのライブラリのセキュリティリリースです。 同一のペイメントハッシュを持つ2つめのHTLCが正常に転送された後に拒否された無効な支払いが、 チャネルマネージャーをデシリアライズに失敗する状態に陥らせるサービス拒否脆弱性を修正しています。 また、悪意ある相手方が自身が開始したスプライスへの資金供給時にノードに手数料を過剰に割り当てさせ、 その超過分が相手方のアウトプットに渡ってしまう手数料インフレの脆弱性も修正しています。

  • ● BTCPay Server 2.4.4は、このセルフホスト型ペイメントプロセッサーのセキュリティリリースです。 レガシーなBitPayのBasic認証APIキーを削除し、その認証方式を廃止したため、 影響を受ける連携機能はサポートされている認証方式に移行する必要があります。 既存のGreenfield APIキーは引き続き機能します。このリリースでは、インボイスの状態を変更する際に認可が必要になり、 制限付きAPIキーによる無制限のキーの作成が防止され、後述するAPIキーの保存方法の変更も含まれています。 付随するDockerのアップデートでは、ホスト管理へのアクセスが制限され、 LNDの共有デフォルトウォレットパスワードが一意のパスワードに置き換えられ、 LNDの認証不要なウォレット管理ルートがリバースプロキシでブロックされます。これらのLNDの変更は、 2.4.2のインシデント（ニュースレター #418参照）後にLND APIを再公開していたサーバーに対して、 LNDの認証不要なパスワード変更エンドポイントへの探索行為が観測されたことに対処するものです。 該当する運用者はそのアクセスを取り除くべきです。 すべてのサーバー管理者はアップグレードし、破壊的変更を確認することが推奨されます。 Webホスティング向けの課金プラグインについては、バージョン4.0.0へのアップグレードと、 レガシーAPIキーの新しいGreenfield APIキーへの置き換えが移行に必要です。 詳細は移行ガイドをご覧ください。

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

最近の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 #35949は、Murch–Zawyが提案したタイムワープ攻撃への緩和策（ BIP54およびニュースレター #316参照）に従うよう、 ブロックテンプレートの作成を更新しました。2,016ブロックの各難易度調整期間の最後のブロックについて、 最小タイムスタンプは少なくともその期間の最初のブロックのタイムスタンプ以上でなければなりません。 これまでは、ノードの時計がその期間の最初のブロックより遅れている場合、 直近11ブロックのタイムスタンプの中央値を超えていれば、提案されるタイムスタンプもそれより前になる可能性がありました。 getblocktemplate RPCは、ノードの時計がこの最小値より遅れている場合も含め、 必要に応じてmintimeと提案されるcurtimeの両方を調整するようになりました。 これは、コンセンサスクリーンアップソフトフォークのアクティベーションの可能性に備えてすべてのネットワークに適用されますが、 コンセンサスの検証は変更されません。

  • ● Bitcoin Core #34931は、デシリアライズできないUTXOデータベースのエントリーが存在しないコインとして扱われるバグを修正しました。 その結果、読み取り不能なコインを使用する有効なブロックが誤って永続的に無効とマークされ、 影響を受けたノードがネットワークのベストチェーンに追従できなくなる可能性がありました。 Bitcoin Coreはこれらの結果を区別するようになり、デシリアライズに失敗した場合はデータベースエラーとして処理を中断するようになります。 LevelDBのチェックサムが通常のディスク破損をすでに検出するため、このバグが発生するには、 保存前に別のコインのシリアライズのバグやメモリ破損が必要でした。

  • ● Bitcoin Core #36048は、Windows以外のシステムにおける-walletnotify 設定オプション（ニュースレター #86参照）を介したコマンドインジェクションを修正しました。 認証済みのRPC呼び出し元は、createwalletコマンドを使って細工した名前のウォレットを作成できました。 オペレーターがウォレット名のプレースホルダー%wを使って-walletnotifyオプションを設定していた場合、 そのウォレットに対するその後のトランザクション通知によって、 ウォレット名に埋め込まれたコマンドがノードのオペレーティングシステム上で実行される可能性がありました。 ウォレット名はシェルエスケープされていましたが、置換関数がその中の正規表現の置換文字を解釈してしまい、 シェルのクォートが壊れていました。プレースホルダーの置換ではウォレット名が文字どおりに扱われるようになり、 シェルエスケープが維持されます。この挙動はBitcoin Core 24.0で導入されたものです。

  • ● Bitcoin Core #36123および#36169は、 新しいHTTPサーバー（ニュースレター#411および#420参照）における無制限のメモリ増加と Windows環境でのポート共有の問題を修正しました。1つめのPRは、サーバーの処理能力を超える速度でリクエストを送信することで、 クライアントがサーバーの接続ごとの受信バッファを際限なく拡大させるのを防ぎます。バッファリングされたリクエストが処理待ちの間は ソケットの読み取りが一時停止され、TCPのバックプレッシャー機能によって送信者の速度が抑制されます。 2つめのPRは、Windowsのリスニングソケットに対してアドレスとポートを排他的に確保します。これまでは、 別のローカルプロセスが同じエンドポイントにバインドし、RPCの認証情報を含む接続を受信する可能性がありました。 あるレビュアーのテストでは、90秒間で16個のREST接続によるメモリ使用量の増加が、 バッファリングの修正前は3.2GBだったのに対し、修正後はわずか3MBでした。

  • ● Bitcoin Core #36176は、動的設定ファイルが-nosettingsオプションで無効化されている状態で、 ウォレット操作が起動時のロード設定を保存しようとした際に発生するエラーを修正しました。 ウォレットの作成、ロード、アンロード時に、ユーザーは次回起動時にそのウォレットを自動的にロードするかどうかも指定できます（ ニュースレター #111参照）。これまでは、設定が無効な状態でこの設定を保存しようとすると、 ウォレットの状態がすでに変更された後に、RPCエラーが発生するか、Bitcoin-Qtがキャッチされない例外でクラッシュしていました。 現在は、設定を保存できなかったという警告を出して操作が完了します。

  • ● Core Lightning #9434および#9473は、 askrene（ニュースレター #316参照）における永続的なルーティング設定に関連するクラッシュを修正しました。 askreneはルーティング情報をレイヤー単位で保存し、そこには特定のノードやチャネルを優先または回避するバイアスを含めることができます（ ニュースレター #381参照）。1つめのPRは、永続レイヤーから説明付きのノードバイアスを復元する際に発生していた起動時のクラッシュを修正しました。 これまでは、受信側と送信側のバイアス値を復元する際に、解放済みの説明用バッファを再利用していたため、 askreneがクラッシュし、lightningdはaskreneを重要なプラグインとして扱っているためシャットダウンしていました。 2つめのPRは、チャネルまたはノードのバイアスをゼロにリセットして削除する際のクラッシュを修正しました。 これまでは、値がゼロのバイアスレコードが保存される前にメモリから削除され、ヌルポインタ参照が発生していました。 現在はレコードがメモリから削除される前にゼロ値が保存されるため、再起動後に以前のバイアスが復元されることもなくなります。

  • ● LND #11061は、BIP340のSchnorr署名を使ったインボイスリクエストとインボイスの署名および検証のサポートを追加し、 BOLT12オファーの実装を継続しています。これらの署名は、メッセージの署名対象のTLVレコードから構築されたマークルルートにコミットします。 読み取り時のバリデーターは、署名が存在するかどうかを確認するだけでなく、無効な署名を拒否するようになりました。 これはニュースレター #413で説明したインボイスリクエストのコーデックに基づいています。

  • ● LND #11125は、呼び出し元がウォレットのUTXOを、それを使用するトランザクションが指定した承認数に達するまで予約できるようにしました。 これまでは、予約は指定した時間の経過後に期限切れになるか、使用するトランザクションの最初の承認時に解除されていました。 そのため、承認が遅い場合は予約より長引く可能性があり、一方で再編成が発生するとインプットが予約されていない状態になる可能性がありました。 現在は、LeaseOutput（ニュースレター #182参照）およびFundPsbt RPCが承認数を受け付けるようになり、 予約を再編成をまたいで有効なまま維持し、時間ベースの期限切れを無視できるようになりました。 呼び出し元は引き続き予約を明示的に解除でき、トランザクションを放棄した場合はこれが必要です。 既存の時間ベースの予約はデフォルトの動作として維持されます。

  • ● LND #11064は、BOLT2で要求されているとおり、チャネル開設メッセージでチャネルタイプを明示的に指定するようにしました。 LNDはopen_channelにchannel_typeを含め、accept_channelでそれをエコーし、 channel_typeを省略した受信open_channelメッセージを拒否するようになりました。 RPCの呼び出し元は引き続きタイプを省略でき、その場合LNDは両ピアがサポートするチャネルタイプに基づいてタイプを選択します。

  • ● BTCPay Server #7561および#7542は、APIキーの保存と処理の方法を更新しました。 1つめのPRは、平文の認証情報をデータベースに無期限に保存する代わりに、ハッシュと導出されたキーIDを保存するようにしました。 クリーンアップジョブは、新たに作成された平文のシークレットを5分経過後に消去します。 移行後も既存のGreenfieldキーは引き続き認証に使用できますが、そのシークレットをサーバーから取得することはできなくなります。 このアップグレードでは、レガシーなBitPay風のBasic認証APIキーも削除され、その認証方式も廃止されます。 指定したAPIキーの失効にはシークレットではなくIDが必要になり、キーのレスポンスにはidフィールドが含まれるようになりました。 2つめのPRは、APIキー管理ページへのリダイレクトURLから新しく生成されたAPIキーを削除し、 ブラウザの履歴やリクエストログを通じてURLから認証情報が漏洩するのを防ぎます。

  • ● BTCPay Server #7559は、ライトニング支払いの監視を、BTCPayインボイスの支払い期限を超えて、 設定された監視期間まで延長しました。これまでは、BTCPayインボイスの期限切れ後に顧客がライトニングインボイスを支払うことができても、 BTCPayはその支払いを記録しませんでした。現在は、リスナーが既存の監視期間を使用するため、 その期間中に受け取った遅延支払いを記録できます。これはどちらのインボイスの支払い期限も変更せず、 支払いを無期限に検出するものでもありません。