今週のニュースレターでは、フルRBFの有効化に関する継続的な議論と、 CoreDev.techミーティングでの議論のいくつかの書き起こし、 LNのようなコントラクトプロトコル用に設計されたエフェメラル・アンカーアウトプットの提案を掲載しています。 また、Bitcoin Stack Exchangeから人気のある質問とその回答や、 新しいソフトウェアリリースおよびリリース候補のリスト、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

  • ● フルRBFに関する継続的な議論: 先週のニュースレターで、 最終的な支払いとしてゼロ承認（zero conf）でトランザクションを受け入れる、 いくつかのビジネスにとって問題を引き起こす可能性がある新しいmempoolfullrbfオプションの組み込みについて、 Bitcoin-Devメーリングリストでの議論をまとめました。 今週は、メーリングリストとIRCルーム#bitcoin-core-devの両方で議論が続きました。 議論のハイライトは次のとおりです:

    • ● フリーオプション問題: Sergej Kotliarは、 あらゆるタイプのトランザクションの置換の最大の問題は、 無料のアメリカンコールオプションが作成されることだと考えていると警告しました。 たとえば、顧客アリスがマーチャントのボブからウィジェットを購入する場合、 ボブは、現在の価格が$20,000 USD/BTCとして、1 BTCのインボイスをアリスに送ります。 アリスはボブに1 BTCを低手数料率のトランザクションで送金します。 交換レートが$25,000 USD/BTCになっても、トランザクションが未承認のままの場合、 アリスは$5,000余分に支払うことを意味します。この時点で、 アリスはトランザクションを自分に払い戻すものに置換することを合理的に選択し、 取引を効果的にキャンセルします。しかし、交換レートがアリスに有利な方に変化した場合（たとえば、$15,000 USD/BTC）、 ボブはアリスの支払いをキャンセルできないため、通常のオンチェーンBitcoinトランザクションでは同じオプションを行使する方法がなく、 非対称な交換レートのリスクが生じます。それに比べて、トランザクションの置換が不可能な場合、 アリスとボブは同じ交換レートのリスクを共有することになります。

      Kotliarは、BIP125のオプトインRBFが利用可能な現在も問題は存在すると指摘しつつ、 フルRBFは問題を悪化させると考えているようです。

      Greg SandersとJeremy Rubinは別々のメールで、特にパッケージリレーが有効になると、 マーチャントのボブは、CPFPを使用して、顧客アリスの元のトランザクションを承認するようマイナーにインセンティブを 与えることができると返信しました。

      Antoine Riardは、LNにも同じリスクが存在することを指摘しました。 アリスはマーチャントであるボブのインボイスの有効期限が切れる直前まで支払いを待つことができ、 交換レートが変わるのを待つ時間を得ることができるからです。 ただし、この場合、ボブが交換レートの大幅な変化に気づくと、 ボブは自分のノードに支払いを受け取らないよう指示し、お金をアリスに返すことができます。

    • ● Bitcoin Coreは、ネットワークを担当していない: Gloria Zhaoは、 IRCの議論で次のように書いています。 「どのような選択肢をとっても、CoreはフルRBFが起こるかどうかをコントロールできないことをユーザーにはっきりと伝えるべきだと思います。 25353を元に戻しても、まだ発生する可能性があります。[…]」

      ミーティングの後、Zhaoは、状況の詳細な概要も投稿しました。

    • ● 削除しないと問題が発生する可能性がある: IRCの議論の中でAnthony Townsは、 先週の彼の指摘を繰り返しました、「24.0からmempoolfullrbfオプションを削除しなければ、 未調整のデプロイを行うことになる」。

      Greg Sandersは、「問題は5%以上が変数を設定するか？で、私はそうは思わない」と疑問を呈しました。 Townsは、「UASFのuacommentは、わずか2週間で~11%の変数の設定が容易であるあることを実証している」と 返信しました。

    • ● オプションにすべき: Martin Zumsandeは、IRCの議論の中で、次のように述べています。 「かなりの数のノードオペレーターやマイナーが特定のポリシーを望んでいる場合、 開発者が「今それはできない」というべきではないと思う。開発者は（デフォルトとすることで）推奨を与えることができ、そうすべきだが、 情報に精通したユーザーに選択肢を提供することは決して問題ではないはずだ。」

    この記事を書いている時点で、明確な解決には至っていません。 mempoolfullrbfオプションはまだ次期バージョンのBitcoin Core 24.0に含まれており、 ゼロ承認トランザクションに依存しているサービスは、先週のニュースレターにあるリンク先のメールを読むことから始め、 慎重にリスク評価することがOptechの推奨事項です。

  • ● CoreDev.techの書き起こし: The Atlanta Bitcoin Conference（TabConf）に先立って、 約40人の開発者がCoreDev.techイベントに参加しました。 このイベントの約半分のミーティングに関する書き起こしがBryan Bishopによって提供されています。 注目すべき議論は次のとおりです:

    • ● トランスポートの暗号化: バージョン2暗号化トランスポートプロトコル の提案に対する最近の更新に関する会話（ニュースレター #222参照）。 このプロトコルは、ネットワークの盗聴者が、どのIPアドレスからトランザクションが発生したか知るのを難しくし、 正直なノード間の中間者攻撃に対する検知および抵抗する能力を向上させます。

      議論では、プロトコル設計上の考慮点をいくつか取り上げ、 プロトコルの作者が特定の決定をした理由を疑問に思っている人にはお勧めの読み物です。 また、以前のカウンターサイン認証プロトコルとの関係も検証しています。

    • ● 手数料: 過去、現在、未来のトランザクション手数料に関する幅広い議論。 ブロックは常にいっぱいのように見えるが、mempoolはそうでもない理由についての質問や、 Bitcoinの長期的な安定性を心配する必要がでてくる前に重要な手数料市場が発展するまでの期間についての議論、 問題が存在すると考えられる場合に展開可能なソリューションなどのトピックがありました。

    • ● FROST: FROST閾値署名方式に関するプレゼンテーション。 この書き起こしは、設計における暗号の選択に関するいくつかの優れた技術的な質問を記載し、 特にFROSTまたは暗号プロトコルの設計全般について詳しく学びたい人にとって有益な読み物でしょう。 Bitcoinのための別の閾値署名方式であるROASTに関するTabConfの書き起こしもご覧ください。

    • ● GitHub: Bitcoin Coreプロジェクトのgitのホスティング先をGitHubから、 別の課題・PR管理ソリューションに移行することについての検討と、GitHubを使い続けるメリットについての議論。

    • ● BIPにおける証明可能な仕様: BIPでhacspec形式仕様記述言語を使用して、 証明可能な正しい仕様を提供することについての議論。 TabConfでの関連講演の書き起こしもご覧ください。

    • ● パッケージとv3トランザクションリレー: パッケージトランザクションリレーを有効にし、 Pinning攻撃を排除するための新しいトランザクションリレールールを使用する提案に関するプレゼンテーションの書き起こし。

    • ● Stratum v2: Stratum バージョン2 プールマイニングプロトコルを実装した新しいオープンソースプロジェクトの発表から始まった議論。 Stratum v2では、認証された接続と、 （プールがトランザクションを選択するのではなく）個々のマイナー（ローカルのマイニング機器を持つ）がマイニングするトランザクションを選択できるよう改良されています。 他の多くの利点に加えて、個々のマイナーが自分でブロックテンプレートを選択できることは、 Tornado Cashの論争のように、マイニングできるトランザクションを政府が強制することを懸念するプールにとって、 非常に望ましいものになるかもしれないということが議論の中で言及されました。 議論の大半は、Stratum v2のネイティブサポートを可能にするためにBitcoin Coreに加える必要のある変更に集中していました。 分散型のプールマイニングプロトコルBraidpoolについてのTabConfの書き起こしもご覧ください。

    • ● MergingはBitcoin Coreプロジェクトでコードをレビューしてもらうための戦略についての議論ですが、 多くの提案は他のプロジェクトにも当てはまります。以下のようなアイディアがありました:

      • 大きな変更はいくつかの小さなPRに分割する。

      • レビューアが最終的な目的を理解しやすいようにする。すべてのPRについて、 動機づけとなるPRの説明を書くことを意味します。インクリメンタルに行われる変更については、 トラッキングイシューや、プロジェクトボートを使用し、リファクタリングの動機づけとなるPRを公開し、 そのリファクタリングされたコードを使用して望ましい目標を達成する。

      • 長期的なプロジェクトでは、プロジェクトの前の状態、現在の進捗、結果を達成するために必要なこと、 ユーザーに提供されるメリットについて説明するハイレベルな説明資料を作成する。

      • 同じプロジェクトやコードサブシステムに興味のある人とワーキンググループを作る。

  • ● エフェメラル・アンカー: Greg Sandersは、 v3トランザクションリレーに関する以前の議論（ニュースレター #220参照）に続いて、 新しいタイプのアンカーアウトプットに関する提案をBitcoin-Devメーリングリストに投稿しました。 v3トランザクションが支払う手数料はゼロですが、OP_TRUEスクリプトへ支払うアウトプットを持ち、 誰もが子トランザクションでコンセンサスルールの下でそれを使用できるようにします。 未承認のゼロ手数料の親トランザクションは、 そのOP_TRUEアウトプットを使用する子トランザクションも含まれているトランザクションパッケージの一部である場合のみ、 Bitcoin Coreでリレーされマイニングされます。これはBitcoin Coreのポリシーにのみ影響し、コンセンサスルールを変更するものではありません。

    この提案の利点として、トランザクションのPinningを防ぐための1ブロックの相対タイムロック（ これを可能にするために使用されるコードにちなんで1 OP_CSVと呼ばれる）を使用する必要性を排除し、 誰でも親トランザクションの手数料を引き上げられることが挙げられます（以前の手数料スポンサーソフトフォークの提案と同様）。

    Jeremy Rubinは、この提案を支持する返信をしましたが、 v3トランザクションを使用できないコントラクトでは機能しないと指摘しました。 他の何人かの開発者もコンセプトについて議論し、この記事を書いている時点では、 全員魅力的に感じているようでした。

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

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

リリースとリリース候補

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

  • ● LDK 0.0.112は、LN対応アプリケーションを構築するためのこのライブラリのリリースです。

  • ● Bitcoin Core 24.0 RC2は、ネットワークで最も広く使われているフルノード実装の次期バージョンの最初のリリース候補です。 テストのガイドが利用できるようになっています。

    警告: このリリース候補には、mempoolfullrbf設定オプションが含まれており、 いくつかのプロトコルやアプリケーション開発者は、今週および先週のニュースレターで説明したように、 マーチャントサービスに対して問題を引き起こす可能性があると考えています。 Optechは、影響を受ける可能性のあるサービスに対して、RCを評価し、公開討論に参加することを推奨しています。

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

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

  • ● Bitcoin Core #23443は、新しいP2Pプロトコルメッセージsendtxrcncl(send transaction reconciliation)を追加し、 ノードがerlayのサポートをピアに通知できるようにしました。 このPRは、erlayプロトコルの最初のパーツのみを追加し、これを使用する前に他のパーツが必要です。

  • ● Eclair #2463と#2461は、Eclairの対話型のデュアルファンディングプロトコルの実装を更新し、 すべてのインプットに対してRBFへのオプトインと承認済みであること（つまり、既にブロックチェーン内にあるアウトプットの使用）を求めるようになりました。 これらの変更により、確実にRBFが使用できるようにし、Eclairユーザーが拠出した手数料がピアの以前のトランザクションの承認のために使用されることはありません。