今週のニュースレターでは、OpenSSLとlibsecp256k1ライブラリのこれまでのパフォーマンス比較の分析を掲載しています。 また、コンセンサスの変更に関する議論や、新しいリリースとリリース候補の発表、 人気のBitcoinインフラストラクチャソフトウェアの注目すべき更新など、恒例のセクションも含まれています。

ニュース

  • ● OpenSSLとlibsecp256k1におけるECDSA署名検証のパフォーマンス比較: Sebastian Falbesonerは、 OpenSSLとlibsecp256k1のECDSAの署名検証パフォーマンスの過去10年間の比較をDelving Bitcoinに投稿しました。 彼は、Bitcoin CoreがOpenSSLからlibsecp256k1に切り替えてから今年で10周年を迎えることに言及し、 Bitcoin Coreが切り替えをしなかったらという仮定の状況を想像したいと考えました。

    移行当初から、libsecp256k1はOpenSSLより2.5〜5.5倍高速でした。とはいえ、 OpenSSLは年々改善されている可能性があり、10年間の比較をテストする価値はありました。

    手法は、両方のライブラリの関数を使ってテスト可能な3つのステップ（圧縮公開鍵のパース、 DERエンコードされた署名のパース、ECDSA署名の検証）で構成されています。疑似乱数鍵ペアのリストを使ってベンチマークを作成し、 3台の異なるマシンでベンチマークを実行し、棒グラフを作成しました。このグラフは、 libsecp256k1が長年に渡り大幅に改善されてきたことを示しています。つまり、 bc-0.19からbc-0.20にかけて約28%、bc-0.20からbc-22.0にかけて約30%の改善が見られましたが、OpenSSLは現状維持でした。

    Sebastianは、Bitcoinエコシステム以外では、secp256k1曲線はそれほと重要ではなく、 改善に時間を費やし労力をはらうような第一級の存在とは見なされていないと結論付けています。 彼はまた、結果を再現し、手法に関する問題や、自身の結果と違いを発見した場合はぜひ報告して欲しいと述べています。 ソースコードはGithubで公開されています。

コンセンサスの変更

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

  • ● データ制限に関する複数の議論: 複数の会話で、コンセンサスにおけるさまざまな分野の制限を変更するためのアイディアが検討されました。

    • ● scriptPubkeyを520 byteに制限制限: PortlandHODLは、コンセンサスでscriptPubkeyのサイズを520 byteに制限する提案をBitcoin-Devメーリングリストに投稿しました。 BIP54のコンセンサスクリーンアップと同様に、これはレガシースクリプトのコーナーケースにおける最大ブロック検証コストを制限します。 また、OP_RETURNを使って大きな連続データセグメントを作成することも不可能になります。 このアイディアに対するフィードバックには、この変更により、最大ブロック検証コストを制限するBIP54と比較して、 古い署名済みプロトコルの没収対象領域が拡大すること、そして特定のソフトフォークアップグレードパス（特に 量子耐性に関するもの）を閉ざされることへの反発が含まれていました。

    • ● データを削減するための一時的なソフトフォーク: Dathon Ohmは、 Bitcoinトランザクションをデータのエンコードに使用する方法を一時的に制限する提案を投稿し、 BIPのプルリクエストを作成しました。このソフトフォークは一時的なものと説明されていますが、 メーリングリストやプルリクエストの議論では、提案された変更による大規模な没収対象領域について批判的な意見が出ています。 さらに、一時的なソフトフォークは可能ではあるものの、その期限切れをめぐる論争は、ハードフォークへと発展させる可能性を秘めています。 これに対しPeter Toddは、提案されたBIPのテキストを、提案されたコンセンサスルールの下で有効なBitcoinトランザクションにエンコードすることで、 このアプローチの限界を示しました。

  • ● ポスト量子署名の集約: Tadge Dryjaは、ロックスクリプトが同じトランザクション内で使用される特定のUTXOにコミットできるようにする OP_CHECKINPUTVERIFY（OP_CIV）をBitcoin-Devメーリングリストに投稿しました。 これにより、関連するUTXOのグループを単一の承認署名で使用できるようになり、 インプットをまたいだ署名の集約と同様の効果があります。 このアプローチは、個別のECDSAやBIP340署名よりもコストがかかりますが、数KBのポスト量子署名では、 トランザクションの仮想バイトを大幅に節約できます。OP_CIVは、 BitVMのようなプロトコルにおける汎用的な兄弟インプットチェックにも使えます。 OP_CHECKCONTRACTVERIFYなどの他の提案も、兄弟scriptPubKeysにコミットすることで同様の署名共有スキームを実現できますが、 異なる（おそらくより悪くなる）トレードオフがあります。

  • ● Bitcoin ScriptにおけるネイティブSTARK証明検証: Abdelhamid Bakhtaは、 Bitcoin ScriptでSTARK証明の特定のバージョンの検証を可能にする新しいTapscript opcode OP_STARK_VERIFYの詳細な提案をDalving Bitcoinに投稿しました。 これにより、Bitcoinに任意の計算の証明を埋め込むことが可能になります。 提案されたopcodeは、証明をBitcoin固有のデータにバインドしないため、 証明は単にそれ自体が埋め込む計算の検証済みの証明に過ぎません。これらの証明は、 他の署名方法を使って特定のBitcoinトランザクションにリンクできます。 この投稿では、Validity Rollupなどのさまざまなユースケースについて議論しています。

  • ● BIP54の実装とTest Vector: Antoine Poinsotは、BIP54の コンセンサスクリーンアップ（詳細はニュースレター #348参照）の作業の最新情報を Bitcoin-Devメーリングリストに投稿しました。 彼はBitcoin Inquisition #99を作成し、 BIP54のコンセンサスルールを実装しました。このPRには、4つの緩和策それぞれの単体テストが含まれており、 提案のTest Vectorを生成するのに使用できます。さらに、sigop計算ロジックのファズハーネスと、 過去の違反を含む現実的な状況における緩和策の動作を模倣する機能テストが含まれています。 さらに、タイムスタンプやコインベース制限など、mainnetのブロックを必要とする緩和策のTest Vectorに必要な 完全なヘッダーチェーンを生成するためのカスタムマイナーも開発されました。 最後に、生成されたTest VectorをBIP54に追加するために、BIPs #2015を作成しました。

リリースとリリース候補

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

  • ● Core Lightning 25.09.2は、この人気のLNノードの現在のメジャーバージョンのメンテナンスリリースで、 bookkeeperとxpayに関連するいくつかのバグ修正が含まれています。その一部は、コードとドキュメントの変更セクションにまとめられています。

  • ● LND 0.20.0-beta.rc3は、この人気のLNノードのリリース候補です。 テストによって恩恵を受ける改善点の1つは、ウォレット再スキャンが早期に行われる問題の修正です。

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

最近の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 #31645は、デフォルトのdbbatchsize設定を16MBから32MBに増やしました。 このオプションは、IBDまたはassumeUTXOスナップショットの後に、 メモリ（dbcacheによって設定）にキャッシュされたUTXOセットをディスクにフラッシュする際に使用するバッチサイズを決定します。 このアップデートは主にHDDとローエンドシステムにメリットをもたらします。 たとえば、著者はRaspberry Piでdbacheを500に設定した場合、フラッシュ時間が30%短縮されたと報告しています。 ユーザーは必要に応じてデフォルト設定を上書きできます。

  • ● Core Lightning #8636は、期限に達するとgetroutesが失敗するaskrene-timeout設定（デフォルトは10秒）を追加します。 maxpartsが低い値に設定されている場合、askrene（ニュースレター #316参照）は キャパシティ不足の経路で再試行ループに入る可能性があります。このPRは、そのようなシナリオでボトルネックとなる経路を無効にし、 処理の進行を確実にします。

  • ● Core Lightning #8639は、オペレーティングシステムに依存するargv（コマンドライン引数）のサイズ制限を回避するために、 bitcoin-cliとのインターフェース時に-stdinを使用するようにbcliを更新しました。 この更新により、ユーザーが大規模なトランザクション（たとえば、 700個のインプットを持つPSBTなど）を作成できない問題が解決されました。 大規模なトランザクションのパフォーマンスに関するその他の改善も行われています。

  • ● Core Lightning #8635は、支払いステータス管理を更新し、 xpay（ニュースレター #330参照）またはinjectpaymentonionを使用する際、 送信HTLCが作成された後にのみ支払いパーツが保留中としてマークされるようになりました。 これまでは、支払いのパーツは最初に保留中としてマークされ、その後HTLCの作成に失敗すると、 listpaysやlistsendpaysでアイテムが永久に保留中のままになる可能性がありました。

  • ● Eclair #3209は、ルーティング手数料率の値が負にならないようにするためのチェックを追加しました。 これまでは、負の値が設定されるとチャネルが強制的に閉鎖されていました。

  • ● Eclair #3206は、Liquidity Adsの購入が署名開始後、 署名交換中に中止された場合、保留中の受信HTLCを直ちに失敗させます。 これまでは、Eclairはこのエッジケースを処理できず、HTLCの有効期限直前に失敗させ、 送信者の資金を不必要に拘束していました。この変更は、 悪意のないモバイルウォレットが接続を切断して中止するケースを想定して行われました。

  • ● Eclair #3210は、BOLT3の仕様およびLDKなどの他の実装に準拠し、 73 byteのDERエンコードされた署名（ニュースレター #6参照）を想定するようウェイトの推定を更新しました。 これにより、このサイズを想定するピアが、手数料不足を理由にEclairからのinteractive-txの試行を拒否することがなくなります。 Eclairはこのような非標準の署名を生成することはありません。

  • ● LDK #4140は、ノードが送信非同期支払いのために再起動する際に発生する、 早期の強制閉鎖を修正しました。これまでは、頻繁にオフラインになるノードがオンラインに戻り、 送信側のHTLCがCLTV有効期限を LATENCY_GRACE_PERIOD_BLOCKS（3ブロック）過ぎていた場合、 LDKはノードが再接続してピアがHTLCを失敗させる前に、直ちに強制閉鎖していました。 このシナリオでは、ノードは受信側のHTLCを要求しようと競合していないため、 LDKはHTLCのCLTV有効期限が切れた後、強制閉鎖する前に、4,032ブロックの猶予期間を追加します。

  • ● LDK #4168は、ピアのメッセージ読み取りの一時停止を通知するread_eventフラグを削除します。 これにより、send_dataが一時停止/再開シグナルの唯一の信頼できる情報源になります。 これにより、send_dataが既に読み取りを再開した後に、 ノードがread_eventから遅れて一時停止通知を受信する可能性がある競合状態が修正されます。 遅れた一時停止により、ノードがそのピアに再度メッセージを送信するまで、読み取りが無期限に無効になります。

  • ● Rust Bitcoin #5116は、トランザクションリストに隣接する重複が含まれている場合、 compute_merkle_rootとcompute_witness_rootのレスポンスでNoneを返すよう更新します。 これにより、重複トランザクションを含む無効なブロックが有効なブロックと同じマークルルート（およびブロックハッシュ）を共有し、 Rust Bitcoinが両方を混同して拒否してしまうという、 変異型のマークルルート脆弱性（CVE 2012-2459）を回避できます。 この解決策はBitcoin Coreの解決策に着想を得ています。

  • ● BTCPay Server #6922では、Subscriptionsが導入され マーチャントは定期支払いプランや支払い方法の設定、チェックアウトプロセスを介したユーザーの登録が可能になります。 システムは各加入者のクレジット残高を追跡し、各請求期間に差し引かれます。加入者用のポータルでは、 ユーザーがプランのアップグレードまたはダウングレード、クレジットの参照、履歴、領収書の確認ができます。 マーチャントは、支払期日が近づくとユーザーに通知するメールアラートを設定できます。 これにより自動課金が導入されるわけではありませんが、計画されているNostr Wallet Connect (NWC)との統合により、 特定のウォレットではそれが実現する可能性があります。