今週のニュースレターでは、ウォレットのフィンガープリンティングがPayjoinのプライバシーを損なう仕組みと、 ウォレットバックアップメタデータ形式に関する提案を掲載しています。また、 Bitcoinのコンセンサスルールの変更に関する提案のまとめや、新しいリリースとリリース候補の発表、 人気のBitcoin基盤ソフトウェアの注目すべき変更など、恒例のセクションも掲載しています。

ニュース

• ● Payjoinプライバシーにおけるウォレットのフィンガープリンティングリスク: Armin Sabouriは、 Payjoin実装間の差異がPayjoinトランザクションのフィンガープリンティングを可能にし、 Payjoinのプライバシーを損なう仕組みについてDelving Bitcoinに投稿しました。

  Sabouriは、Payjoinトランザクションは標準的な単一当事者のトランザクションと区別がつかないように見えるべきだと述べています。 しかし共同トランザクションの痕跡が残る場合があります。

  • トランザクション内

    • 単一のトランザクション内でインプットとアウトプットを所有者毎に分割する。

    • インプットのエンコーディングの違い。

    • インプットのbyte長。

  • トランザクション間

    • 後方: 各インプットは、それ自身のフィンガープリントを持つ以前のトランザクションによって作成されている。

    • 前方: 各アウトプットは、将来のトランザクションで使用される可能性があり、フィンガープリントが露出する。

  続いてSabouriは、Samourai、PDKデモ、Cake Wallet（Bull Bitcoin Mobileへの送金）の３つのPayjoin実装をレビューし、 それぞれにフィンガープリンティングを可能にする相違点を発見しています。具体的には以下のものが含まれます（ただしこれらに限りません）:

  • インプットの署名エンコードの違い。

  • SIGHASH_ALL byteが一方には含まれるが、もう一方には含まれない。

  • アウトプット金額の割り当て

  Sabouriは、これらのウォレットフィンガープリントの一部は取り除くことが容易である一方、 特定のウォレットの設計上の選択に起因するものもあると結論づけています。 ウォレット開発者は、Payjoinを実装する際にこうしたプライバシーの漏洩の可能性を認識しておくべきだとしています。

• ● ウォレットバックアップメタデータ形式に関するBIPドラフト: Pythcoinerは、 ウォレットバックアップメタデータの共通構造に関する新しい提案をBitcoin-Devメーリングリストに投稿しました。 BIPs #2130で公開されているこのBIPドラフトは、アカウントディスクリプターや鍵、ラベル、 PSBTなどさまざまな種類のメタデータを標準的な方法で保存する仕様を策定し、 異なるウォレット実装間の互換性確保や、ウォレットの移行・復元プロセスの簡素化を目的としています。 Pythcoinerによると、エコシステムには共通仕様が存在しておらず、本提案はそのギャップを埋めることを目指しています。

  技術的な観点では、提案されている形式は、バックアップ構造を表す単一の有効なJSONオブジェクトを含む UTF-8エンコードされたテキストファイルです。BIPにはJSONオブジェクトに含めることができる各フィールドが列挙されており、 それらはすべてオプションであることが明記されています。また、 各ウォレット実装は有用でないと判断したメタデータを自由に無視できるものとされています。

コンセンサスの変更

Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション

• ● コンパクトな同種写像PQCはHDウォレット、鍵の調整、サイレントペイメントを置き換え可能: Conduitionは、ポスト量子暗号システムとして 同種写像ベース暗号（IBC）のBitcoinへの適用可能性に関する研究をDelving Bitcoinに投稿しました。 楕円曲線の離散対数問題（ECDLP）は、ポスト量子の世界では安全でなくなる可能性がある一方、 楕円曲線の数学そのものに根本的な欠陥があるわけではありません。簡単に言うと、 同種写像とはある楕円曲線から別の楕円曲線へのマッピングです。IBCの暗号学的仮定は、 特定の種類の楕円曲線間の同種写像を計算することは困難である一方、 基底曲線から同種写像とそのマッピング先の曲線を生成することは容易であるという点にあります。 したがって、IBCにおける秘密鍵は同種写像であり、公開鍵はマッピング後の曲線となります。

  ECDLPの秘密鍵と公開鍵のように、同じソルト（例：BIP32の導出ステップ）から新たな秘密鍵と公開鍵を独立して計算し、 導出された秘密鍵が導出された公開鍵に対して正しく署名することが可能です。Conduitionはこれを 「再ランダム化（rerandomization）」と呼んでおり、これによってBIP32、BIP341およびBIP352が （おそらく追加の暗号技術的な工夫を伴いつつも）根本的に実現可能になるとしています。

  現時点では、IBC向けのMuSigやFROSTのような署名集約プロトコルは存在しておらず、 conduitionは、Bitcoin開発者と暗号学者に対し、その可能性を研究するよう呼びかけています。

  既知のIBC暗号システムにおける鍵と署名のサイズは、ECDLPに依存する暗号システムの鍵の約2倍ですが、 ハッシュベースや格子ベースの暗号システムよりははるかに小さいものです。検証コストは、 デスクトップマシンでも高く（1回の検証あたり1ミリ秒程度）、ハッシュベースや格子ベースと同程度の水準です。

• ● VaropsバジェットとTapscriptリーフ 0xc2（Script Restoration）がBIP 440および441に: Rusty Russellは、Great Script Restoration（またはGrand Script Renaissance）の最初の２つのBIPが、 BIP番号の割り当てのために提出されたことをBitcoin-Devメーリングリストに投稿しました。 これらはそれぞれBIP 440およびBIP 441として番号が付与されました。BIP440は、 各操作コストの会計システムを構築することで、以前無効化されたScriptのopcodeを復元します。 この会計システムは、ワーストケースのブロックレベルのスクリプト検証コストが、 ワーストケースの署名操作数のブロックの検証コストを超えないようにします。BIP441は、 2010年にサトシによって無効化されたopcodeを復元する新しいTapscriptバージョンの検証について説明しています。

• ● SHRIMPS: 複数のステートフル署名デバイス間で2.5KBのポスト量子署名: Jonas Nickは、ポスト量子Bitcoinに向けた新しい準ステートフルなハッシュベース署名について Delving Bitcoinに投稿しました。SHRIMPSは、 SPHINCS+の署名サイズが、特定のセキュリティレベルを維持しつつ生成可能な署名の最大数に応じてスケールする という特性を活用しています。

  SHRINCSの設計と同様に、SHRIMPSの鍵は2つの鍵をハッシュして組み合わせたものです。 この場合、両方の鍵はステートレスなSPHINCS+の鍵ですが、パラメーターセットが異なります。 1つめの鍵は少数の署名に対してのみ安全で、その鍵を使用する各署名デバイスにおける最初（または最初の数回）の署名に使用することを意図しています。 2つめの鍵はより多数の署名（Bitcoinの文脈では事実上無制限）に対して安全で、 各デバイスはそのデバイスからの署名が一定回数（ユーザーが選択可能な場合もあり）を超えたら、この鍵にフォールバックします。 その結果、単一のシードから多数導出できる任意の鍵が少数回しか署名しないというBitcoinの一般的なユースケースにおいては、 ほぼすべての署名を2.5KB未満に抑えることができます。一方で、鍵が何度も再利用された場合でも、署名総数に実質的な上限はなく、 その代わりに後続の署名は約7.5KBになります。SHRIMPSが準ステートフルと呼ばれるのは、グローバルな状態を保持する必要はないものの、 各署名デバイスが署名に使用するSHRIMPS鍵毎に数bitの状態を記録しなければならないからです（各デバイスと鍵ペアにおける最初の署名のみが 小さい署名サイズの恩恵を受ける場合は、1 bitで済みます）。

リリースとリリース候補

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

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

• ● Core Lightning 26.04rc2は、この人気のLNノードの次期メジャーバージョンの最新のリリース候補で、 以前のリリース候補からスプライシングの更新とバグ修正が続いています。

• ● BTCPay Server 2.3.7は、このセルフホスト型のペイメントソリューションのマイナーリリースで、 プロジェクトを.NET 10に移行し、サブスクリプションとインボイスのチェックアウト機能を改善し、 その他いくつかの機能強化とバグ修正を行っています。プラグイン開発者は、 アップデート時にプロジェクトの.NET 10移行ガイドに従ってください。

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

最近の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 #32297は、bitcoin-cliに-ipcconnectオプションを追加します。 これにより、Bitcoin CoreがENABLE_IPCでビルドされ、ノードが-ipcbind（ ニュースレター#320および#369参照）で起動されている場合、 HTTPの代わりにUnixソケット経由のプロセス間通信（IPC）を使ってbitcoin-nodeインスタンスに接続し、制御できるようになります。 -ipcconnectを省略した場合でも、bitcoin-cliはまずIPCを試み、IPCが利用できない場合はHTTPにフォールバックします。 これは、マルチプロセス分離プロジェクトの一部です。

• ● Bitcoin Core #34379は、ウォレットに秘密鍵の一部しか持たないディスクリプターが含まれている場合に、 gethdkeys RPC（ニュースレター #297参照）をprivate=trueで呼び出すと失敗するバグを修正します。 listdescriptorsの修正（ニュースレター #389参照）と同様に、 このPRは利用可能な秘密鍵を返します。なお、完全な監視専用ウォレットに対して、gethdkeys private=trueを呼び出した場合は、 引き続き失敗します。

• ● Eclair #3269は、アイドル状態のチャネルから自動的な流動性回収機能を追加します。 PeerScorerが両方向の合計支払い量がチャネルキャパシティの5%を下回ったことを検知すると、 中継手数料を設定済みの最小値に向けて段階的に引き下げます。 手数料が最低5日間最小値になったままでも取引量が回復しない場合、Eclairは当該ピアとの冗長なチャネルを閉鎖します。 チャネルが閉鎖されるのは、ノードが資金の少なくとも25%を保有し、かつローカル残高が既存の localBalanceClosingThreshold設定を超えている場合に限られます。

• ● LDK #4486は、rbf_channelエンドポイントをsplice_channelにマージし、 新規のスプライスとインフライトスプライスの手数料引き上げの両方に対応する単一のエントリーポイントとして提供します。 スプライスが既に進行中の場合、splice_channelから返されるFundingTemplateにはPriorContributionが含まれるため、 ユーザーは新しいコイン選択をすることなくスプライスをRBFできます。 スプライスのRBFの動作については、ニュースレター #397をご覧ください。

• ● LDK #4428は、新しいcreate_channel_to_trusted_peer_0reserveメソッドにより、 信頼済みのピアとのゼロチャネルリザーブでのチャネル開設・受け入れのサポートを追加します。 ゼロリザーブチャネルは、相手方がチャネル内のオンチェーン残高を全額使用することが可能です。 これは、アンカーアウトプットを使用するチャネルとゼロ手数料コミットメントチャネル（ ニュースレター #371参照）の両方で有効です。

• ● LND #9982、#10650、#10693は、 TaprootチャネルにおけるMuSig2ナンスのワイヤーハンドリングを強化します。 ChannelReestablishにLocalNoncesフィールドが追加され、 ピアがスプライス関連の更新に複数のナンスを調整できるようになります。 lnwireはナンスを含むメッセージのTLVデコード時にMuSig2公開ナンスを検証し、 LocalNoncesDataのデコードでは各ナンスエントリーが検証されます。

• ● LND #10063は、RBF協調閉鎖フローをMuSig2を使用した Simple Taproot Channelに拡張します。 ワイヤーメッセージはTaproot固有のナンスと部分署名フィールドを持ち、 閉鎖の状態マシンはshutdown、closing_complete、closing_sigの各段階で、 ジャストインタイムのナンスパターンを持つMuSig2セッションを使用します（RBF協調閉鎖フローの背景については、 ニュースレター #347をご覧ください）。