今週のニュースレターでは、Taprootのソフトフォークのロックインをお祝いし、 アンチ・フィー・スナイピングを実装するために使用されるフィールドを変更することで トランザクションのプライバシーを改善するドラフトBIPについて掲載し、 トランザクションの交換と支払いバッチの組み合わせの課題についての記事を特集しています。 また、新しいソフトウェアのリリースおよびリリース候補の発表や、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更などの恒例のセクションも含まれています。

ニュース

  • ● 🟩 Taproot ロックイン: BIP 340、341および342で定義された Taprootのソフトフォークと関連する変更は、先週末にマイナーのシグナリングによりロックインされました。 Taprootは、11月初旬から中旬と予想されるブロック709,632以降で安全に使用できるようになります。 この猶予により、ユーザーが自分のノードをTaprootのルールを適用する（Bitcoin Core 0.21.1もしくはそれ以降の） リリースにアップグレードする時間が与えられ、ブロック709,632以降にTaprootのScriptで受け取った資金は、 たとえマイナーに問題があったとしても安全であることが保証されます。

    開発者の皆さまには、アクティベーションが完了した時点で、効率性やプライバシー、 ファンジビリティの向上の恩恵が受けられるようTaprootの実装を始めることをお勧めします。

    Taprootのロックインを祝福する読者の皆さまは、 開発者のPieter WuilleによるTaprootの起源と歴史についての短いスレッドもお読みください。

  • ● TaprootトランザクションでウォレットがデフォルトでnSequenceをセットするためのBIPが提案される: Chris Belcherは、ウォレットがアンチ・フィー・スナイピングを実装するための代替方法を提案するドラフトBIPを Bitcoin-Devメーリングリストに投稿しました。 代替方法は、シングルシグユーザーやマルチシグユーザーおよび、 Taproot対応のLNや高度なCoinswapなどの特定のコントラクトプロトコルのユーザーによって作られる トランザクションのプライバシーおよびファンジビリティを強化します。

    アンチ・フィー・スナイピングは、 Bitcoinの安全性を確保するために費やされるproof wof workの量を減らし、 承認スコアに頼るユーザー能力を制限するような方法で、 マイナーが互いに手数料を盗もうとするのを阻止するために、一部のウォレットが実装する手法です。 今日、アンチ・フィー・スナイピングを実装しているすべてのウォレットは、 nLockTimeの高さのロックを使用していますが、 BIP68のnSequenceの高さのロックを使用して同じ保護を実装することも可能です。 アンチ・フィー・スナイピングについてはこれ以上の効果はありませんが、 通常のウォレットがnSequenceの値を、CoinswapやTaproot対応のLNのアイディアなど 特定のマルチシグベースのコントラクトプロトコルのトランザクションで必要とされるのと同じ値を設定する良い理由になります。 これにより通常のウォレットのトランザクションをコントラクトプロトコルのトランザクションのように見せることができ、その逆も可能です。

    Belcherの提案は、両方のオプションが利用可能な場合、 ウォレットがnLockTimeとnSequenceのどちらを使用するか50%の確率でランダムに選択することを提案しています。 全体的に、提案が実装されると、通常のシングルシグのトランザクションや簡単なマルチシグのユーザーが、 コントラクトプロトコルのユーザーと一緒になり、お互いのプライバシーやファンジビリティを向上させることができるようになります。

フィールドレポート: RBFと加法的バッチ処理の利用

CardCoinsより

“加法的バッチ処理”は、mempool内の未承認トランザクションに追加のアウトプットを追加するスキームです。 このフィールドレポートでは、CardCoinsが顧客への支払いワークフローに、 そのようなスキームの再編成およびDoSに対して安全な実装を導入するために行った取り組みを紹介します。

Replace By Fee (RBF、BIP125) と バッチ処理は、 Bitcoinのmempoolと直接やりとりする企業にとって2つの重要なツールです。 手数料は上がったり下がったりしますが、ビジネスは常に手数料の効率化と戦わなければなりません。

それぞれのツールは、強力ではあるものの、複雑さや微妙な差異があります。例えば、 顧客の引き出しをバッチ処理すると、企業の手数料は節約できますが、取引を迅速にしたい顧客にとっては、 child pays for parent (CPFP)が不経済になる可能性が高いです。 同様に、RBFは手数料を低く抑える戦略をとる企業にとっては便利ですが（最初のトランザクションのブロードキャストは低い手数料で始め、 徐々に高くしていく）、顧客の引き出しトランザクションがウォレットで更新され、顧客を混乱させる可能性があります。 また、顧客がこのトランザクションを未承認のまま使用した場合、 企業が親のトランザクションを交換しようとする際に子の支払いをする必要があるため、 顧客が未承認のこのトランザクションを使用するのは面倒なことになります。 さらに悪いことに、企業は、顧客の引き出しを受け取った他のサービスによりピン留めされた引き出しを持っているかもしれません。

これらの2つのツールを組み合わせると、サービスプロバイダーは新しい機能を利用できるようになりますが、 同様に新しい形の複雑さにさらされることになります。基本的なケースでは、 RBFと単一の静的なバッチを組み合わせると、RBFとバッチ処理が個別に持つ複雑さを単純に組み合わせることになります。 ただし、RBFと”加法的バッチ処理”を組み合わせると、新たなエッジケースや危険な障害シナリオが発生します。

加法的RBFバッチ処理では、サービスプロバイダーは新しい顧客の引き出しを未承認のトランザクションに組み込むめに、 mempool内のトランザクションに新しいアウトプット（および承認済みのインプット）を追加します。 これにより、サービスプロバイダーは、顧客の引き出しを一度に大量に処理することで手数料の節約効果を維持しつつ、 ユーザーには即時引き出しを提供できます。各顧客が引き出しを要求すると、mempool内のトランザクションにアウトプットが追加されます。 このトランザクションは、承認されるか、他の局所的な最適値に到達するまで更新され続けます。

このような加法的RBFバッチ処理には多くの戦略があります。CardCoinsでは、 （Matthew Zipkinの協力を得て）安全第一のアプローチで実装しました。 その詳細はブログ記事RBF Batching at CardCoins: Diving into the Mempool’s Dark Reorg Forestに掲載されています。

リリースとリリース候補

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

  • ● Rust Bitcoin 0.26.2は、同プロジェクトの最新のマイナーリリースです。 前回のメジャーバージョンと比較して、いくつかのAPIの改善とバグ修正が含まれています。 詳細は変更ログをご覧ください。

  • ● Rust-Lightning 0.0.98は、いくつかの改善とバグ修正を含むマイナーリリースです。

  • ● LND 0.13.0-beta.rc5は、プルーニングされたBitcoinフルノードの使用をサポートし、 Atomic MultiPath (AMP)を使用した支払いの送受信を可能にし、 PSBT機能の向上、その他の改善およびバグ修正を行ったリリース候補です。

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

今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 Bitcoin Improvement Proposals（BIP）、および Lightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core GUI #4では、GUIを介してHardware Wallet Interface (HWI)の 外部署名者を使用するための初期サポートを追加しています。 この機能が完成すると、ユーザーはBitcoin CoreのGUIから直接HWI互換のハードウェアウォレットを使用できるようになります。

    HWIパス設定オプションのスクリーンショット

  • ● Bitcoin Core #21573では、Bitcoin Coreに含まれるlibsecp256k1のバージョンを更新しています。 最も注目すべき変更は、ニュースレター#136および#146に掲載した 最適化されたモジュラ逆数のコードを使用していることです。PRに投稿された性能評価によると、 古いブロックの検証が約10%高速化されています。

  • ● C-Lightning #4591では、bech32mアドレスのパースのサポートを追加しています。 C-Lightningは、option_shutdown_anysegwit機能をネゴシエートしたピアが、 任意のv1以上のネイティブsegwitアドレスをクロージングまたは払い戻しの宛先として指定できるようになりました。