今週のニュースレターでは、エフェメラル・アンカーに関する提案のアップデートと、 Wizardsardineで働く開発者によるminiscriptに関するフィールドレポートの寄稿を掲載しています。 また、新しいソフトウェアのリリースとリリース候補の発表や、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更のなど、恒例のセクションも含まれています。

ニュース

  • ● エフェメラル・アンカーの支払いからマリアビリティを排除する: Gregory Sandersは、エフェメラル・アンカーの提案の微調整について Delving Bitcoinフォーラムに投稿しました。 エフェメラル・アンカーにより、誰もが使用可能（anyone-can-spend）なアウトプットスクリプトを使用して トランザクションにゼロ値のアウトプットを含めることができるようになります。 誰でもこのアウトプットを使用できるため、誰でもアウトプットを作成したトランザクションの CPFPによる手数料の引き上げを行うことができます。 これは、支払うべき手数料率を正確に予測する前にトランザクションが署名されることが多い LNなどのマルチパーティコントラクトプロトコルにとって便利です。 エフェメラル・アンカーを使用すると、コントラクトの参加者は誰でも必要と思われるだけ手数料を追加することができます。 他の参加者、もしくは何らかの理由で他のユーザーが、より高い手数料を追加したい場合は、 CPFPによる手数料の引き上げを、より高い手数料率のCPFPに置き換えることができます。

    提案されている誰もが使用可能なスクリプトは、OP_TRUEと同等のスクリプトで、 空のインプットスクリプトを持つインプットで使用可能です。 Sandersが今週投稿したように、レガシーなアウトプットスクリプトを使用することは、 それを使用する子トランザクションのtxidが変更可能であることを意味します。 どのマイナーもインプットスクリプトにデータを追加して、子トランザクションのtxidを変更することができます。 そのため、トランザクションが承認されたとしても、孫トランザクションを無効にする別のtxidで承認される可能性があるため、 子トランザクションを手数料の引き上げ以外の用途に使用するのは賢明ではありません。

    Sandersは、代わりに、将来のsegwitのアップグレード用に予約されているアウトプットスクリプトの１つを使用することを提案しています。 この場合、segwitでは4バイト、素のOP_TRUEでは１バイトであるため、若干ブロックスペースが増加しますが、 トランザクションマリアビリティに関する懸念は解消されます。スレッドでの議論の後、 Sandersは、マリアビリティを気にせずトランザクションサイズを最小限に抑えたい人向けのOP_TRUEバージョンと、 若干大きいものの子トランザクションの変更を許可しないsegwitバージョンの両方を提供する提案をしました。 スレッドでは、覚えやすいbech32mアドレスを作成するために segwitアプローチで余分なバイトを選択することに焦点を当てた議論が行われました。

フィールドレポート: Miniscriptの旅路

WizardsardineのAntoine Poinsotより

miniscriptに対する私たちの（実用的な）興味は、2020年初頭に、 当時利用可能なスクリプトプリミティブのみを使用するマルチパーティVaultアーキテクチャである Revaultを設計していた頃に始まりました。

私たちは当初、固定の参加者のセットを使用したRevaultを紹介しました。 運用環境で、より多くの参加者に一般化しようとするとすぐに問題に遭遇しました。

  • 実際、デモで使用したスクリプトは安全だろうか？宣伝されているすべての方法で使用可能なのか？ 宣伝されている以外の使用方法はないのか？
  • たとえそうだとしても、それを様々な数の参加者に一般化し、安全性を保つためにはどうすればいいのか？ いくつかの最適化を適用して、その結果のスクリプトが同じセマンティクスを持つようにするにはどうすればいいか？
  • さらに、Revaultは（支払いポリシーを強制するため）事前署名されたトランザクションを使用している。 スクリプトの構成から、手数料の引き上げに割り当てる予算を事前に把握するにはどうしたらいいか？ これらのスクリプトを使用するトランザクションが最も一般的な標準性チェックをパスすることをどうやって確認できるだろうか？
  • 最後に、スクリプトが意図されたセマンティクスに対応し、常に使用可能であると仮定しても、 具体的にどのように使用できるだろうか？例えば、考えられるすべての構成について満足のいくwitness（署名）を作成するには どうすればいいだろうか？ハードウェア署名デバイスと互換性のあるものにするにはどうすればいいか？

miniscriptがなかったら、これらの問いは難題になっていたでしょう。 ガレージにいる2人の男が、その場でスクリプトを作成するソフトウェアを書き、 最善を尽くし、その上でそれをセキュリティを強化するBitcoinウォレットと呼ぶつもりはないでしょう。 私たちはRevaultの開発を中心に会社を設立したいと考えていましたが、 安全な製品を市場に投入できるという合理的な保証を投資家に提供しなければ、資金を得ることはできませんでした。 また、資金がなければ、これらのエンジニアリングの課題をすべて解決することはできないでしょう。

miniscriptは、「構造化された方法でBitcoin Script（のサブセット）を記述し、 分析、組み合わせ、汎用署名などを可能にする言語です。[…]合成を可能にする構造を持っています。 さまざまな特性（使用条件、正当性、セキュリティ特性、マリアビリティなど）を静的に分析するのがとても簡単です。」 これはまさに私たちが必要としていたものです。この強力なツールを手に入れたことで、 投資家により良い保証[0]を提供することができ、資金を調達し、Revaultの開発を開始することができました。

当時、miniscriptはBitcoinアプリケーション開発者にとって すぐに使用できるソリューションにはまだほど遠いものでした（もし、なたが2023年以降にこれを読んでいる新しい Bitcoin開発者であれば、そう、私たちはBitcoin Scriptを手で書いていた時期がありました）。 私たちは、miniscriptをBitcoin Coreに統合し（PR #24147、 #24148、#24149参照）、 Revaultウォレットのバックエンドとして使用し、署名デバイスメーカーにファームウェアを実装するよう説得する必要がありました。 後者が最も困難でした。

これは鶏と卵の問題でした。ユーザーからの需要がないのに、メーカーがminiscriptを実装するインセンティブは低かったのです。 そして私たちは、署名デバイスのサポートなしにRevaultをリリースすることはできませんでした。 幸運なことに、このサイクルは、2021年3月にStepan Snigirevによって Specter DIYにminiscriptディスクリプターのサポートが 導入されたことで最終的に解消しました。 しかし、Specter DIYは長い間、単なる「機能的なプロトタイプ」であるみなされ、 Salvatore Ingalaは2022年にLedger Nano S(+)用の新しいBitcoinアプリで初めて 製品化可能な署名デバイスにminiscriptを導入しました。 このアプリは、2023年1月にリリースされ、最も人気のある署名デバイスをサポートした Lianaウォレットを公開することができました。

miniscriptの旅路を締めくくるには、最後の開発が残っています。 Lianaはリカバリーオプションに焦点を当てたBitcoinウォレットです。 このウォレットでは、タイムロックされたリカバリー条件（たとえば、 通常は資金を使用できないサードパーティのリカバリー鍵や、 減衰/拡大するマルチシグなど）を指定できます。 miniscriptは当初、P2WSHスクリプトでのみ利用可能でした。 Taprootがアクティベートされてから2年近く経ちますが、 資金を使用する度にリカバリーの支払い条件をオンチェーンで公開しなければならないのは残念なことです。 このため、私たちはminiscriptをTapscriptに移植する作業を行ってきました（ こちらとこちらを参照）。

未来は明るいです。ほとんどの署名デバイスがminiscriptのサポートを実装しているか、 実装中（たとえば、最近のBitboxやColdcard）なのに加えて、 Taprootとminiscriptのネイティブフレームワークが洗練されているため、 安全なプリミティブを使用したBitcoin上のコントラクトはこれまで以上にアクセスしやすくなっています。

オープンソースのツールやフレームワークへの資金提供によって、革新的な企業が競争し、 より一般的にはプロジェクトを実行するための参入障壁がどう低くなるかに注目することは興味深いことです。 ここ数年で加速しているこの傾向は、この分野の未来に希望を抱かせてくれます。

[0] もちろんリスクはまだありました。しかし、少なくともオンチェーンの部分は乗り越えられると確信していました。 オフチェーンの方は（予想どおり）もっと難しいことが分かりました。

リリースとリリース候補

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

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

今週の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 #28207は、mempoolがディスクに保存される方法を更新しました （通常はノードのシャットダウン時に行われますが、savemempool RPCによってトリガーされることもあります）。 これまでは、基礎となるデータを単純にシリアライズして保存していました。 現在は、シリアライズされたデータが、各ノードで独立して生成されたランダム値によってXORされ、 データを難読化します。難読化を解除するため、ロード時に同じ値でXORされます。 この難読化により、誰かがトランザクションに特定のデータを入れて、 ウィルススキャナーのようなプログラムが保存されたmempoolのデータに危険フラグを付けるような、 特定のバイト列を表示させることができなくなります。 同じ方法が以前PR #6650でUTXOセットを保存するために適用されました。 ディスクからmempoolのデータを読み取る必要があるソフトウェアは、それ自体でXORの演算を適用するか、 難読化されない形式での保存を要求するために-persistmempoolv1の設定を使用できます。 後方互換の設定は将来のリリースで削除される予定です。

  • ● LDK #2715では、ノードはオプションで配送されると想定されている値よりも小さい金額のHTLCを 受け入れることができるようになりました。 これは、上流のピアが新しいJITチャネルを通じてノードに支払う場合に便利です。 この場合、上流のピアにオンチェーントランザクションの手数料がかかり、 ノードに支払われるHTLCの金額からその手数料を差し引く必要があります。 この機能の上流側に関するLDKの以前の実装については、ニュースレター #257を参照ください。