今週のニュースレターでは、ウォレットとデバイス間の通信が1往復のみで済む流出防止プロトコルに関する議論を掲載しています。 また、クライアントとサービスのアップデートや、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの最近の変更など恒例のセクションも含まれています。

ニュース

  • ● シンプルな（ただし不完全な）流出防止プロトコル: 開発者のMoonsettlerは、 流出防止プロトコルの説明を Delving Bitcoinに投稿しました。 同じプロトコルは以前にも紹介されています（ニュースレター#87および#88参照）。 Pieter Wuilleは、流出防止技術に関する最も古い説明として、 Gregory Maxwellによる2014年の投稿を挙げています。

    このプロトコルは、sign-to-contractプロトコルを使用して、 ソフトウェアウォレットがハードウェア署名デバイスによって選択されたnonceにエントロピーを付与できるようにします。 これによりソフトウェアウォレットは、後でエントロピーが使用されたことを検証できます。 sign-to-contractは、pay-to-contractのバリエーションです。 pay-to-contractでは受信者の公開鍵が調整され、sign-to-contractでは送信者の署名nonceが調整されます。

    このプロトコルの利点は、BitBox02やJadeハードウェア署名デバイス用に実装されたプロトコル（ニュースレター #136参照）と比べて、ソフトウェアウォレットとハードウェア署名デバイス間の通信が1往復で済むことです。 この1往復は、シングルシグまたはスクリプト化されたマルチシグトランザクションに署名するために必要な他の手順と組み合わせることができるため、 この手法はユーザーのワークフローに影響を与えません。現在展開されている手法も、 sign-to-contractに基づいており、2往復が必要です。これは今日のほとんどのユーザーにとって必要以上ですが、 スクリプトレスマルチシグや スクリプトレス閾値署名を使用するようにアップグレードするユーザーの場合は、 複数の往復が必要になる場合があります。署名デバイスをコンピューターに直接接続するユーザーや、 Bluetoothなどの双方向のワイヤレス通信プロトコルを使用するユーザーにとっては、往復の回数は問題になりません。 ただし、デバイスをエアギャップにしておきたいユーザーの場合、各往復に2回の手動介入が必要になります。 これは、頻繁に署名する場合や、スクリプト化されたマルチシグ用に複数のデバイスを使用したりする場合には、 すぐに煩わしい作業量になります。

    このプロトコルの欠点は、Maxwellが彼の最初の説明で言及したとおりで、 「グラインディングにより追加ビットあたりのコストが指数関数的に増加するサイドチャネル攻撃は残りますが、 […]単一の署名ですべてが漏洩される明白で非常に強力な攻撃は排除することができます。 これは明らかに完全とは言えませんが、2回のプロトコルであるため、対策の使用を検討しない多くの場所で、 プロトコル仕様の要素としてこれを追加コストなしで採用できます。」

    このプロトコルは、流出防止をまったく使用しない場合に比べて明らかにアップグレードされており、 Pieter Wuilleは、これがおそらく1ラウンド署名による流出防止としては最善であると指摘しています。 ただし、Wuilleは、グリンディングベースの流出さえも防止するため、2ラウンドの流出防止プロトコルを推奨しています。

    この記事の執筆時点では、議論は進行中です。

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

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

  • ● Proton Walletの発表: Protonは、複数のウォレットやbech32、バッチ送金、 BIP39ニーモニックおよび彼らのメールサービスとの統合をサポートするオープンソースの Proton Walletを発表しました。

  • ● CPUNet testnetの発表: braidpoolマイニングプールプロジェクトのコントリビューターが、 テストネットワークCPUNetを発表しました。 CPUNetは、一般的なtestnetよりも一貫したブロックレートを実現することを目的として、 ASICマイナーを除外するために変更されたproof-of-workアルゴリズムを使用しています。

  • ● Lightning.Pubのローンチ: Lightning.Pubは、暗号化通信と鍵ベースのアカウントIDにnostrを使用し、 共有アクセスとチャネルの流動性の調整を可能にするLNDのノード管理機能を提供します。

  • ● Taproot Assets v0.4.0-alphaリリース: v0.4.0-alphaリリースは、オンチェーンでのアセットの発行と PSBTを使用したアトミックスワップおよびライトニングネットワークを介したアセットのルーティングを mainnetで実現するTaproot Assetsプロトコルをサポートします。

  • ● Stratum v2ベンチマークツールのリリース: 最初の0.1.0リリースでは、さまざまなマイニングシナリオにおける Stratum v1とStratum v2プロトコルのパフォーマンスのテスト、 レポート、比較をサポートします。

  • ● signetでのSTARK検証PoC: StarkWareは、signetテストネットワーク上でOP_CAT opcodeを使用して（ ニュースレター #304参照）ゼロ知識証明を検証するSTARK verifierを発表しました。

  • ● SeedSigner 0.8.0リリース: Bitcoinハードウェア署名デバイスプロジェクトのSeedSignerは、 0.8.0リリースで、P2PKHおよびP2SHマルチシグの署名機能、 追加のPSBTをサポート、デフォルトでTaprootサポートを有効にしました。

  • ● Floresta 0.6.0リリース: 0.6.0では、Florestaはコンパクトブロックフィルター、 signetでのFraud Proofおよび、既存のウォレットやクライアントアプリケーションに統合するためのデーモンである florestadのサポートを追加しました。

リリースとリリース候補

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

  • ● Core Lightning 24.08rc2は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。

  • ● LND v0.18.3-beta.rc1は、この人気のLNノード実装の軽微なバグ修正のリリース候補です。

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

最近の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 #28553は、mainnetのブロック840,000のassumeUTXO スナップショットパラメーター（ブロックハッシュ、そのブロックまでのトランザクション数、 そのブロックまでのシリアライズされたUTXOセットのSHA256ハッシュ）を追加します。 これは、複数のコントリビューターによるテストの結果で、期待されるSHA256チェックサムを持つ 同じスナップショットファイルを再現でき、スナップショットがロードされると正常に機能することが確認されています。

  • ● Bitcoin Core #30246は、asmap-toolユーティリティにdiff_addrsサブコマンドを導入し、 ユーザーがASMap（自律システム）の2つのマップを比較し、 異なるAS番号に再割り当てされたノードネットワークアドレスの数に関する統計を計算できるようにします。 この機能は、時間の経過と共にASMapが劣化する度合いを定量化します。これは、 Bitcoin Coreのリリースで事前計算されたASMapを出荷し、 Bitcoin Coreのエクリプス攻撃に対する耐性をさらに高めるための重要なステップです。 ニュースレター#290をご覧ください。

  • ● Bitcoin Core GUI #824は、Migrate Walletメニューの項目を単一のアクションからメニューリストに変更し、 ユーザーが、ロードできないウォレットを含む、ウォレットディレクトリ内の任意のレガシーウォレットを移行できるようにします。 この変更は、ディスクリプターウォレットがデフォルトになり、 レガシーウォレットがBitcoin Coreにロードできなくなる可能性がある将来に備えたものです。 移行するウォレットを選択する際、ウォレットにパスフレーズがある場合、GUIがユーザーにその入力を求めます。

  • ● Core Lightning #7540は、ネットワーク内でランダムに選択されたチャネルが少なくとも1 msatを転送できる確率を表す 定数乗数を追加することで、renepayプラグイン（ニュースレター#263参照）で チャネルを経由してルーティングが成功する確率を計算する式を改善します。 デフォルト値は0.98に設定されていますが、これは今後さらにテストを行った後に変更される可能性があります。

  • ● Core Lightning #7403は、非常に低いmax_htlcを持つチャネルを無効にする チャネルフィルタリングペイメント修飾子をrenepayプラグインに追加します。 これは、将来拡張され、他の理由で望ましくないチャネル（基本手数料が高い、キャパシティが低い、 高レイテンシーなど）を除外できます。さらに、手動でノードやチャネルを無効にするための 新しいexcludeコマンドラインオプションが追加されました。

  • ● LND #8943は、コードベースにAlloyを導入しました。これは、LND #8751のバグ修正に触発されたもので、 Linear Fee Functionの手数料引き上げメカニズム用の最初のAlloyモデルから始まります。 Alloyは、システムコンポーネントの正しさを検証するための軽量な形式手法を提供し、 初期実装中にバグを見つけやすくします。本格的な形式手法のようにモデルが常に正しいことを証明しようとするのではなく、 Alloyは制限されたパラメーターのセットと反復の入力に基づいて動作し、 優れたビジュアライザーと共に、特定のアサーションに対する反例を見つけようとします。 モデルは、P2Pシステムでプロトコルを定義するためにも使用できるため、ライトニングネットワークに特に適しています。

  • ● BDK #1478は、bdk_chainクレートのFullScanRequestおよびSyncRequestのリクエスト構造をいくつか変更します。 リクエストの構築と使用を分離するビルダーパターンを使用し、 chain_tipパラメーターをオプションにしてユーザーがLocalChainの更新をオプトアウトできるようにし（ LocalChainなしでbdk_esploraを使用している場合に便利です）、同期の進行状況を確認する際の人間工学を改善します。 さらに、bdk_esploraクレートは、TxGraphの更新に常に以前のトランザクションアウトプットを追加し、 /tx/:txidエンドポイントを使用してAPI呼び出し回数を削減することで最適化されています。

  • ● BDK #1533は、Wallet::create_singleメソッドを追加することで、 単一のディスクリプターウォレットのサポートを有効にし、 Wallet構造に内部（お釣り）ディスクリプターが必要になった以前の更新を元に戻しています。 以前の変更の理由は、パブリックなElectrumまたはEsploraサーバーに依存する際に、 ユーザーのお釣り用のアドレスのプライバシーを保護するためでしたが、 すべてのユースケースを含むよう元に戻されています。

  • ● BOLTs #1182は、BOLT4仕様のルートブラインドと Onionメッセージのセクションの明確さと完全性を向上させるために以下の変更を加えました。 ルートブラインドのセクションを1レベル上に移動して、（Onionメッセージだけではない）支払いへの適用性を強調し、 blinded_path型とその要件についてより具合的な詳細を提供し、 blinded_pathのライターの責任と説明を拡張し、blinded_pathのリーダーのセクションをblinded_pathとencrypted_recipient_dataの別々の部分に分離し、 blinded_pathのコンセプトの説明を改善し、ダミーホップの使用を推奨し、 onionmsg_hopの名前をblinded_path_hopに変更し、その他の明確化のための変更を加えました。

  • ● BLIPs #39は、受信側のノードに支払うためのブラインドパスを伝えるために BOLT11インボイスにオプションフィールドbを追加するBLIP39を追加しました。 これはLNDに実装されており（ニュースレター#315参照）、 オファープロトコルがネットワークで広く展開されるまで使用することを目的としています。