en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #348

Apr 4, 2025

今週のニュースレターでは、Bitcoinのsecp256k1曲線の楕円曲線暗号の教育目的の実装のリンクを掲載しています。また、コンセンサスの変更に関する議論や、新しいリリースとリリース候補の発表、人気のBitcoinインフラストラクチャソフトウェアの注目すべき変更など、恒例のセクションも含まれています。

ニュース

● 教育および実験ベースのsecp256k1実装: Sebastian FalbesonerおよびJonas NickとTim Ruffingは、 Bitcoinで使用される暗号関連のさまざまな機能のPython実装を Bitcoin-Devメーリングリストで発表しました。彼らは、この実装は「安全ではなく（原文では大文字）」、「プロトタイプの作成や、実験、教育用である」と警告しています。

また、いくつかのBIP（340、324、327、352）の参照コードとテストコードは、既に「secp256k1のカスタム実装と場合によっては微妙に異なる実装」が含まれていることも言及しています。彼らは、今後この状況を改善したいと考えています。おそらく、今後のChillDKG（ニュースレター #312参照）のBIPから始めることになるでしょう。

コンセンサスの変更

Bitcoinのコンセンサスルールの変更に関する提案と議論をまとめた月次セクション

● 量子コンピューターによる盗難と耐性に関する複数の議論: 量子コンピューターがビットコインを盗むのに十分な性能を持つようになった場合、ビットコイナーはどのような対応ができるかについて検討されました。
- ● 脆弱なビットコインは破棄されるべきか？ Jameson Loppは、量子耐性へのアップグレードパスが採用され、ユーザーが解決策を採用する時間が取れた後、量子コンピューターを利用した盗難に脆弱なビットコインを破棄することについて、いくつかの主張をBitcoin-Devメーリングリストに投稿しました。いくつかの主張は次のとおりです:
  - ● 一般的な選択の主張: 彼は、ほとんどの人が、高速な量子コンピューターを持つ誰かに盗まれるよりも、破棄されることを望むと考えています。特に、窃盗犯は「量子コンピューターにいち早くアクセスできる数少ない特権階級」の一人だろうからと、彼は主張しています。
  - ● 共通の被害の主張: 盗まれるビットコインの多くは、紛失したコインか、長期保有を予定していたコインのいずれかでしょう。対照的に、窃盗犯は盗んだビットコインをすぐ使ってしまう可能性があり、他のビットコインの購買力を低下させます（マネーサプライのインフレと同様に）。ビットコインの購買力が低下すると、マイナーの収入が減少し、ネットワークのセキュリティを低下させ、（彼の観察によると）ビットコインを受け入れるマーチャントが少なくなると指摘しています。
  - ● 最小限の利益の主張: 盗難を許可すれば量子コンピューターの開発資金を提供できるようになりますが、コインを盗むことは、Bitcoinプロトコルの誠実な参加者に直接的な利益はもたらしません。
  - ● 明確な期限の主張: 量子コンピューターを持つ誰かがビットコインを盗み始める日を、誰も事前に知ることはできません。しかし、量子コンピューターに対して脆弱なコインが破棄される特定の日付は、事前に完全に正確に発表できます。その明確な期限により、ユーザーがビットコインを期間内に再保護するインセンティブが高まり、失われるコインの総数は減ります。
  - ● マイナーのインセンティブの主張: 前述のように、量子コンピューターによる盗難は、マイナーの収入を減らす可能性があります。ハッシュレートの過半数を保持する多数派は、量子コンピューターに対して脆弱なビットコインの使用を検閲することができます。他のビットコイナーが別の結果を望んだとしても彼らはそのような行動をする可能性があります。
  Loppは、脆弱なビットコインの破棄に反対するいくつかの主張も示していますが、破棄を支持する結論を出しています。
  
  Nagaev Borisは、アップグレードの期限を過ぎてタイムロックされているコインも破棄すべきかどうかを問いました。 Loppは、長期のタイムロックの落とし穴を指摘し、個人的には「1，2年以上資金をロックするのは不安だ」と語っています。
- ● SHA256プリイメージを公開することでUTXOの所有を安全に証明する: Martin Habovštiakは、ECDSAやSchnorr署名が安全ではなくなった場合でも（高速な量子コンピューターが登場した後など）、誰かがUTXOを管理していることを証明できるようにするアイディアを Bitcoin-Devメーリングリストに投稿しました。 UTXOにこれまで公開されたことのないSHA256コミットメント（または他の量子耐性のあるコミットメント）が含まれていれば、そのプリイメージを公開するためのマルチステッププロトコルをコンセンサスの変更と組み合わせることで量子コンピューターによる盗難を防ぐことができます。これは、 Tim Ruffingの以前の提案（ニュースレター #141参照）と基本的に同じで、彼はそれが一般的にGuy Fawkesの署名スキームとして知られていることを知りました。これは、マイナーの検閲に対する耐性を向上させるために、Adam Backが2013年に考案したスキームのバリエーションでもあります。つまり、プロトコルは以下のように機能します:
  1. アリスは何らかの方法でSHA256コミットメントを行うアウトプットへの資金を受け取ります。これは、P2PKH、P2SH、P2WPKH、P2WSHのような直接ハッシュされるアウトプット、または、スクリプトパスを含むP2TRアウトプットにすることができます。
  2. アリスが同じアウトプットスクリプトに対して複数の支払いを受け取った場合、それらすべての支払いを使用する準備ができるまで、それらを一切使用しないか（P2PKHおよびP2WSHでは必ず、 P2SHおよびP2WSHでも実質的に）、または使用する際に少なくとも1つのプリイメージが明らかにならないように細心の注意を払う必要があります（P2TRのキーパスとスクリプトパスでは簡単に可能）。
  3. アリスは使用する準備ができると、通常通り支払いトランザクションを非公開で作成しますが、ブロードキャストはしません。また、トランザクション手数料を支払うために、量子安全な署名アルゴリズムで保護されたビットコインも入手します。
  4. 量子安全なビットコインの一部を使用するトランザクションでは、アリスは使用したい量子安全ではないビットコインにコミットし、非公開の支払いトランザクションにもコミットします（公開せずに）。アリスはこのトランザクションが深く承認されるまで待ちます。
  5. アリスは、トランザクションが実質再編成できないようになったことを確認したら、これまで非公開だったプリイメージと量子安全ではない支払いを公開します。
  6. ネットワーク上のノードは、ブロックチェーンを検索して、プリイメージにコミットする最初のトランザクションを見つけます。そのトランザクションがアリスの量子安全ではない支払いにコミットしている場合、アリスの支払いを実行します。そうでない場合は、何もしません。
  これにより、アリスは、自分の支払いトランザクションが量子コンピューターのオペレータによる支払いの試みよりも優先されることを確認するまで、量子コンピューターに対して脆弱な情報を公開する必要がなくなります。プロトコルのより正確な説明については、Ruffingの2018年の投稿をご覧ください。スレッドでは説明されていませんが、上記のプロトコルはソフトフォークとして展開できると考えています。
  
  Habovštiakは、このプロトコルを使って安全に使用できるビットコイン（たとえば、そのプリイメージがまだ公開されていない）は、コミュニティが量子耐性のあるビットコイン全体を破棄すると決定した場合でも破棄すべきではないと主張しています。また、緊急時でも一部のビットコインを安全に使用できるため、短期的には量子耐性スキームを展開する緊急性が低下すると主張しています。
  
  Lloyd Fournierは、「このアプローチが受け入れられれば、ユーザーがすぐに実行できる行動は、 Taprootウォレットに移行することだ思う」と述べています。 Taprootウォレットは、現在のコンセンサスの下で、アドレスの再利用も含めてキーパスでの支払いを許可できるだけでなく、キーパス支払いが後に無効にされた場合、量子コンピューターによる盗難に対する耐性もあるからです。
  
  別のスレッドで（次の項目を参照）、Pieter Wuilleは量子コンピューターによる盗難に対して脆弱なUTXOには、公開されていないが、さまざまな形態のマルチシグ（LNやDLC、エスクローサービスを含む）など、複数の参加者が知っている鍵も含まれると指摘しています。
- ● 量子安全ではないビットコインを破棄するためのBIPドラフト: Agustin Cruzは、量子コンピューターによる盗難の恐れがある（それが予想されるリスクとなった場合に）ビットコインを破棄する一般的なプロセスについて、いくつかの選択肢を説明するBIPのドラフトをBitcoin-Devメーリングリストに投稿しました。 Cruzは、「移行の期限を強制することで、正当な所有者に資金を確保するための明確で譲れない機会を提供します[…] 十分な通知と堅牢な保護手段を伴う強制的な移行は、現実的でBitcoinの長期的なセキュリティを保護するために必要です」と主張しています。
  
  スレッドの議論のほとんどは、BIPドラフトに焦点をあてたものではありません。そのほとんどは、量子安全でないビットコインを破棄することが良いアイディアなのかどうかに焦点を当てており、これは後にJameson Loppが始めたスレッド（前述のサブ項目で説明）と同様でした。
● CTV+CSFSソフトフォークに関する複数の議論: OP_CHECKTEMPLATEVERIFY（CTV）と OP_CHECKSIGFROMSTACK（CSFS）opcodeのソフトフォークのさまざまな側面について、複数の会話で検討されました。
- ● CTVの動機に対する批判: Anthony Townsは、BIP119に記載されているCTVの動機に対する批判を投稿しました。彼は、この動機は、CTVとCSFSの両方をBitcoinに追加することで損なわれると主張しました。議論が始まってから数日後、BIP119は作者によって更新され、物議を醸している文言のほとんど（おそらくすべて）が削除されました。変更の概要についてはニュースレター #347を、また参考としてBIP119の旧バージョンをご覧ください。議論されたトピックには次のようなものがありました:
  - ● CTV+CSFSにより永久のコベナンツの作成が可能になる: CTVの動機には、「コベナンツは、実装が複雑すぎることと、コベナンツによりロックされたコインの流動性を低下させるリスクがあることから、歴史的にビットコインには不向きであると広く考えられてきました。このBIPは、 テンプレートと呼ばれるシンプルなコベナンツを導入し、大きなリスクなしに、非常に価値のあるユースケースの限定されたセットを可能にします。 BIP119のテンプレートは、動的な状態を持たない非再帰的な完全列挙型のコベナンツを可能にします。（強調は原文のまま）」とあります。
    
    Townsは、CTVとCSFSの両方を使用するスクリプトを説明し、 MutinyNet signet上でそれを使用するトランザクションをリンクしています。このトランザクションは、スクリプト自体に同じ金額を送る場合のみ使用できます。定義については議論がありましたが、CTVの作者は以前、機能的に同様の構成を再帰的コベナンツと説明しており、 Optechはその会話の要約でその慣例に従いました（ニュースレター #190参照）。
    
    Olaoluwa Osuntokunは、CTVを使用するスクリプトが「完全に列挙され」、「動的な状態がない」ままであることに関するCTVの動機を擁護しました。これは、CTVの作者（Jeremy Rubin）が2022年に行った主張と似ています。 Rubinは、Townsが設計したpay-to-selfタイプのコベナンツを「再帰的だが完全な列挙型」と呼びました。 Townsは、CSFSを追加すると、完全列挙の主張されている利点が損なわれると反論しました。彼は、CTVまたはCSFSのBIPを更新し、「CTVとCSFSの組み合わせによって、何らかの形で恐ろしく、それでも防止されるユースケース」について記載するよう求めました。これは、SIGHASH_ANYPREVOUTを使用すると可能になるが、 CTV+CSFSを使用すると不可能な「自己複製オートマトン（俗にSpookChainsと呼ばれる）」を記載した BIP119の最近の更新で行われた可能性があります。
  - ● CTVとCSFS用のツール: Townsは、上記の再帰スクリプトを開発するために既存のツールを使うのは難しいと指摘し、これは導入の準備が整っていないことを示唆しています。Osuntokunは、彼が使用しているツールは「非常にシンプル」であると述べています。 TownsもOsuntokunも、使用したツールについては言及していません。 Nadav Ivgiは、自身のMinsc言語を使用したサンプルを示し、「Minscを改良して、このような作業を簡単にすることに取り組んでいます。 Minscは、TaprootやCTV、PSBT、ディスクリプター、Miniscript、スクリプト、BIP32などをサポートしています。」と述べています。ただし、「その多くはまだ文書化されていません」と認めています。
  - ● 代替案: Townsは、CTV+CSFSを、代替スクリプト言語を提供する彼のBasic Bitcoin Lisp Language（bll）とSimplicityと比較しています。Antoine Poinsotは、理解しやすい代替言語は、理解しにくい現在のシステムへの小さな変更よりもリスクが少ない可能性があると示唆しています。開発者のMoonsettlerは、Bitcoinスクリプトに段階的に新しい機能を導入することで、表現力が高まるにつれて予期せぬ自体に遭遇する可能性が低くなるため、後でさらに機能を追加しても安全になると主張しています。
    
    OsuntokunとJames O’Beirneはどちらも、CTVやCSFSと比べて、 bllやSimplicityの準備ができているという主張を批判しています。
- ● CTV+CSFSの利点: Steven Rooseは、表現力をさらに高める他の変更の第一段階として、CTVとCSFSをBitcoinに追加する提案を Delving Bitcoinに投稿しました。議論のほとんどは、CTV、CSFS、またはその両方を組み合わせた場合に可能になる利点の認定に焦点が当てられました。これには以下が含まれます:
  - ● DLC: CTVとCSFSはどちらも個別に、DLCを作成するのに必要な署名の数を減らすことができます。特に、大量の契約のバリエーション（1ドル単位のBTC-USD価格の契約など）に署名するDLCにとっては重要です。 Antoine Poinsotは、BitcoinユーザーがDLCにあまり興味がないことを示す証拠として、 DLCサービスプロバイダーが閉鎖するという最近の発表をリンクし、数ヶ月前にJonas Nickが述べた「DLCはBitcoinで意味のある採用には至っておらず、その限れれた利用はパフォーマンスの制限によるものではないようだ」という投稿をリンクしました。返信には、まだ機能している他のDLCサービスプロバイダーのリンクがあり、その中には、「3,000万ドルの資金調達」を行ったと主張するプロバイダーも含まれています。
  - ● Vault: CTVは、署名済みトランザクションと（オプションで）秘密鍵の削除を使用した現在のBitcoinで可能な Vault（金庫）の実装を簡単にします。Anthony Townsは、このタイプのVaultはあまり興味深いものではないと主張します。 James O’Beirneは、CTVまたは同様のものが、彼のBIP345 OP_VAULT Vaultなどのより高度なタイプのVaultを構築するための前提条件であると反論しています。
  - ● Accountable Computing Contract: CSFSは、スクリプトベースのランポート署名を実行する現在の必要性を置き換えることで、 BitVMなどのAccountable Computing Contractの多くの手順を排除できます。 CTVは、追加の署名演算の一部を削減できる可能性があります。Poinsotは、 BitVMに大きな需要があるかどうかを再度尋ねます。 Gregory Sandersは、シールドClient-side Validation（ニュースレター #322参照）の一部として、トークンの双方向ブリッジが興味深いと答えています。しかし、CTVもCSFSもBitVMのトラストモデルを大幅に改善するものではなく、他の変更によってトラストを低下させたり、他の方法でコストのかかる演算の数を減らしたりできる可能性があるとも述べています。
  - ● Liquidのタイムロックスクリプトの改善: James O’Beirneは、 CTVは「コインを定期的に[移動する]必要がある[Blockstream]のLiquidタイムロックフォールバックスクリプトを大幅に改善する」という、Blockstreamの2人のエンジニアからのコメントを伝えました。説明を求めると、元BlockstreamエンジニアのSanket Kanjalkarは、そのメリットはオンチェーントランザクション手数料の大幅な節約になる可能性があると説明しました。 O’Beirneは、Blockstreamの研究ディレクターであるAndrew Poelstraからの追加情報も共有しました。
  - ● LN-Symmetry: CTVとCSFSを併用すると、LN-Symmetryを実装することができ、現在LNで使用されているLN-Penaltyチャネルの欠点の一部が解消され、 3人以上の参加者がいるチャネルを作成できるようになり、流動性の管理とオンチェーンの効率が向上する可能性があります。 SIGHASH_ANYPREVOUT（APO）を使用して LN-Symmetryの実験バージョン（ニュースレター #284参照）を実装したGregory Sandersは、 LN-SymmetryのCTV+CSFSバージョンはAPOほど機能が豊富ではなく、トレードオフが必要になると指摘しています。 Anthony Townsは、SandersのAPOの実験コードを最新のソフトウェアで実行し、 TRUCやエフェメラルアンカーなどの最近導入されたリレー機能を使用するように更新した人は誰もいないと付け加えました。まして、CTV+CSFSを使用するようにコードを移植した人は誰もいないため、その組み合わせのLN-Symmetryを評価する能力は制限されています。
    
    Poinsotは、ソフトフォークによって可能になった場合、LN開発者にとって LN-Symmetryの実装が優先事項になるかどうかを尋ねています。 2人のCore Lightningの開発者（現在LN-Symmetryと呼んでいるものを紹介した論文の共著者でもある）の発言から、それが優先事項であることが示されています。それに対し、LDKのリード開発者であるMatt Coralloは、「[LN-Symmetry]は、これを完成させる必要があるという意味ではそれほど興味深いとは思わない」と語っています。
  - ● Ark: Rooseは、Ark実装を構築している企業のCEOです。彼は、「CTVはArkにとってゲームチェンジャーです。[…]ユーザーエクスペリエンスに対する CTVの利点は否定できません。また、CTVが利用可能になり次第、両方の[Ark]実装でCTVが利用されることは間違いありません」と述べています。 Townsは、APOまたはCTVのいずれかを使ってArkをテスト用に実装した人はいないと指摘しました。 Rooseは、その後すぐにそれを実行するコードを書き、「非常に簡単」で、既存の実装の統合テストをパスしたと述べました。彼は、改善点のいくつかを数値化しました。CTVに切り替えた場合、「約900行のコードが削除でき、[…]独自のラウンドプロトコルが3から[2]に削減され、 [さらに]署名nonceと部分署名を渡す必要がなくなるため、帯域幅が改善できます」。
    
    Rooseは後に、ArkユーザーにとってのCTVの利点について議論する別のスレッドを開始しました（以下の要約を参照）。
- ● ArkユーザーにとってのCTVの利点: Steven Rooseは、現在signetに導入されているArkプロトコル（コベナンツレスArk（clArk）と呼ばれる）の簡単な説明と、 OP_CHECKTEMPLATEVERIFY（CTV）opcodeが利用可能になることで、最終的にmainnetに導入された際に、プロトコルのコベナンツ使用バージョンがユーザーにとってより魅力的になる可能性があることをDelving Bitcoinに投稿しました。
  
  Arkの設計目標の1つは、非同期支払い（受信者がオフラインの支払い）を可能にすることです。 clArkでは、これは、支払人とArkサーバーによって支払人の既存の事前署名済みトランザクションチェーンが拡張され、最終的に受信者が資金に対する排他的制御を受け入れることができるようにすることで実現しています。この支払いは、Ark out-of-round支払い（arkoor）と呼ばれます。受信者がオンラインになると、次の操作を選択できます:
  - ● 遅延後の退出: 事前署名済みトランザクションのチェーン全体をブロードキャストし、 Joinpool（Ark と呼ばれる）から退出します。支払人が同意したタイムロックの期限が切れるまで待つ必要があります。事前署名済みトランザクションが適切な深さまで承認されると、受信者は資金をトラストレスに制御できることを確信できます。ただし、迅速な決済や、UTXOの共有による手数料の削減など、Joinpoolの一部であることのメリットは失われます。また、トランザクションチェーンを承認するためにトランザクション手数料を支払う必要がある場合もあります。
  - ● 何もしない: 通常のケースでは、トランザクションチェーン内の事前署名されたトランザクションは最終的に期限切れとなり、サーバーが資金を請求できるようになります。これは盗難ではなく、プロトコルの予想される部分で、サーバーは請求された資金の一部またはすべてを何らかの方法でユーザーに返すことを選択できます。期限が近づくまで、受信者は待つことができます。
    
    異常ケースでは、サーバーと支払人は（いつでも）共謀して別のトランザクションチェーンに署名し、受信者に送信された資金を盗むことができます。注：Bitcoinのプライバシー特性により、サーバーと支払人が同一人物になることができるため、共謀が必要ない場合もあります。ただし、受信者がサーバーが署名したトランザクションチェーンのコピーを保持している場合は、サーバーが資金を盗んだことを証明できるため、他の人がそのサーバーの使用を阻止するのに十分な可能性があります。
  - ● リフレッシュ: サーバーの協力により、受信者は、支払人が共同で署名したトランザクションの資金の所有権を、受信者が共同署名者となった別の事前署名トランザクションにアトミックに移転できます。これにより、有効期限が延長され、サーバーと以前の支払人が共謀して以前送信した資金を盗む可能性がなくなります。ただし、リフレッシュでは、サーバーがリフレッシュされた資金を期限が切れるまで保持する必要があり、サーバーの流動性が低下するため、サーバーは受信者に期限が着れるまで金利を請求します（有効期限は固定されているため、前払い）。
  Arkのもう1つの設計目標は、参加者がLN支払いを受け取れるようにすることです。 Rooseは元の投稿と返信で、Joinpool内に既に資金を持っている既存の参加者は、 LN支払いを受け取るために必要な対話の実行ができなかった場合、オンチェーントランザクションのコストまでペナルティを課せられる可能性があると説明しています。ただし、Joinpool内に資金を持っていない参加者は、ペナルティを課せられないため、対話型の手順の実行を拒否して、コストをかけずに正直な参加者に問題を引き起こすことができます。これにより、Arkユーザーは、使用したいArkサーバーに既に適度な額を預け入れていない限り、 LN支払いを受け取ることが事実上できなくなるようです。
  
  Rooseは次に、CTVの利用によってプロトコルがどのように改善できるかを説明しています。主な変更点は、Arkラウンドの作成方法です。Arkラウンド は、オフチェーントランザクションのツリーにコミットする小さなオンチェーントランザクションで構成されます。 clArkの場合、これらは事前署名されたトランザクションで、そのラウンドのすべての支払人が署名できる必要があります。 CTVが利用可能な場合、トランザクションのツリーの各ブランチは、署名を必要とせずにCTVを使って子孫にコミットできます。これにより、ラウンドの作成時に利用できない参加者に対しても、トランザクションを作成でき、以下の利点があります:
  - ● ラウンド中の非対話型支払い: Arkのarkoor（out-of-round）支払いの代わりに、次のラウンドまで待つ意思のある支払人は、ラウンド中に受信者に支払いができます。受信者にとって、これは大きな利点です。ラウンドが適切な深さまで承認されると、受信者は受け取った資金に対するトラストレスな制御を受け取ります（有効期限が近づくまで、その時点で退出するか、安価にリフレッシュできます）。受信者は、複数の承認を待つ代わりに、サーバーが正直に動作するためにArkプロトコルによって作られたインセンティブをすぐに信頼することを選択できます（ニュースレター #253参照）。別の点として、Rooseは、これらの非対話型支払いをバッチ処理して、一度に複数の受信者に支払うこともできると指摘しています。
  - ● ラウンド中のLN支払いの受け入れ: ユーザーは、 LN支払い（HTLC）をArkサーバーに送信するよう要求できます。サーバーは、次のラウンドまで支払いを保留し、 CTVを使ってラウンドにHTLCロックされた支払いをユーザーに追加します。その後、ユーザーはHTLCのプリイメージを公開して支払いを請求できます。ただし、Rooseは、これには依然として「さまざまな不正使用防止対策」が必要であると指摘しています。（これは、受信者がプリイメージを公開しないリスクがあるためであり、サーバーの資金はArkラウンドの終了までロックされたままになり、2ヶ月以上続く可能性があります。）
    
    David Hardingは、Rooseに返信して詳細を尋ね、状況をLNのJITチャネルと比較しました。 JITチャネルでも、HTLCのプリイメージが公開されないことで、ライトニングサービスプロバイダー（LSP）に問題が生じるという同様の問題があります。 LSPは現在、トラストベースのメカニズムを導入することでこの問題に対処しています（ニュースレター #256参照）。同じソリューションをCTV-Arkで使用する予定であれば、それらのソリューションは、clArkでのLN支払いのラウンド中の受け入れも安全に許可すると思われます。
  - ● より少ないラウンド、署名、ストレージ: clArkはMuSig2を使用し、各参加者は複数のラウンドに参加し、複数の部分署名を生成し、完成した署名を保存する必要があります。CTVを使用すると、生成して保存する必要のあるデータが少なくなり、必要な対話も少なくなります。
● OP_CHECKCONTRACTVERIFYセマンティクス: Salvatore Ingalaは、提案中のOP_CHECKCONTRACTVERIFY（CCV）opcodeのセマンティクス、最初のBIPドラフトのリンクおよび、Bitcoin Coreへの実装のドラフトのリンクを Delving Bitcoinに投稿しました。彼の説明は、CCVの動作の概要から始まります。 CCVでは、公開鍵が任意のデータにコミットしていることをチェックできます。使用されるTaprootアウトプットの公開鍵と、作成されるTaprootアウトプットの公開鍵の両方をチェックできます。これを使って、使用されるアウトプットのデータが、作成されるアウトプットに引き継がれるようにすることができます。 Taprootでは、アウトプットの調整により、Tapscriptなどの Tapleafeにコミットできます。調整が1つ以上のTapscriptにコミットすると、アウトプットに制限（使用条件）が設定され、使用されるアウトプットに設定された条件が、作成されるアウトプットに転送されるようになります。これは、Bitcoinの専門用語では、一般的にコベナンツと呼ばれます（ただし議論の余地はありますが）。コベナンツによって制限を満たしたり変更が可能になる場合があり、これによって（それぞれ）コベナンツが終了するか、将来の反復の条件が変更されます。 Ingalaは、このアプローチの利点と欠点を次のように説明しています:
- ● 利点: Taprootネイティブで、 UTXOセット内のTaprootのエントリーのサイズが増加せず、追加データを必要としない使用条件のため、追加データをwitnessスタックに含める必要がありません（したがって、追加のコストが発生しません）。
- ● 欠点: Taprootのみで機能し、調整を確認するには、（たとえば）SHA256の演算よりもコストのかかる楕円曲線の演算が必要です。
使用条件を使用されるアウトプットから作成されるアウトプットに転送するだけでも便利ですが、多くのコベナンツでは、使用されるアウトプット内のビットコインの一部またはすべてが、作成されるアウトプットに渡されることを確実にしたいと考えています。Ingalaは、 CCVの金額の処理に関する3つの選択肢について説明しています。
- ● 無視: 金額はチェックしない
- ● 控除: 特定のインデックス（たとえば3つめのアウトプット）で作成されるアウトプットの金額が、同じインデックスで使用されるアウトプットの金額から差し引かれ、残った金額が追跡されます。たとえば、インデックス3で使用されるアウトプットの金額が100 BTCで、インデックス3で作成されるアウトプットの金額が70 BTCの場合、コードは残りの30 BTCを追跡します。作成されるアウトプットの金額が使用されるアウトプットの金額よりも多い場合、トランザクションは無効としてマークされます（残金が減り、おそらくゼロ未満になります）。
- ● デフォルト: 特定のインデックスで作成されるアウトプットの金額が、使用されるアウトプットの金額と デフォルト チェックでまだ使用されていない以前の残金の量の合計よりも多い場合を除き、トランザクションを無効とマークします。
アウトプットが控除で複数回チェックされる場合、または同じアウトプットで控除と デフォルト の両方が使用される場合、トランザクションは有効です。

Ingalaは、上記の操作の組み合わせの視覚的な例をいくつか示しています。以下は、彼の「部分的な金額の送信」の例のテキストによる説明で、 Vaultに役立つかもしれません。トランザクションには、 100 BTCのインプットが1つ（アウトプットを1つ使用）、アウトプットは2つあり、 1つは70 BTCでもう1つは30 BTCです。トランザクションの検証中にCCVが2回実行されます:
1. CCVの控除操作は、インデックス0で100 BTCを使用し、70 BTCが使用され、 30 BTCが残金になります。BIP345スタイルのVaultでは、 CCVは70 BTCを以前保護されていた同じスクリプトに戻します。
2. 2回めは、インデックス1で デフォルト を使用します。このトランザクションでは、インデックス1でアウトプットが作成されていますが、インデックス1で使用されるアウトプットはないため、暗黙的な金額0が使用されます。そのゼロに、インデックス0の控除呼び出しによる残金30 BTCが追加され、作成されるアウトプットは30 BTC以上である必要があります。BIP345スタイルのVaultでは、 CCVはアウトプットスクリプトを調整し、タイムロックの期限が切れた後に、この金額を任意のアドレスに支払ったり、いつでもユーザーのメインのVaultに戻したりできるようにします。
Ingalaが検討して却下したいくつかの代替アプローチは、彼の投稿と返信の両方で説明されています。彼は、「2つの金額動作（デフォルトと控除）は非常に人間工学的であり、実際に望ましい金額チェックの大部分をカバーしていると思います」と書いています。

また、「OP_CCVとOP_CTVを使用して、 […BIP345…]とほぼ同等のフル機能のVaultを実装しました。さらに、 OP_CCVのみを使用した機能限定バージョンが、OP_CCVのBitcoin Core実装の機能テストとして実装されています。」とも述べています。
● コンセンサスクリーンアップ用のBIPドラフトの公開: Antoine Poinsotは、コンセンサスクリーンアップソフトフォーク提案用に作成した BIPドラフトのリンクをBitcoin-Devメーリングリストに投稿しました。これには、いくつかの修正が含まれています:
- ハッシュレートの過半数がブロックを高速に生成するために使用できる2つの異なるタイムワープ攻撃の修正。
- 検証に非常に時間がかかるブロックの作成を防ぐために、レガシートランザクションに署名操作（sigops）の実行制限を設定。
- ● 重複トランザクションを完全に防止する BIP34コインベーストランザクションの一意性の修正。
- ● マークルツリーの脆弱性の一種を防止するため、将来の64 byteトランザクション（ストリップサイズを使用して計算）を無効化。
技術的な回答は、提案の2つの部分を除いてすべてに好意的でした。複数の回答で見られた最初の反対意見は、 64 byteトランザクションの無効化でした。返信では以前の批判を繰り返しました（ニュースレター #319参照）。マークルツリーの脆弱性に対処するためには代替方法もあります。この方法は、軽量（SPV）ウォレットでは比較的簡単に使用できますが、Bitcoinと他のシステム間のブリッジなど、スマートコントラクトでのSPV検証に課題が生じる可能性があります。 Sjors Provoostは、オンチェーンで強制可能なブリッジを実装する人が、 64 byteトランザクションが存在しないと仮定できることと、マークルツリーの脆弱性を防ぐために代替方法を使用しなければならないことの違いを示すコードを提供することを提案しました。

2つめの反対意見は、BIPに含まれるアイディアに対する後発の変更に関するもので、 PoinsotのDelving Bitcoinの投稿で説明されています。この変更では、コンセンサスクリーンアップの有効化後に作られたブロックに、コインベーストランザクションのロックタイムを強制可能にするフラグを設定することが求められます。以前提案されたように、有効化後のブロックのコインベーストランザクションは、ロックタイムをブロックの高さ（マイナス１）に設定します。この変更により、マイナーは有効化後のロックタイムと強制フラグの両方を使用する代替の早期Bitcoinブロックを生成できなくなります（なぜなら、そうしたとしても、遠い将来のロックタイムを使用しているため、そのコインベーストランザクションは、それを含むブロックでは有効にならないからです）。過去のコインベーストランザクションで、将来のコインベーストランザクションで使用されるものとまったく同じ値を使用できないため、重複トランザクションの脆弱性が防止されます。この提案に対する反対意見は、すべてのマイナーがロックタイム強制フラグを設定できるかどうかは明確ではないというものでした。

リリースとリリース候補

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

● BDK wallet 1.2.0は、カスタムスクリプトへの支払いの送信の柔軟性が増し、コインベーストランザクションに関連するエッジケースが修正され、その他の機能やバグ修正もいくつか含まれています。
● LDK v0.1.2は、LN対応アプリケーションを構築するこのライブラリのリリースです。いくつかのパフォーマンスの改善とバグ修正が含まれています。
● Bitcoin Core 29.0rc3は、ネットワークの主流のフルノードの次期メジャーバージョンのリリース候補です。バージョン29のテストガイドをご覧ください。
● LND 0.19.0-beta.rc1は、この人気のLNノードのリリース候補です。おそらくテストが必要な主な改善の1つは、協調クローズにおける新しいRBFベースの手数料引き上げです。

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

最近の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およびBINANAsの注目すべき変更点。

● Bitcoin Core #31363では、トランザクション間の手数料率と依存関係のみを追跡する mempoolトランザクションの軽量インメモリモデルであるTxGraphクラスを導入しました。これには、AddTransactionやRemoveTransaction、AddDependencyなどのミューテーション関数と、 GetAncestors、GetCluster、CountDistinctClustersなどの検査関数が含まれます。 TxGraphは、コミットと中止機能による変更のステージングもサポートします。これはクラスターmempoolプロジェクトの一部であり、 mempoolからの排除、再編成処理、クラスター対応のマイニングロジックの将来の改善の準備です。
● Bitcoin Core #31278では、settxfee RPCコマンドと-paytxfee起動オプションが非推奨になりました。これらを使用すると、ユーザーはすべてのトランザクションに対して静的な手数料率を設定できます。代わりに、ユーザーは手数料推定に頼るか、トランザクション毎に手数料率を設定する必要があります。これは、Bitcoin Core 31.0で削除対象としてマークされています。
● Eclair #3050は、受信者が直接接続されたノードである場合に、 BOLT12支払いの失敗を中継する方法を更新し、読み取り不可能なinvalidOnionBlindingの失敗で上書きするのではなく、常に失敗のメッセージを転送するようになりました。失敗にchannel_updateが含まれている場合、EclairはそれをTemporaryNodeFailureで上書きして、非公開チャネルの詳細が公開されないようにします。他のノードが関係するブラインドルートの場合、 Eclairは引き続き、invalidOnionBlindingで失敗を上書きします。すべての失敗のメッセージは、ウォレットのblinded_node_idを使って暗号化されます。
● Eclair #2963は、チャネルの強制閉鎖中にBitcoin Coreのsubmitpackage RPCコマンドを呼び出して、コミットメントトランザクションとそのアンカーの両方を一緒にブロードキャストすることで 1P1Cパッケージリレーを実装します。これにより、コミットメントトランザクションは、その手数料率がmempoolの最小値を下回っていても伝播できますが、 Bitcoin Core 28.0以降に接続する必要があります。この変更により、コミットメントトランザクションの手数料率を動的に設定する必要がなくなり、ノードが現在の手数料率に同意しない際に強制閉鎖がスタックしなくなります。
● Eclair #3045は、シングルパートのトランポリンペイメントの外側の Onionペイロードのpayment_secretフィールドをオプションにします。これまでは、マルチパスペイメント（MPP）が使用されていなくても、すべてのトランポリンペイメントにpayment_secretが含まれていました。 BOLT11インボイスを処理する際にペイメントシークレットが必要になる可能性があるため、 Eclairは提供されていない場合は復号時にダミーのシークレットを挿入します。
● LDK #3670は、トランポリンペイメントの処理と受け取りのサポートを追加しますが、トランポリンルーティングサービスの提供はまだ実装されていません。これはLDKが展開を予定する非同期支払いの前提条件です。
● LND #9620は、必要なパラメーターとジェネシスハッシュなどのブロックチェーン定数を追加することで、 testnet4のサポートを追加します。