今週のニュースレターでは、提案中のOP_CHECKTEMPLATEVERIFY (CTV) opcodeがDiscreet Log Contractsに及ぼす影響の分析および、 CTVとSIGHASH_ANYPREVOUTを有効にするためのTapscriptへの代替変更案に関する議論の要約について掲載しています。 また、新しいリリースの発表や人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • ● Scriptの変更によるDLCの効率性の向上: Lloyd Fournierは、 提案中のOP_CHECKTEMPLATEVERIFY(CTV) opcodeが、 Discreet Log Contracts(DLC)の作成に必要な署名の数を大幅に削減し、 また他のいくつかの演算の数を減らすことができることをDLC-Devメーリングリストおよび、 Bitcoin-Devメーリングリストに投稿しました。

    簡単に言うと、コントラクトの各最終状態（例えば、アリスが1 BTCを入手し、ボブが2 BTCを入手するような）に対して、 DLCは現在、その状態に対してそれぞれ個別の署名アダプターを作成する必要があります。 例えば、ビットコインの将来価格に関するコントラクトでは、1ドル未満を四捨五入した価格を指定するため、 比較的短期のコントラクトでも数千ドルの価格帯をカバーする必要があるため、多数の最終状態を定義することになります。 そのため、参加者は何千もの部分署名を作成、交換、保存する必要があります。

    代わりに、Fournierは、アウトプットをオンチェーンに配置することをコミットするTapleafでCTVを使用し、 何千もの取りうる状態を作成することを提案しています。 CTVはハッシュを使ってアウトプットにコミットするため、参加者は取りうる状態のハッシュを迅速かつオンデマンドに計算し、 計算およびデータの交換、データストレージを最小限に抑えます。 一部の署名は引き続き使用されますが、その数は大幅に削減されます。 複数のオラクル（例えば為替レートコントラクトにおける複数の価格データプロバイダーなど）を使用するコントラクトの場合、 必要なデータ量は更に単純化および削減されます。

    Jonas Nickは、提案中のSIGHASH_ANYPREVOUTの署名ハッシュモードを使用しても 同様の最適化が可能であると述べています （次のニュース項目で説明されている代替手段を使用しても同様の最適化が可能であることも留意してください）。

  • ● CTVとAPOの代替可能な構成: Russell O’Connorは、 BitcoinのTapscript言語に２つの新しいopcodeを追加するソフトフォークのアイディアを Bitcoin-Devメーリングリストに投稿しました。 Tapscriptは、新しいOP_TXHASH opcodeを使用して、 支払いトランザクションのどの部分がシリアライズされハッシュされるかを指定し、 ハッシュダイジェストは後続のopcodeが使用できるよう評価スタックに配置されます。 （以前提案された）新しいOP_CHECKSIGFROMSTACK (CSFS) opcodeは、 Tapscriptが公開鍵を指定し、スタック上の特定のデータ （OP_TXHASHによって作成された計算済みのトランザクションダイジェストなど）に対して対応する署名を要求できるようにします。

    O’Connorは、これらの2つのopcodeにより、これまでの2つのソフトフォークの提案、 SIGHASH_ANYPREVOUT (BIP118で定義されたAPO)および OP_CHECKTEMPLATEVERIFY (BIP119で定義されたCTV)を エミュレーションできることを説明しました。目的によっては、 このエミュレーションはCTVやAPOを直接使用するよりも効率が悪いかもしれませんが、 OP_TXHASHとOP_CSFSはTapscript言語をよりシンプルに保ち、 特にOP_CATなどのTapscriptへの他のシンプルな追加要素と組み合わせた場合、 今後のScript作成者に柔軟性を提供することができます。

    Anthony Townsは、返信で、他の代替opcodeを使用した同様のアプローチを提案しました。

    この要約が書かれている時点では、このアイディアはまだ活発に議論されていました。 私たちは、将来のニュースレターで、この話題を再度取り上げる予定です。

リリースとリリース候補

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

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

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

  • ● Bitcoin Core #23201では、データを解決する代わりに最大weightを指定できるようにすることでウォレットユーザーが、 外部入力（以前ニュースレター #170で言及した）を使用してトランザクションに資金を提供する機能を向上させました。 これにより、アプリケーションはfundrawtransaction RPC、send RPC、walletfundpsbt RPCを使用して、 HTLCのような非標準アウトプットでトランザクションの手数料を引き上げることができます （ニュースレター #184に掲載されているLNクライアントの要件）。

  • ● Eclair #2141は、ウォレットのUTXOが少ない時に、より積極的な承認ターゲットを選択することで、 （以前ニュースレター #184で取り上げた）自動手数料引き上げメカニズムを改良しました。 このような状況では、さらに強制クローズした場合にウォレットのUTXOの数を維持するために、 手数料引き上げトランザクションが迅速に承認されることが重要です。 Eclairが使用するAnchor Outputスタイルの手数料引き上げの詳細については、こちらをご覧ください。

  • ● BTCPay Server #3341では、LNを介して払い戻しを要求する際に、 これまでのデフォルト30日とは異なるBOLT11の有効期限を設定することができるようになりました。