今週のニュースレターでは、サイレントペイメント用の軽量クライアントプロトコルの提案と、 Taproot用の2つの新しいディスクリプターの提案、 重複する機能を持つopcodeをソフトフォークで追加するかどうかについての議論のリンクを掲載しています。 また、Bitcoin Stack Exchangeから人気のある質問とその回答、新しいリリースとリリース候補の発表、 人気のBitcoinインフラストラクチャの注目すべき変更を含む恒例のセクションも含まれています。

ニュース

  • ● サイレントペイメント用の軽量クライアント: Setor Blagogeeは、軽量クライアントがサイレントペイメント（SP）を受け取るための プロトコルのドラフト仕様をDelving Bitcoinに投稿しました。 いくつかの暗号プリミティブを追加するだけで、どんなウォレットソフトウェアでもSPを送信できるようになりますが、 サイレントペイメントを受信するためには、それらのプリミティブだけでなく、 SPと互換性のあるすべてのオンチェーントランザクションに関する情報にアクセスする機能も必要です。 これは、Bitcoin Coreなど、すでにすべてのオンチェーントランザクションを処理しているフルノードにとっては簡単ですが、 通常、要求するトランザクションデータの量を最小限にしようとすると軽量クライアントには追加の機能が必要です。

    基本プロトコルでは、サービスプロバイダーがSPで使用できる公開鍵のブロックごとのインデックスを構築します。 クライアントは、そのインデックスと、同じブロックのコンパクトブロックフィルターをダウンロードします。 クライアントは各鍵（または鍵のセット）のローカルtweakを計算し、ブロックフィルターに対応する調整された鍵への支払いが含まれているかどうかを判断します。 含まれている場合は、ブロックレベルのデータを追加でダウンロードして、受け取った金額と、 後で支払いで使用する際の方法を知ることができます。

  • ● RAW Taprootディスクリプター: Oghenovo Usiwomaは、 Taprootの使用条件を構築するために提案された2つの新しいディスクリプターについて Delving Bitcoinに投稿しました。

    • rawnode(<hash>)は、内部ノードまたはリーフノードのマークルツリーノードのハッシュを引数にとります。 これにより、ウォレットや他のスキャンプログラムは、使用するTapscriptを正確に知らなくても、 特定のアウトプットスクリプトを見つけることができます。これは、ほとんどの状況において、 お金を受け取る上で安全ではありません。未知のスクリプトは、使用できなかったり、第三者が資金を使用できる可能性があります。 しかし、安全なプロトコルもあります。

      Anthony Townsは、アリスがボブに自分の資金を相続できるようにしたいという例を示しています。 アリスの使用条件ではアリスはノードハッシュのみをボブに提供し、 ボブの相続条件ではアリスは彼に（おそらく一定期間が経過するまで使用できないようにするタイムロックを含む） テンプレート化されたディスクリプターを提供します。 これは、ボブにとっては資金は彼のものではないため安全です。 ボブに他の使用条件を事前に明かす必要がないためアリスのプライバシーにも適しています（ただし、 ボブはアリスのオンチェーントランザクションからそれらを知る可能性があります）。

    • rawleaf(<script>,[version])は、 テンプレート化されたディスクリプターを使って表現できないスクリプトを含めるための既存のrawディスクリプターに似ています。 主な違いは、BIP342で定義されているTapscriptのデフォルトとは異なる Tapleafバージョンを示す機能が含まれている点です。

    Usiwomaの投稿には、以前の議論と彼が作成した参照実装への例とリンクが記載されています。

  • ● 重複するソフトフォークの提案は相互に排他的であるべきか？ Pierre Rochardは、同様のコストで同じ機能の多くを提供できるソフトフォークの提案は相互に排他的であると考えるべきなのか、 それとも複数の提案を有効化して開発者が好きな方を使えるようにするのが理にかなっているのか、質問しています。

    Anthony Townsは、重複する機能それ自体は問題ではないが、 誰もが代替案を好むことで使用されない機能は、いくつかの問題を引き起こす可能性があることを示唆するなど、 複数のポイントに回答しています。彼は、 特定の提案に好意的な人は、試作段階のソフトウェアを使用してその機能をテストし、 特にその機能をBitcoinに追加できる他の方法と比較して、その使い勝手を確かめることを提案しています。

Bitcoin Stack Exchangeから選ばれたQ&A

Bitcoin Stack ExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。

リリースとリリース候補

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

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

今週の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 #29612は、dumptxoutset RPCを使用したUTXOセットのダンプ出力のシリアライゼーションフォーマットを更新しました。 これにより、17.4%のスペースの最適化が実現します。loadtxoutset RPCは、 UTXOセットのダンプファイルをロードする際にこの新しい形式を期待し、古い形式はサポートされなくなりました。 以前のdumptxoutsetに関してはニュースレター#178および#72をご覧ください。

  • ● Bitcoin Core #27064は、Windowsのデフォルトのデータディレクトリを、 新規インストールの場合のみ、C:\Users\Username\AppData\Roaming\Bitcoinから C:\Users\Username\AppData\Local\Bitcoinに変更しました。

  • ● Bitcoin Core #29873は、TRUC（Topologically Restricted Until Confirmation）トランザクション（v3トランザクション）に10kvBのデータweight制限を導入し、 トランザクションPinning攻撃の潜在的な緩和コストを削減し、 ブロックテンプレート構築の効率を向上し、特定のデータ構造に厳しいメモリ制限を課します。 v3トランザクションは、標準トランザクションのサブセットで、トランザクションPinning攻撃を克服するコストを最小限に抑えながら、 トランザクションの置換を可能にするよう設計された追加ルールを備えています。 v3トランザクションの詳細については、ニュースレター#289および#296をご覧ください。

  • ● Bitcoin Core #30062は、ピアノードのネットワークアドレスに関する情報を返すコマンドである getrawaddrman RPCに2つの新しいフィールドmapped_asとsource_mapped_asを追加しました。 新しいフィールドは、ピアとそのソースにマップされたASN（自律システム番号）を返します。 これにより、どのISPがどのIPアドレスを管理しているかに関するおおよその情報が提供され、 Bitcoin Coreのエクリプス攻撃に対する耐性が向上します。 ニュースレター#52、#83、#101、#290もご覧ください。

  • ● Bitcoin Core #26606は、Berkeleyデータベース（BDB）ファイルパーサーの独立した実装である BerkeleyRODatabaseを導入しました。これにより、BDBファイルへの読み取り専用アクセスが提供されます。 重いBDBライブラリを必要とせずに、レガシーウォレットのデータを抽出できるようになり、 ディスクリプターウォレットへの移行が容易になります。 wallettoolのdumpコマンドは、BerkeleyRODatabaseを使用するように変更されました。

  • ● BOLTs #1092は、使用されておらずサポートされなくなった機能initial_routing_syncと option_anchor_outputsを削除してライトニングネットワーク（LN）の仕様を整理しました。 次の3つの機能は、現在すべてのノードに存在するものと想定されています： 任意のデータを特定のホップにリレーする可変サイズのOnionメッセージのためのvar_onion_optin、 ノードが再接続時に最新のチャネル状態に関する情報を要求するためのoption_data_loss_protect、 ノードがチャネルの更新の度にノードの非HTLC資金を同じアドレスに送信するようコミットするoption_static_remotekey。 特定のゴシップ要求のためのgossip_queries機能が変更され、 これをサポートしていないノードは、他のノードから照会を受け付けないようになりました。 ニュースレター#259参照。