今週のニュースレターでは、OP_VAULTの提案を再実装するために柔軟なCovenantの設計を使用する分析と、 署名アダプターのセキュリティに関する投稿、一部の読者にとって特に興味深いと思われる求人情報を掲載しています。 また、新しいリリースとリリース候補、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など 恒例のセクションも掲載しています。

ニュース

• ● MATTベースのVault: Salvatore Ingalaは、 最近のOP_VAULTの提案（ニュースレター #234参照）と同様の動作をする Vaultのラフな実装をBitcoin-Devメーリングリストに投稿しました。 ただしこれは、IngalaのMATT（Merklize All The Things）の提案（ニュースレター #226参照）に 基づいたものです。MATTは、いくつかの非常にシンプルなCovenant opcodeをソフトフォークで追加することで、 Bitcoin上で非常に柔軟なコントラクトを作成できるようにします。

  今週の投稿でIngalaは、MATTは非常に柔軟であるだけでなく、 いくつかの日常的に使用される可能性のあるトランザクションテンプレートで効率的かつ簡単に使用できることを実証しようとしました。 これは最近のOP_VAULTの提案で行われているように、 Ingalaは、BIP119のOP_CHECKTEMPLATEVERIFY（CTV）の提案を基に構築しています。 さらに2つの追加opcodeを使用して（必要なすべてを完全にカバーしているわけではないことを認めながら）、 OP_VAULTとほぼ同等の機能セットを提供しています。 唯一の注目すべき欠点は、「まったく同じVaultに送り返される追加のアウトプットを追加するオプション」です。

  この記事を書いている時点では、Ingalaの投稿には直接の返信はありませんでしたが、 MATTに対する彼の当初の提案と、（基本的に）任意の複雑なプログラムが実行されたことを検証できる機能については、 引き続き議論が行われています。

• ● 署名アダプターのセキュリティ分析: Adam Gibsonは、 署名アダプターのセキュリティの分析、 特に複数の参加者がトラストレスにアダプターを作成する必要があるMuSigのような マルチシグプロトコルとどのように相互作用するかについて、 Bitcoin-Devメーリングリストに投稿しました。 署名アダプターは、効率とプライバシーを向上させるためにPTLCを使用するよう 近い将来アップグレードされるLNで使用される予定です。 また、効率とプライバシーまたはその両方を向上させるために、他の多くのプロトコルでも使用されることが想定されています。 PTLCは、新しくアップグレードされたBitcoinプロトコルの最も強力な構成要素の１つであるため、 そのセキュリティ特性を慎重に分析することは、正しく使用されることを保証するために不可欠です。 Gibsonは、Lloyd Fournierらのこれまでの分析（ニュースレター #129参照）をベースにしつつ、 さらなる分析が必要な領域を指摘し、自身の寄稿に対するレビューを求めています。

• ● プロジェクトチャンピオンの求人: Spiralの助成団体のSteve Leeは、 Bitcoinの長期的なスケーラビリティ、セキュリティ、プライバシー、柔軟性を大幅に向上させる クロスチームプロジェクトのチャンピオンとして、経験豊富なBitcoinコントリビューターに応募してほしいという要望を Bitcoin-Devメーリングリストに投稿しました。 詳しくは、彼の投稿を参照してください。

リリースとリリース候補

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

• ● LND v0.16.2-betaは、このLN実装のマイナーリリースで、 「前のマイナーリリースで導入されたパフォーマンスのリグレッション」に対するいくつかのバグ修正が含まれています。

• ● Core Lightning 23.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の注目すべき変更点。

• ● Bitcoin Core #25158は、gettransactionRPCおよび、listtransactionsRPC、 listsinceblockRPCのトランザクション詳細のレスポンスに、 どのトランザクションがabandonedとマークされたかを示す abandonedフィールドを追加しました。

• ● Bitcoin Core #26933では、パッケージとして評価される場合でも、mempoolに受け入れられるために、 各トランザクションがノードの最小リレー手数料率（-minrelaytxfee）を満たすという要件を再導入しました。 パッケージの検証では、動的なmempoolの最小手数料率よりも低いトランザクションの手数料の引き上げが可能です。 このポリシーが再導入されたのは、置き換えの際に手数料ゼロのトランザクションが手数料を引き上げる子孫を失うリスクを回避するためです。 v3のようなパッケージトポロジーの制限や、mempoolの排除プロセスの修正など、 このようなトランザクションを防止するDoS耐性のある方法が見つかった場合、将来的に元に戻される可能性があります。

• ● Bitcoin Core #25325では、UTXOキャッシュにプールベースのメモリリソースを導入しました。 この新しいデータ構造は、各UTXOに大して個別にメモリを割り当てたり開放したりする代わりに、 UTXOを追跡するためのより大きなメモリプールを事前に割り当てて管理します。 UTXOのルックアップは、特にIBD中のメモリアクセスの大部分を占めています。 ベンチマークによると、より効率的なメモリ管理により、インデックスの再作成が20%以上高速化されています。

• ● Bitcoin Core #25939では、トランザクションインデックスのオプションを有効にしたノードが、 utxoupdatepsbt RPCを使用してPSBTを更新する際に、ノードがそのインデックスを検索し、 使用するトランザクションアウトプットに関する情報をPSBTに追加することができるようになりました。 このRPCが2019年に最初に実装されたとき（ニュースレター #34参照）、 ネットワーク上ではレガシーアウトプットとsegwit v0アウトプットの2種類のアウトプットが一般的でした。 PSBTの各レガシーアウトプットの支払いには、署名者がそのアウトプットの量を検証できるように、 そのアウトプットを含むトランザクションの完全なコピーを含める必要があります。 使用されるアウトプットの量を検証せずに支払いをすると、 支払人がトランザクション手数料を大幅に過払いする可能性があるため、検証は重要です。

  一方、各segwit v0アウトプットの支払いは、PSBTが前のトランザクション全体ではなく、 アウトプットのscriptPubKeyと量のみを含めることができるように、量にコミットします。 これによりトランザクション全体を含める必要がなくなると考えられていました。 承認されたトランザクションの未使用のトランザクションアウトプットは、 すべてBitcoin CoreのUTXOセットに保存されているため、utxoupdatepsbt RPCは、 UTXOを使用する任意のPSBTに必要なscriptPubKeyと量のデータを追加することができます。 またutxoupdatepsbtは、以前にローカルノードのmempoolを検索してUTXOを探し、 ユーザーが未承認のトランザクションのアウトプットを使用できるようにしました。

  しかし、utxoupdatepsbtがBitcoin Coreに追加された後、 いくつかのハードウェア署名デバイスは、ユーザーが同じトランザクションに2回署名したように見せることにより生じる 手数料の過払いを防ぐために、segwit v0アウトプットの使用でも完全なトランザクションを含めることを要求するようになりました （ニュースレター #101参照）。 そのため、PSBTに完全なトランザクションを含める必要性が高まりました。

  このマージされたPRでは、トランザクションインデックス（有効な場合）とローカルノードのmempoolから完全なトランザクションを検索し、 必要に応じてPSBTに含めます。完全なトランザクションが見つからない場合は、 UTXOセットがsegwitアウトプットの支払いに使用されます。Taproot（segwit v1）は、 少なくとも1つのTaprootアウトプットを使用するほとんどのトランザクションで過払いの懸念が解消されるため、 今後のハードウェア署名デバイスの更新では、その場合に完全なトランザクションが必要なくなることが予想されます。

• ● LDK #2222では、チャネルがUTXOに対応していることを検証することなく、 そのチャネルの関係ノードからゴシップされたメッセージを使用して、チャネルに関する情報を更新できるようになりました。 LNのゴシップメッセージは、サービス拒否（DoS）攻撃を防ぐためのLNの設計の1つの方法として、 証明済みのUTXOを持つチャネルに属している場合にのみ受け入れるべきですが、 一部のLNノードはUTXOを検索する機能を持たず、DoS攻撃を防ぐための他の方法を持つ場合があります。 このマージされたPRにより、UTXOデータのソースがない場合でも、情報を利用しやすくなります。

• ● LDK #2208では、強制クローズしたチャネルの未解決のHTLCのトランザクションの 再ブロードキャストと手数料の引き上げを追加しました。 これは、いくつかのPinning攻撃への対処と信頼性の確保に役立ちます。 LNDが独自の再ブロードキャストインターフェースを追加したニュースレター #243や、 CLNが独自のロジックを改善した先週のニュースレターも参照ください。