今週のニュースレターでは、いくつかの利点があるOP_VAULTの代替設計の提案と、 新しい週刊Optechポッドキャストの発表を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、 新しいソフトウェアリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など、 恒例のセクションも含まれています。

ニュース

  • OP_VAULTの代替設計: Greg Sandersは、 OP_VAULT/OP_UNVAULTの提案機能(ニュースレター #234参照)を提供するための代替設計を Bitcoin-Devメーリングリストに投稿しました。 彼の代替案は、2つではなく3つのopcodeを追加するものです。例を挙げると:

    • アリスは、少なくとも2つのリーフスクリプトを含むスクリプトツリーを持つ P2TRアウトプットに支払いをすることで資金をVault(金庫)にデポジットします。 このうち1つは、時間遅延のあるUnvault(引き出し)処理をトリガーできるもので、 もう1つは、即座に資金を凍結するものです。例:tr(key,{trigger,freeze})

      • トリガー・リーフスクリプトには、 (アリスのホットウォレットに署名を要求するような)信頼性の低い認可条件と、 OP_TRIGGER_FORWARD opcodeが含まれています。アリスはこのリーフスクリプトを作成する際に、 支払い遅延パラメーター(たとえば1,000ブロック(約1週間)の相対タイムロック)を提供します。

      • フリーズ・リーフスクリプトには、 アリスが指定したい認可条件(無くても良い)とOP_FORWARD_DESTINATION opcodeが含まれています。 アリスはこのリーフスクリプトを作成する際に、 (コールドウォレットやハードウェア署名デバイスに複数の署名を要求するような) より信頼性の高い認可条件を選択します。アリスは、 ハッシュダイジェストの形でこれらの条件へのコミットメントをopcodeに提供します。

    • アリスは、上記のスクリプトツリー宛のアウトプットのトリガー・リーフスクリプトを使用することで(インプットとして使用することで)、 Unvault(引き出し処理)をトリガーします。この時点で、 彼女はOP_TRIGGER_FORWARD opcodeに2つのパラメーターを提供します。 1つはこのインプットの資金を受け取るアウトプットのインデックスで、 もう1つはこの後資金を使用する際の方法についてのハッシュベースのコミットメントです。 opcodeは、トランザクションの指示されたアウトプットが、 トリガー・リーフスクリプトが前に指定された遅延(たとえば1,000ブロック)と等しい OP_CHECKSEQUENCEVERIFY(CSV)による相対遅延と アリスのコミットメントハッシュを含むOP_FORWARD_OUTPUTS opcodeで置き換えられていることを除いて、 使用しようとしているスクリプトツリーと同様のスクリプトツリーを持つP2TRアウトプットに支払いをしているか検証します。 スクリプトツリーを再構築する方法は、以前のCovenantの提案である OP_TAPLEAF_UPDATE_VERIFYニュースレター #166参照)と似ています。

    • アリスは、相対タイムロックが切れるまで待ち、 OP_FORWARD_OUTPUTS opcodeを持つtapleafを選択してUnvaultアウトプットを使用することで引き出しを完了させます。 opcodeは、このトランザクションのアウトプットの金額と スクリプトのハッシュがアリスが前のトランザクションで作成したコミットメントと同じか検証します。 このケースでは、アリスは資金をVaultに預け入れ、引き出しを開始し、 アリスの監視プログラムが指定されたアウトプット宛の意図された支払いか確認するために少なくとも1,000ブロック待ち、 支払いが完了したことになります。

    • 何か問題が発生した場合、アリスは資金を凍結します。 彼女は、資金をVaultに預けた瞬間から引き出しが完了するまでの間、いつでもこの処理を行うことができます。 資金を凍結するためには、彼女は単純にVaultトランザクションまたはトリガートランザクションのアウトプットを フリーズ・リーフスクリプトを使って使用する選択をします。 アリスがVaultトランザクションで明示的にフリーズ・リーフスクリプトを配置したことを思い出してください。 また、それが引き出しを開始するトリガートランザクションにも暗黙的に継承されていることに注意してください。

    元のOP_VAULTの設計と比べたこのアプローチの利点の1つは、 フリーズ・リーフスクリプトにアリスが指定したい任意の認可条件を含めることができる点です。 OP_VAULTの提案では、アリスが選択したパラメーターを知る者は誰でも、 彼女の資金をフリーズ・スクリプト宛に使用することができました。 これはセキュリティ上の問題にはなりませんが、迷惑になります。 Sandersの設計では、アリスは(たとえば)凍結を開始するのに非常に軽量の保護されたウォレットに署名を要求することができます。 これはおそらく、ほんとどの嫌がらせ目的の攻撃を防ぐのに十分な負担となりますが、 アリスが緊急時に素早く資金を凍結するのを妨げるほどの障壁ではありません。

    他のいくつかの利点は、コンセンサスで強制されるVaultプロトコルをより理解しやすくし、 安全性を検証しやすくすることを目的としています。上記の記事を書いた後、 OP_VAULTの提案者であるJames O’Beirneは、Sandersのアイディアに好意的な返事をしました。 O’Beirneはさらなる変更のアイディアも持っていたため、今後のニュースレターで紹介する予定です。

  • 新しいOptech Podcast: Twitterスペースで毎週開催されているOptech Audio Recapが ポッドキャストとして提供されるようになりました。各エピソードは、 すべての一般的なポッドキャストプラットフォームやOptechのウェブサイトでの書き起こしで利用できます。 Bitcoinの技術的なコミュニケーションを向上させるというOptechのミッションにおいて、 これが大きな前進であると考える理由など、詳細はブログ記事をご覧ください。

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Bitcoin-inquisition: Activation logic for testing consensus changesは、 Anthony TownsによるPRで、Bitcoin Inquisitionプロジェクトでソフトフォークをアクティベート、 非アクティベートするための新しい方法を追加しています。 これは、signetで実行されテストに使用されるよう設計されています。 このプロジェクトについては、ニュースレター #219で取り上げています。

具体的には、このPRはBIP9のブロックのバージョンビットを使用する方法をHeretical Deploymentsと呼ばれるものに置き換えます。 mainnetでのコンセンサスやリレーの変更は、慎重な(人間の)コンセンサスの構築と 精巧なソフトフォークのアクティベーションメカニズムを必要とするため、 アクティベートするのが困難で時間がかかりますが、 テスト用のネットワークではこれらの変更のアクティベートを効率化できます。 このPRでは、バグや望ましくないことが判明した変更を無効化する方法も実装されており、 これはmainnetとは大きく異なる点です。

  • なぜBitcoin Coreにマージされていないコンセンサスの変更をデプロイしたいのですか? Bitcoin Coreにコードをマージし、その後でsignetでテストすることに(あるとしたら)どんな問題があるのでしょうか?

    いくつかの理由が議論されました。mainnetユーザーが実行しているCoreのバージョンのアップグレードを要求できないので、 バグが修正された後でも、一部のユーザーはバグのあるバージョンを実行し続ける可能性があります。 regtestのみに依存すると、サードパーティ製のソフトウェアの統合テストが難しくなります。 コンセンサスの変更を別のリポジトリにマージすることは、Coreにマージするよりもリスクが低くなります。 アクティベートされてなくても、ソフトフォークロジックを追加すると既存の動作に影響を与えるバグを導入する可能性があります。 

  • Heretical Deploymentsは、BIP9の状態(DEFINEDSTARTEDLOCKED_INACTIVEFAILED)に似た 有限状態マシンの一連の状態を遷移しますが、ACTIVEの後にDEACTIVATINGという状態が追加されます( その後に最終の状態ABANDONEDが続きます)。状態DEACTIVATINGの目的は何ですか?

    ソフトフォークにロックされた資金を引き出す機会をユーザーに提供するためのものです。 フォークが非アクティベートもしくはリプレースされると、ユーザーはその資金を使用できなくなる可能性があります。 たとえそれが誰でも使用可能な資金であったとしてもです。Txが非標準となり拒否されると使用できなくなります。 懸念されるのは、限定されたsignetの資金が永久に失われることではなく、UTXOセットが肥大化する可能性があることです。 

  • なぜこのPRではmin_activation_heightが削除されているのですか?

    新しい状態モデルでは、ロックインとアクティベーションの間に設定可能な間隔はありません。 Heretical Deploymentsでは、次の432ブロック(3日間)の状態マシン期間の開始時に自動的にアクティベートされます (この期間はHeretical Deploymentsでは固定されています)。 

  • TaprootがこのPRに埋め込まれているのはどうしてですか?

    埋め込まなければ、それをHeretical Deploymentにする必要があり、コーディングの手間がかかります。 また、そうするといずれタイムアウトになりますが、Taprootは決してタイムアウトしないようにする必要があります。 

リリースとリリース候補

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

  • Core Lightning 23.02は、この人気のLN実装の新バージョンのリリースです。 これには、バックアップデータのピアストレージ(ニュースレター #238参照)の実験的なサポートや、 デュアル・ファンディングOfferの実験的なサポートの更新が含まれています。 また、その他にもいくつかの改善とバグ修正が含まれています。

  • LDK v0.0.114は、LN対応のウォレットやアプリケーションを構築するためのこのライブラリの新バージョンのリリースです。 いくつかのセキュリティ関連のバグが修正され、Offerを解析する機能が追加されています。

  • BTCPay 1.8.2は、この人気のあるBitcoin用のセルフホスト型ペイメントプロセッサソフトウェアの最新リリースです。 バージョン1.8.0のリリースノートには、「このバージョンでは、カスタムチェックアウトフォームや、 店舗のブランディングオプション、再設計されたPOSキーパッド、新しい通知アイコンとアドレスラベルが追加されました。」とあります。

  • LND v0.16.0-beta.rc2は、この人気のLN実装の新しいメジャーバージョンのリリース候補です。

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

今週のBitcoin CoreCore LightningEclairLDKLNDlibsecp256k1Hardware Wallet Interface (HWI)Rust BitcoinBTCPay ServerBDKBitcoin Improvement Proposals(BIP)、およびLightning BOLTsの注目すべき変更点。

  • LND #7462では、リモート署名とステートレスinit機能を使用した監視専用ウォレットの作成が可能になりました。