今週のニュースレターでは、コンパクトブロックリレーのプレフィリングテストの結果と、 mempoolベースの手数料推定ライブラリのリンクを掲載しています。 また、Bitcoinのコンセンサスルールの変更に関する議論のまとめや、 新しいリリースおよびリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき更新など、 恒例のセクションも含まれています。

ニュース

• ● コンパクトブロックのプレフィリングのテスト: David Gumbergは、（以前ニュースレター#315と#339で取り上げた） コンパクトブロックの再構築率に関するDelving Bitcoinのスレッドに、 コンパクトブロックリレーの プレフィリング をテストして得られた結果の概要を返信しました。 プレフィリングとは、ノードが新しいブロック内のトランザクションの一部または全部を、 ピアがまだそれらのトランザクションを持っていない可能性があると判断した場合に、 事前にピアにリレーすることです。Gumbergの投稿は詳細で、他の人が自分で実験できるように Jupyter Notebookのリンクも含まれています。主なポイントは以下のとおりです:

  • ネットワーク転送を考慮しない場合、どのトランザクションをプレフィリングするか決定する単純なルールにより、 ブロック再構築の成功率が約62%から約98%に向上しました。

  • ネットワーク転送を考慮した場合、一部のプレフィリングにより追加のラウンドトリップが発生する可能性があり、 その場合は利点が打ち消され、パフォーマンスがわずかに低下する可能性があります。 しかし、この問題を回避するために多数のプレフィリングを行うことで、 再構築率は93%にまで向上し、さらなる改善の余地も残しています。

• ● mempoolベースの手数料推定ライブラリ: Lauren Shareshianは、 Block社が開発した手数料推定ライブラリを Delving Bitcoinで発表しました。他の手数料推定ツールとは異なり、 このライブラリはノードのmempoolへのトランザクションフローのみを推定基準にしています。 投稿では、この「Augur」ライブラリを複数の手数料推定サービスと比較し、 Augurはミス率（トランザクションの85%以上が想定された時間内で承認される）が低く、 平均過大推定率（トランザクションが必要以上に支払う手数料が約16%程度）も低いことが示されました。

  Abubakar Sadiq Ismailは、Delvingのスレッドに返信し、 Augurのリポジトリで、このライブラリで使用されているいくつかの仮定について検証する有益なissueを公開しました。

コンセンサスの変更

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

• ● 量子脆弱なアウトプットからの移行: Jameson Loppは、量子脆弱なアウトプットの使用を段階的に廃止するための 3段階の提案をBitcoin-Devメーリングリストに投稿しました。

  • BIP360量子耐性署名スキーム（または代替スキーム）のコンセンサスの有効化から3年後、 ソフトフォークにより量子脆弱なアドレスに支払いをするトランザクションを拒否します。 量子耐性のあるアウトプットへの支払いのみが許可されます。

  • 2年後、2回めのソフトフォークにより、量子脆弱なアウトプットからの支払いが拒否されます。 これにより、量子脆弱なアウトプットに残っている資金は使用できなくなります。

  • オプションで、その後のコンセンサスの変更により、 耐量子証明スキームを用いて（たとえばニュースレター #361の内容など） 量子脆弱なアウトプットからの支払いが許可される可能性があります。

  スレッドでの議論の大部分は、量子脆弱なビットコインを盗むのに十分な速度の量子コンピューターが存在することが判明するまで、 量子コンピューターに脆弱なビットコインの使用を阻止する必要があるかどうかという、 以前の議論の繰り返しでした（ニュースレター #348参照）。 双方から合理的な議論がなされ、この議論は今後も続くと予想されます。

• ● TaprootネイティブなOP_TEMPLATEHASH提案: Greg Sandersは、 Tapscriptに3つのopcodeを追加する提案を Bitcoin-Devメーリングリストに投稿しました。 そのうち2つは、以前提案されたOP_CHECKSIGFROMSTACKと OP_INTERNALKEY（ニュースレター #285参照）です。3つめのopcodeはOP_TEMPLATEHASHで、 OP_CHECKTEMPLATEVERIFY (OP_CTV)のTaprootネイティブ版で、 以下の違いが強調されています:

  • （segwit以前の）レガシースクリプトは変更しません。この代替案に関する以前の議論については、 ニュースレター #361をご覧ください。

  • ハッシュされるデータ（およびハッシュされる順序）は、 Taprootで署名でコミットするためにハッシュされるデータと似ているため、 既にTaprootをサポートしているソフトウェアの実装を簡単にします。

  • OP_CTVとは異なり、Taprootの annexにコミットします。 これを使用する1つの方法は、 古い状態の公開によりカウンターパーティがリカバリーできるようにコントラクトプロトコルで使用されるデータなど、 一部のデータがトランザクションの一部として公開されることを保証することです。

  • OP_NOPx opcodeではなく、OP_SUCCESSx opcodeを再定義します。 OP_NOPx opcodeを再定義するソフトフォークは、 opcodeの評価が失敗した場合にトランザクションを無効としてマークするVERIFY opcodeである必要があります。 OP_SUCCESSx opcodeの再定義は、実行後にスタックに1（成功）または0（失敗）のいずれかを配置するだけで済みます。 これにより、再定義されたOP_NOPx opcodeがOP_IFなどの条件句でラップする必要がある場合でも、 直接使用できるようになります。

  • 「… scriptSigで予期しない入力を防止します （ニュースレター #361参照）。

  Brandon Blackは、この提案を以前のLNHANCEバンドル提案（ニュースレター #285参照）と比較し、 ほとんどの点で同等であると評価しましたが、オンチェーンスペースにおける 輻輳制御 （遅延支払いバッチ処理）の効率性が低いと指摘しました。

• ● より長い相対タイムロックを許可する提案: 開発者のPythは、BIP68の相対タイムロックを現在の最大約1年から最大約10年に延長する提案を Delving Bitcoinに投稿しました。これにはソフトフォークと、 トランザクションインプットの sequence フィールドから追加bitの使用が必要になります。

  Fabian Jahrは、あまりに遠い将来のタイムロックは、量子コンピューターの開発（あるいは、 前述したJameson Loppの提案のような量子防御プロトコルの導入）などによる 資金の損失につながる可能性があると懸念を示しました。 Steven Rooseは、他のタイムロックメカニズム（事前署名トランザクションやBIP65 CLTVなど）を使用することで、 遠い将来のタイムロックは既に可能だと指摘し、Pythは、 望ましいユースケースはウォレットのリカバリーパスであり、 プライマリーパスが利用できなくなった場合にのみ長いタイムロックを使用し、 代替手段がなければ資金の永久的な損失となる状況での利用を想定していると付け加えました。

• ● コミットメントスキームとしてTaprootを用いた量子コンピューターに対するセキュリティ: Tim Ruffingは、量子コンピューターによる改竄に対するTaprootコミットメントの 安全性を分析した論文のリンクを投稿しました。 彼は、Taprootコミットメントが、従来のコンピューターに対して持つ 拘束性（binding） と 秘匿性（hiding） を今後も維持できるかどうかを検証しています。 彼は次のように結論づけています:

  量子攻撃者がTaprootアウトプットを作成し、 それを1/2の確率で予期しないマークルルートに展開することができるようにするには、 少なくとも2^81回のSHA256を実行する必要があります。 攻撃者がSHA256計算の最長シーケンスが2^20に制限された量子マシンしか持っていない場合、 攻撃者は1/2の成功確率を得るために少なくとも2^92台のマシンが必要です。

  Taprootコミットメントが量子コンピューターによる改竄に対して安全であれば、 keypath支払いを無効化し、Tapscriptに量子耐性のある署名検証opcodeを追加することで、 Bitcoinに量子耐性を追加できます。Ethan HeilmanがBitcoin-Devメーリングリストに投稿した BIP360 pay-to-quantum-resistant-hashの最近のアップデートでは、まさにこの変更が行われています。

リリースとリリース候補

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

• ● Bitcoin Core 29.1rc1は、主要なフルノードソフトウェアのメンテナンスバージョンのリリース候補です。

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

最近の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 #29954は、getmempoolinfo RPCを拡張し、 レスポンスオブジェクトに2つのリレーポリシーフィールド：permitbaremultisig （ノードがベアマルチシグをリレーするかどうか）とmaxdatacarriersize（ mempool内のトランザクションのOP_RETURNアウトプットで許可される最大byte数）を追加しました。 fullrbfやminrelaytxfeeなどの他のポリシーフラグは既に公開されているため、 これらの追加によりリレーポリシーの完全なスナップショットが可能になります。

• ● Bitcoin Core #33004は、-natpmpオプションをデフォルトで有効にし、 PCP（ポート制御プロトコル）による自動ポート転送と、 NAT-PMP（NAT Port Mapping Protocol）へのフォールバックを可能にします（ニュースレター #323参照）。PCPまたはNAT-PMPをサポートするルーターの配下にある待受ノードは、 手動設定なしでアクセス可能になります。

• ● LDK #3246は、オファーのsigning_pubkeyを宛先として使用することで、 ブラインドパスなしでBOLT12 オファーと払い戻しを作成できるようにします。 create_offer_builder関数とcreate_refund_builder関数は、ブラインドパスの作成を MessageRouter::create_blinded_pathsに委譲するようになりました。 これにより、呼び出し元は、DefaultMessageRouterでコンパクトパスを生成したり、 NodeIdMessageRouterで完全な長さの公開鍵パスを生成したり、 NullMessageRouterでパスを生成しないようにすることができます。

• ● LDK #3892は、BOLT12インボイスのマークルツリー署名を公開し、 開発者がCLIツールやその他のソフトウェアを構築して、インボイスを再作成できるようにします。 このPRはまた、元のオファーを追跡するためにBOLT12インボイスにOfferIdフィールドを追加します。

• ● LDK #3662は、（LSPS05としても知られる）BLIPs #55を実装し、 クライアントがLSPからプッシュ通知を受け取るためにエンドポイント経由でウェブフックを登録する方法を定義しています。 APIは、クライアントがすべてのウェブフックをリストしたり登録したり、特定のウェブフックを削除したりできる 追加のエンドポイントを公開します。これは、クライアントが非同期支払いを受信する際に通知を受け取るのに便利です。