今週のニュースレターでは、Bitcoin Stack Exchangeからの人気のある質問と回答や、 Taprootの準備に関する情報、新しいリリースおよびリリース候補のリスト、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションが含まれています。

ニュース

今週は重要なニュースはありません。

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

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

Taprootの準備 #19: 将来のコンセンサスの変更

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

ブロック709,632でのTaprootのアクティベーションが近づくにつれ、 開発者がTaproot上に構築したいと以前から表明していたコンセンサスのいくつかの変更を楽しみにするようになりました。

  • ● インプットをまたいだ署名の集約: Schnorr署名は、複数の異なる公開鍵と秘密鍵のペアの所有者が、 協力して署名を作成したことを証明する単一の署名を簡単に作成することができます。

    将来のコンセンサスの変更により、 トランザクションで使用されているすべてのUTXOの所有者がその支払いを承認したことを証明する 単一の署名をトランザクションに含めることができるようになる可能性があります。 これにより、最初のインプットの後は、keypathでの支払い毎に約16 vbyteが節約され、 統合やCoinJoinでの大幅な節約につながります。 これにより、CoinJoinベースによる支払いの方が、自分単独の支払いよりも安くなり、 より多くのプライベートな支払いを行う緩やかなインセンティブを提供します。

  • ● SIGHASH_ANYPREVOUT: 通常のBitcoinのトランザクションには、1つ以上のインプットが含まれており、 そのインプットのそれぞれがtxidを使って以前のトランザクションアウトプットを参照しています。 この参照により、Bitcoin Coreのような完全な検証ノードに、トランザクションがどれだけの金額を使用できるか、 またその支払いが許可されたことを証明するためにどんな条件を満たす必要があるかが伝えられます。 Bitcoinトランザクションの署名を生成するすべての方法は、Taprootを使用する場合も使用しない場合も、 prevoutのtxidにコミットするか、prevoutにまったくコミットしないかのいずれかです。

    これは事前に準備された正確な一連のトランザクションを使用したくないマルチユーザー・プロトコルにとって問題となります。 ユーザーが特定のトランザクションをスキップしたり、witnessデータ以外のトランザクションの詳細を変更したりすると、 後続のトランザクションのtxidが変更されます。 txidを変更すると後続のトランザクション用に事前に作成されていた署名が無効になります。 これによりオフチェーンプロトコルは古いトランザクションを送信したユーザーにペナルティを与える （LN-penaltyなど）を実装しなければなりません。

    SIGHASH_ANYPREVOUTは、 署名がprevout txidへのコミットをスキップすることを許可することで、 この問題を解消することができます。使用される他のフラグによっては、 prevoutやトランザクションに関する他の詳細（金額やScriptなど）にコミットしますが、 以前のトランザクションで使用されていたtxidは関係なくなります。 これにより、LNのeltooレイヤーの実装や、 Vaultや他のコントラクトプロトコルの改善の両方が可能になります。

  • ● 委譲と一般化: （Taprootまたはそれ以外の）Scriptを作成した後は、 秘密鍵を渡さない限り、そのScriptから支払いをする能力を他の人に委譲する方法はほぼありません （BIP32ウォレットを使っている場合はとても危険です）。 さらにTaprootは、keypathによる支払いや少数のScriptベースの条件のみを使用したいユーザーにとって、 より手軽な価格を提供します。Taprootを一般化し、署名者の委譲を行うことで、 Taprootを強化する方法がいくつか提案されています:

    • ● Graftroot: Taprootのアイディアが紹介された直後に提案されたGraftrootは、 誰もがTaprootのkeypath支払いをできるようにする追加機能を与えるものです。 keypathの署名者は資金を直接使用する代わりに、資金を使用できる新しい条件を記述したScriptに署名し、 そのScriptの条件を満たすことができる人に使用権限を委譲することができます。 署名およびScript、そのScriptを満たすために必要なデータが、支払いトランザクションで提供されます。 keypathの署名者は、実際に支払いが発生するまで、オンチェーンデータを作成することなく、 この方法で無制限の数のScriptに委譲することができます。

    • ● 一般化されたTaproot (g’root): その数ヶ月後、Anthony Townsは、公開鍵ポイントを使って、 必ずしもMASTのような構造を使わずに、 複数の異なる支払い条件にコミットする方法を提案しました。 この一般化されたTaproot (g’root) 構造は、「Taprootの仮定が成立しない場合に、 より効率的になる可能性がある」としています。 また、「ソフトフォーク・セーフなインプットをまたぐ集約システムを簡単に構築する方法を提供する」 としています。

    • ● Entroot: Graftrootとg’rootを最近合成したもので、 多くのケースを単純化し、より帯域幅を効率化しています。これは、トップレベルのkeypath支払いを作成できる人だけでなく、 entrootブランチのいずれかを満たすことができる誰からでも署名者の委譲をサポートすることができます。

  • ● 新旧opcode: Taprootのソフトフォークには、 Bitcoinに新しいopcodeを追加するための改良された方法（OP_SUCCESSx opcode）を提供する Tapscriptのサポートが含まれています。 Bitcoinの初期に追加されたOP_NOPx (no operation) opcodeと同様に、 OP_SUCCESSx opcodeは、常にsuccessを返すことのないopcodeに置き換えられるよう設計されています。 提案されている新しいopcodeには次のようなものがあります:

    • ● 旧opcodeの復活: 数式や文字列操作のための多くのopcodeが、セキュリティの脆弱性への懸念から2010年に無効化されました。 多くの開発者は、これらのopcodeがセキュリティレビューを経て再び有効になること、 そして（場合によっては）より大きな数値が扱えるよう拡張されることを期待しています。

    • ● OP_CAT: 以前無効化されたopcodeの内の１つで、特筆すべきはOP_CATです。 研究者が、OP_CAT自体でBitcoinのあらゆる種類の興味深い動作を可能にしたり、 興味深い方法で他の新しいopcodeと組み合わせることができることを発見しています。

    • ● OP_TAPLEAF_UPDATE_VERIFY: ニュースレター #166に掲載したように、OP_TLUV opcodeは、 Taprootのkeypathとscriptpathの機能を使って特に効率的かつ強力なCovenantsを可能にします。 これは、JoinPoolやVaultおよび、 その他のセキュリティやプライバシーの改善を実装するために使用できます。 また、OP_CHECKTEMPLATEVERIFYとうまく組み合わせることができます。

上記のアイディアはすべて、まだ提案に過ぎません。どれも成功するとは限りません。 各提案を成熟させるのは研究者や開発者であり、その後Bitcoinに各機能を追加することが、 Bitcoinのコンセンサスルールを変更する労力に値するかどうかをユーザーが判断することになります。

リリースとリリース候補

人気の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 #23002では、新しいウォレットを作成する際に、 descriptorベースのウォレットをデフォルトにします。 descriptorベースのウォレットは、Bitcoin Core PR #16528で初めて導入されました。 すべてのウォレットをdescriptorベースのものに移行し、最終的にレガシーウォレットのサポートを終了させるという 長期的な計画があります。

  • ● Bitcoin Core #22918は、getblockRPCと/rest/block/エンドポイントを拡張し、 ブロックで使用されている以前作成された各アウトプット（”prevout”）に関する情報を含む 新しいレベルのverbosity (3)を提供します。

    ブロックが新しい未使用トランザクションアウトプット（UTXO）を作成すると、 Bitcoin Coreはそれをデータベースに保存します。後続のトランザクションがそのUTXOを使おうとすると、 Bitcoin Coreはそれをデータベースから取得し、それを使用するために必要な条件をすべて満たしているかどうか （正しい公開鍵に対する有効な署名が含まれているかなど）検証します。 ブロック内のすべての支払いが有効な場合、 Bitcoin CoreはこれらのprevoutのエントリーをUTXOデータベースからundoファイルに移動します。 このファイルは、その後でブロックが再編成中にチェーンから削除された場合に、 UTXOデータベースを以前の状態に戻すために使用できます。

    このPRは、undoファイルからprevoutを取得し、ブロックに実際に含まれているか、 その内容から計算される情報の一部としてそれらを含めます。 prevoutのデータを必要とするユーザーやアプリケーションにとっては、 各トランザクションとそのアウトプットを直接調べるよりも、この方法の方がはるかに高速で便利です。 プルーニングを有効にしているフルノードでは、古いundoファイルは削除されるため、 これらのブロックに対して新しいverbosityレベル3を使用することはできません。

  • ● C-Lightning #4771は、他の条件が同じであれば、 より大きな資金量（チャネルキャパシティ）を持つチャネルを含む経路を優先するようpayコマンドを更新しました。 チャネルの総資金量は公開されていますが、チャネルの各方向にどれだけの資金があるかは公開されていません。 しかし、2つのチャネルがそれぞれある状態になる確率が等しい場合、 キャパシティが大きいチャネルの方が小さいチャネルよりも支払いサイズを処理できる可能性が高いと言えます。

  • ● C-Lightning #4685では、BOLTs #891のドラフト仕様に基づいた 実験的なwebsocketトランスポートが追加されています。 これにより、C-Lightning（および、同じプロトコルをサポートする他のLN実装）は、 ピアとの通信に使用する代替ポートを配信できるようになります。 基本的なLN通信プロトコルは同じまま、純粋なTCP/IPではなく、バイナリのwebsocketフレームを使って実行されるだけです。

  • ● Eclair #1969は、findroute*系のAPIコールに、 ignoreNodeIDs、ignoreChannelIDsおよびmaxFeeMsatというパラメータを追加しました。 また、発見した経路に関するすべての情報を返すfullフォーマットも追加されています。

  • ● LND #5709 (元々は #5549) は、 Lightning Pool（ニュースレター #123参照）をサポートするノード間（現在はLNDノードのみ）で使用するための 新しいコミットメントトランザクションフォーマットを追加しました。 この新しいフォーマットにより、チャネルのリースをオファーするノードは、 リース期間が終了するまで、その資金をオンチェーンで使用することができなくなります。 これによりリース期間中はチャネルを開いておき、 資金（流動性）を使ってルーティング手数料を稼げるようにするというインセンティブが働きます。 チャネルのコミットメントトランザクションフォーマットは、チャネルが開いている間、 その2つのダイレクト・ピア間でのみ確認されるため、ネットワーク上の他のノードに影響を与えること無く、 どんなフォーマットでも使用することができます。

  • ● LND #5346では、LNDノードとそのピアが、タイプ識別子が32,767以上のカスタムメッセージを交換できる機能を追加しました。 プルリクエストでは、カスタムメッセージのいくつかの推奨される使用法が提案されています。 lncliコマンドが更新され、カスタムピアメッセージの送信と受け入れが簡単になりました。

  • ● LND #5689では、LNDノードがすべての秘密鍵の操作を、リモートのほとんどオフラインの署名ノードに委譲する機能が追加されました。 詳細なドキュメントはこちらです。

  • ● BTCPay Server #2517では、LN経由でのペイアウトや払い戻しの発行が可能になりました。 管理者は支払い金額を入力し、受信者は自分のノードの詳細を入力して支払いを受け取ることができます。

  • ● HWI #497は、Trezorファームウェアを使用してデバイスに追加情報を送信し、 お釣り用のアドレスがマルチシグのフェデレーションに属しているか検証できるようにします。 それ以外の場合、Trezorはお釣りを個別の支払いとして表示し、ユーザーはお釣り用アドレスが正しいか手動で確認する必要があります。