en | ja | es | cs | hi | zh | de | fr | pt

Bitcoin Optech Newsletter #406

May 22, 2026

今週のニュースレターでは、BIP322の汎用署名メッセージフォーマットの更新に関する議論のリンクと、 NATの背後にあるBitcoinノードがインバウンド接続を受け入れられるよう支援するために TCPホールパンチングを利用するというアイデアを掲載しています。また、サービスやクライアントソフトウェアの最近の更新や、人気のあるBitcoin基盤ソフトウェアへの注目すべき更新など恒例のセクションも含まれています。

ニュース

● BIP322「Generic Signed Message Format」の重要な更新: Oliver Guggerは、 BIP322を完成形にするためのアイデアについてBitcoin-Devメーリングリストに投稿しました。 Guggerはbtcdでのサポートを実装する中で、いくつかの未解決の問題や提案の不備に気づきました。彼は提案に対して3つの主要な修正を提案しました:
- 3種類の署名を区別するための人間が読めるプレフィックス
- 「Proof of Funds(資金の証明)」版へのUTXO情報の含有
- PSBTベースのメッセージ署名のサポート
いくつかの議論を経て、PSBTの構築に関するフィードバックを取り込んだ後、BIP322への更新が公開されました（ニュースレター #405参照）。 GuggerはBIP322をComplete(完了)へと進め、仕様が安定し、実装準備が整ったことを示しました。この更新以降、Coldcardが3月にBIP322のサポートを出荷していたことが再び話題になりました。

以前のバージョンのBIP322のサポートを実装していたプロジェクトは、新しい人間が読みやすいプレフィックスや、改訂されたProof of Funds署名フォーマットなど、互換性を損なう変更が導入された更新仕様との互換性を確認する必要があります。
● NATの背後にあるBitcoinノードのためのTCPホールパンチング: 0xB10C は、家庭用ルーターのNATの背後にあるより多くノードが、インバウンド接続を受け入れられるようにするためのアイデアについて、 Delving Bitcoinに投稿しました。この最初の構想は、Bitcoin Core v30.0以降で -natpmp=1をデフォルト設定しても、家庭用ISPにおける到達可能なノード数が期待どおりに増加しなかったという観察から生まれたものです。

このアイデアは、ホールパンチングを活用します。これは、特定の種類のNATの背後にある2つのホストが、サーバー経由でトラフィックを中継することなく直接接続できる技術です。プロセスは次のように動作します。到達不能な2つのホスト、アリスとボブが、第三者を介して自分たちの公開エンドポイント(つまり、IPアドレスとポート)を交換し、同時に互いへの接続を開始します。これによりNAT内にマッピングが作成され、ホストはハンドシェイクを完了して接続を確立できます。提案されている技術はノード間の正確な同期を必要とするTCP上で動作するため、UDPを使う同様の技術と比較すると障害率が高くなります。

0xB10Cは、BitcoinのP2Pプロトコルを使った実装に関する複数のアプローチに言及しました。 1つめのアプローチでは、ランデブーサーバーと呼ばれるブリッジが必要であり、これによってアリスとボブがエンドポイント情報を交換できます。このサーバーは、到達不能なホストが自身の接続スロットを提供できるようにするマッチメイキングサービスを提供することもできますし、空きインバウンドスロットの不足により既存の接続を削除する代わりに、既存の接続のうち1つを別のピアに引き継ぐことを決定することもできます。彼はまた、Tor/I2P下で直接ホールパンチングを実行し、接続確立のための第三者サーバーを不要にする方法についても説明しました。このアプローチでは、アリスが専用のTor/I2Pエンドポイントで待ち受けを開始し、そこにボブが接続してホールパンチングのプロセスを開始します。

この提案はまだ正式なものではなく、多くの疑問点が残されています。0xB10Cはコミュニティからのフィードバックを求め、ホールパンチ接続をどのように分類するか、TCPホールパンチングの信頼性、起こりうる攻撃、実装の労力といった多くの未解決点に対処するための議論を呼びかけました。

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

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

● Ibis Walletの発表: Ibis WalletはBDK上に構築されたAndroidウォレットで、コインコントロール、RBFおよびCPFPによる手数料管理、マルチシグ、 QRコードを用いたハードウェア署名デバイスとの統合、サイレントペイメント、そしてTorの統合をサポートします。また、Spark、Liquid、そして将来的にはArkを含むオプションのセカンドレイヤーもサポートします。
● LDK Serverの発表: SpiralはLDK Serverを発表しました。これは、ペイメントプロセッサーやウォレットプロバイダー向けにLDK Node上に構築されたAPIファーストのライトニングノードデーモンです。 gRPCインターフェース、組み込みのBDKベースのウォレット、そしてAIエージェントがノードと対話するための MCP（Model Context Protocol）サーバーを提供します。
● Mempool.space v3.3.0リリース: Mempool v3.3.0は、Taprootスクリプトツリーの可視化、更新されたPSBTプレビュー、手数料推定の改善、エフェメラル・ダストのサポート、古くなったブロックの比較、 sighashアイコン、merkle-proof APIなどの機能を追加しています。
● peer-observer のP2P監視ツール: 0xB10C は、自身のpeer-observer プラットフォームで使用されているいくつかのオープンソースコンポーネントを概説しました。これには、IPC、ログ、P2P、RPCのソースを使ってBitcoin Coreノードからイベントを抽出するためのインフラストラクチャが含まれます。彼はまた、アーカイブ、異常検知、アラートツールに関する継続的な開発についても説明しています。

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

最近の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 #29136は、指定されたBIP32拡張秘密鍵をインポートするか、指定がなければ生成する addhdkey RPCを追加します。これはアウトプットスクリプトの生成には使われません。これにより、ウォレットは即座にアドレスを生成することなく、将来の使用(例えばマルチシグスクリプト向け)のために署名鍵を保管できます。このPRはまた、保管された鍵をウォレットバックアップに含めることができるように、 listdescriptorsが返す新しいunused(KEY)ディスクリプター型も追加されています。
● Bitcoin Core #34893は、PSBTを結合する際にBIP174の独自フィールド（ニュースレター#72 および#181を参照)を保持するようcombinepsbt RPCを更新します。これまではcombinepsbtが独自フィールドを暗黙的に破棄しており、アプリケーション固有のPSBTメタデータが失われる結果となっていました。 decodepsbt RPCはすでにこれらのフィールドを適切にパース、シリアライズ、表示しています。
● Bitcoin Core #34860は、CreateNewBlock()メソッドからinclude_dummy_extranonce オプションを削除します(ニュースレター#392参照)。Bitcoin Core は、高さ0から16のブロックを作成する際、内部のコインベースscriptSigに常にダミーパディングを付加するようになりました。これらの高さでは、BIP34の高さエンコーディングだけではコンセンサス上の最小scriptSig長を満たせないためです。ただし、このパディングはMining IPCインターフェース経由で接続されたStratum V2クライアントに公開される CoinbaseTx構造体のscriptSigPrefixフィールドには含まれません(ニュースレター#310および#388参照)。
● Bitcoin Core #31298は、無関係なトランザクションを拒否するよう combinerawtransaction RPCを更新します。これまでは、最初のトランザクションを暗黙的に返し、それらがマージできなかったことを報告しませんでした。Bitcoin Coreは現在、各トランザクションからインプットのscriptSigとwitnessを取り除き、その結果得られる未署名トランザクションのハッシュを比較し、それらが一致しない場合はエラーを返します。
● Bitcoin Core #28802は、Bitcoin CoreのCLI引数パーサーであるArgsManagerに、コマンド固有のオプションのサポートを追加します。コマンドは、自身に適用されるオプションを宣言できるようになり、 ArgsManagerはそれらのオプションを関連するコマンドのヘルプ出力の下に列挙し、無効なコマンドとオプションの組み合わせを自動的に拒否できます。このPRは、これを bitcoin-wallet(ニュースレター #32参照)の-dumpfileオプションに適用しており、このオプションは現在dumpおよびcreatefromdumpコマンドに対してのみ登録されています。
● Eclair #3298は、低い手数料率でのBIP125の置換ルールへの準拠を保証するよう設計された新しい BOLT2の手数料率引き上げルールに従うよう、内部のRBFロジックを更新します。これまでの25/24手数料率乗数のみを適用する代わりに、Eclairはその乗数か、追加の25 sat/kwのいずれか大きい方を使用するようになりました。これは、ニュースレター#400で取り上げたLDKの挙動、およびニュースレター#404で取り上げたBOLT仕様の更新と一致します。
● LDK #4575は、チャネルに資金をスプライシングする際にユーザーが手動でUTXOを選択できるようにするsplice_in_inputs APIを追加します。選択されたUTXOは完全に消費され、その金額から手数料を差し引いた額がチャネルに追加され、お釣りのアウトプットは作成されません。これは既存の金額ベースのスプライスインフローを補完するものです。このフローでは、呼び出し側が追加する金額を指定し、ウォレットがインプットを選択します。ただし、 2つのインプット選択フローを同一の資金提供内で混在させることはできません。
● LND #10814は、バージョン0.21で削除予定とされていた非推奨のSendPayment、SendPaymentSync、 SendToRoute、SendToRouteSync、TrackPaymentエンドポイントを削除します(ニュースレター#340参照)。呼び出し側はV2の代替であるSendPaymentV2、SendToRouteV2、TrackPaymentV2を使用する必要があります。このPRはまた、非推奨の単一チャネルoutgoing_chan_idフィールドも削除し、呼び出し側に複数チャネル対応のoutgoing_chan_idsフィールドを使用することを要求します(ニュースレター #33参照)。
● Rust Bitcoin #6191は、Erlayのトランザクションリコンシリエーションで使用される sendtxrcncl P2Pメッセージのエンコードおよびデコードのサポートを追加します。Bitcoin Coreは Erlayサポートの初期対応の一部としてこのメッセージのサポートを追加しました(ニュースレター#223参照)。ただし、完全なErlayトランザクションリコンシリエーションはまだ実装されていません。
● BLIPs #42は、BOLT12の連絡先に関する仕様であるBLIP42を追加します。 BOLT12オファーは静的なライトニング支払い指示として再利用できるため、ウォレットはオファーを連絡先として保存できます。このBLIPは、支払人が連絡先への支払いを行う際に含めることができるオプションのinvoice_requestフィールド（連絡先シークレット、自身のオファー、BIP353名など）を定義します。これにより、受取人は既知の連絡先からの支払いを認識したり、新しい連絡先を追加したり、追加のやり取りなしに支払い側に資金を送り返したりすることができます。

もっと知りたいですか？

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