/ home / newsletters /
Bitcoin Optech Newsletter #305
今週のニュースレターでは、サイレントペイメント用の軽量クライアントプロトコルの提案と、 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達が疑問に対して答えを探しに(もしくは他のユーザーの質問に答える時間がある場合に)アクセスする、 数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・回答を紹介しています。
-
● コインベーストランザクション/ブロックの最小サイズは? Antoine Poinsotは、コインベーストランザクションに関する最小限の制限について説明し、 現在のブロック高で有効なBitcoinブロックの最小サイズは145バイトであると結論付けています。
-
● スクリプトの数値エンコーディングCScriptNumを理解する Antoine Poinsotは、CScriptNumがBitcoinのスクリプト内で整数をどのように表現するか説明し、 エンコーディング例をいくつか示し、2つのシリアライゼーション実装のリンクを掲載しています。
-
● BTCのウォレットアドレスを公開し、それが何BTC持っているか隠す方法はありますか? Vojtěch Strnadは、サイレントペイメントの再利用可能な支払いアドレスを使用すると、 オブザーバーがそれに支払われるトランザクションを関連付けることなく、公開ペイメント識別子を提示できると指摘しています。
-
● regtestにおける手数料率増加のテスト Ava Chowは、regtestにおいて、Bitcoin Coreのテストフレームワークを使用し、手数料率の高い環境をシミュレートするために、
-maxmempool
を低い値に、-datacarriersize
を高い値に設定することを推奨しています。 -
● なぜ私のP2P_V2ピアはv1で接続されているのでしょうか? Pieter Wuilleは、ユーザーがBIP324暗号化トランスポートをサポートするピアが v1非暗号化接続で接続されているのを確認した原因は、古いピアaddr情報であったのではないかという仮設を立てています。
-
● P2PKHトランスポートは非圧縮鍵のハッシュに送信しますか、それとも圧縮鍵のハッシュに送信しますか? Pieter Wuilleは、圧縮公開鍵と非圧縮公開鍵の両方を使用できるため、異なるアドレスが生成されると指摘し、 P2WPKHはポリシーにより圧縮公開鍵のみをサポートし、P2TRはx座標のみの公開鍵を使用すると付け加えています。
-
● Bitcoinネットワークにブロックをブロードキャストするにはどのような方法がありますか? Pieter Wuilleは、P2Pネットワーク上でブロックを通知する4つの方法について説明しています: BIP130を使用する方法、BIP152を使用する方法、 未承諾で
block
メッセージを送信する方法、 および古いinv
/getdata
/block
メッセージフローを使用する方法です。
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
-
● LND v0.18.0-betaは、この人気のLNノード実装の最新のメジャーリリースです。 リリースノートによると、インバウンドルーティング手数料 の実験的なサポートが追加され(ニュースレター #297参照)、 ブラインドパス用の経路探索が利用可能になり、 ウォッチタワーがSimple Taproot Channelをサポートし、 暗号化されたデバッグ情報の送信が効率化されました(ニュースレター #285参照)。 その他にも多くの機能が追加され、多くのバグが修正されています。
-
● Core Lightning 24.05rc2は、この人気の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 #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参照。