今週のニュースレターでは、Bitcoinおよび関連プロトコルのためのゼロ知識Validity Proofに関する研究を掲載しています。 また、mempoolポリシーに関する限定週刊シリーズの新しい記事や、 クライアントとサービスのアップデート、新しいリリースとリリース候補、 人気のあるBitcoinインフラストラクチャプロジェクトの変更など、恒例のセクションも含まれています。

ニュース

  • ● ゼロ知識Validity Proofによる状態の圧縮: Robin Linusは、 システムにおける将来の操作をトラストレスに検証するためにクライアントがダウンロードする必要のある状態の量を削減するために Validity Proofを使用することについて、Lukas Georgeと共著の論文を Bitcoin-Devメーリングリストに投稿しました。 彼らはまず、彼らのシステムにBitcoinを適用しました。 ブロックヘッダーのチェーンにおけるProof of Workの累積量を証明し、 特定のブロックヘッダーがそのチェーンの一部であることをクライアントが検証できるプロトタイプができたことを報告しています。 これにより、複数のプルーフを受け取ったクライアントは、どのProof of Workが最も作業量が多いかを判断できるようになります。

    また、ブロックチェーンのすべてのトランザクションの状態変化が通貨のルール（ たとえば、新しいブロックによって作成されるビットコインの量、 非コインベースの各トランザクションが破棄（使用）したビットコインよりも多くの量を持つUTXOを作成してはならないこと、 マイナーはブロックで破棄されたUTXOと作成されたUTXOの差額を請求できることなど）を遵守していることを証明する次善のプロトタイプもあります。 このプルーフと現在のUTXOセットのコピーを受け取ったクライアントは、 そのセットが正確かつ安全であることを検証することができます。 多くのコントリビューターが自身のノードでこれらのブロックをすべて正常に検証したことに同意した場合に、 古いブロックのスクリプトの検証をオプションでスキップするBitcoin Coreの機能にちなんで、 彼らはこれを assumevalid プルーフと呼んでいます。

    プルーフの複雑さを最小限にするため、彼らは、 彼らのシステムに最適化されたハッシュ関数を使用したバージョンのUtreexoを使用しています。 また、このプルーフとUtreexoクライントを組み合わせることで、 非常に少量のデータをダウンロードした後、そのクライアントがすぐにフルノードとして動作し始めることができるようになると述べています。

    プロトタイプの有用性に関しては、 「ヘッダーチェーンのプルーフとassumevalidステートプルーフをプロトタイプとして実装しています。 前者は証明可能ですが、後者は妥当なサイズのブロックを証明するためにはまだ性能改善が必要です。」と書かれています。 また、スクリプトを含む完全なブロックの検証にも取り組んでいますが、 その実現には少なくとも40倍の速度向上が必要だと述べています。

    Bitcoinブロックチェーンの状態の圧縮に加えて、彼らは、LLのTaproot AssetsやRGBの一部の使用法（ ニュースレター#195および#247参照）と同様の、 Client-Side-Validation型のトークンプロトコルに使用できるプロトコルについても説明しています。 アリスがボブにトークンの一部を転送する場合、ボブは、そららのトークンが作成された時点までのすべての転送履歴を検証する必要があります。 理想的なシナリオにおいて、その履歴は転送回数とともに線形に増加します。 しかし、ボブがアリスから受け取ったトークンよりも多い量をキャロルに支払いたい場合は、 アリスから受け取ったトークンの一部と、別のトランザクションで受け取ったトークンの一部を組み合わせる必要があります。 そしてキャロルは、アリスを経由した履歴と、ボブの別のトークン履歴の両方を検証する必要があります。 これはマージと呼ばれます。マージが頻繁に起きると、検証する必要のある履歴のサイズは、 そのトークンのユーザー間のすべての転送履歴のサイズに近づきます。 Bitcoinではすべてのフルノードがすべてのユーザーのトランザクションを検証しています。 これと比較すると、Client-Side-Validationを使用するトークンプロトコルでは、 同様の検証は厳密には必要ではありませんが、マージが頻繁に起こると、最終的に事実上同様の検証が必要になります。

    つまり、Bitcoinの状態を圧縮できるプロトコルは、マージが頻繁に起きる場合でも、 トークンの履歴の状態を圧縮するのに適応できるということです。 著者らは、それを実現する方法について説明しています。 彼らの目標は、トークンの以前の転送が、そのトークンのルールに従っていることの証明を生成することです。 これには、以前の各転送がブロックチェーンにアンカリングされていることを証明するために、Bitcoinに対するプルーフを使用することも含まれています。 アリスは、トークンをボブに転送し、一定サイズの短い有効性のプルーフを渡すことができます。 ボブはプルーフを検証し、転送が特定のブロック高で行われ、彼のトークンウォレットに支払われ、 自分がそのトークンを独占的に制御していることを知ることができます。

    この論文では、追加で実施可能な研究開発について頻繁に言及していますが、 私達はこれをBitcoinの開発者が10年以上にわたって望んでいた機能に向けた心強い進歩であると感じています。

承認を待つ #2: インセンティブ

トランザクションリレーや、mempoolへの受け入れ、マイニングトランザクションの選択に関する限定週刊シリーズです。 Bitcoin Coreがコンセンサスで認められているよりも制限的なポリシーを持っている理由や、 ウォレットがそのポリシーを最も効果的に使用する方法などが含まれます。

先週の記事では、mempoolについて、未承認トランザクションのキャッシュとして、 ユーザーがトランザクションをマイナーに送信するための分散化された方法を提供するものであると説明しました。 しかし、マイナーはそのトランザクションを承認する義務はなく、 コインベーストランザクションだけを含むブロックはコンセンサスルールにおいて有効です。 ユーザーは、トランザクションの総アウトプット額を変更せずに、総インプット額を増やすことで、 マイナーに自分のトランザクションを承認するインセンティブを与え、 マイナーはその差額をトランザクション 手数料 として請求することができます。

トランザクション手数料は、従来の金融システムでは一般的ですが、 新規のBitcoinユーザーは、オンチェーン手数料が取引額に比例するのではなく、 トランザクションのweightによって支払われることに驚くことがよくあります。 流動性ではなくブロックスペースが制限要因になります。 手数料率 は通常、仮想バイト（virtual byte）あたりのsatoshiで表されます。

コンセンサスルールにより、各ブロックでトランザクションが使用するスペースが制限されています。 この制限により、ブロックの伝播時間がブロック間隔に対して低く保たれ、 ブロックが古くなってしまう（ステイルブロック）リスクが軽減されます。 また、ブロックチェーンとUTXOセットの増加を抑制することができ、 これらはフルノードの立ち上げと維持にかかるコストに直接貢献します。

このように、未承認トランザクションのキャッシュとしての役割の他に、 mempoolはブロックスペースの公開オークションを促進します。 正常に機能している場合、オークションは自由市場の原則に従います。 つまり、優先順位はマイナーとの関係でははなく、純粋に手数料に基づきます。

ブロックのトランザクションを選択する際に手数料を最大化することは（総weightと署名操作の数の制限あり）、 NP困難な問題です。 この問題は、トランザクションの関係性によってさらに複雑になります。 高手数料率のトランザクションをマイニングするには、その低手数料率の親をマイニングする必要があるかもしれません。 別の言い方をすると、低手数料率のトランザクションをマイニングすることで、 高手数料率のその子をマイニングする機会が生まれるかもしれません。

Bitcoin Coreのmempoolは、各エントリとその祖先の手数料率を計算し（祖先手数料率 と呼ばれる）、 その結果をキャッシュし、貪欲ブロックテンプレート構築アルゴリズムを使用します。 mempoolを 祖先スコア （祖先手数料率と個別手数料率の最小値）順にソートし、 その順番で祖先パッケージを選択し、残りのトランザクションの祖先手数料とweight情報を随時更新していきます。 このアルゴリズムは、性能と収益性のバランスを取るものであり、必ずしも最適な結果が得られるとは限りません。 その有効性は、トランザクションと祖先パッケージのサイズを制限することで向上させることができます。 Bitcoin Coreでは、その制限がそれぞれ400,000 weightと404,000 weightに設定されています。

同様に、高手数料率の子を持つ低手数料率のトランザクションを退去させるのは不利になるため、 mempoolから退去させるパッケージを選択する際に使用される 子孫スコア が計算されます。

mempoolの検証では、同じインプットを使用するトランザクション（つまり二重支払いや、競合するトランザクション）を処理する際も、 手数料と手数料率が使用されます。ノードは最初に確認したトランザクションを常に保持するのではなく、 一連のルールを使用して、どのトランザクションを保持するインセンティブがより高いかを決定します。 この動作はReplace by Feeとして知られています。

マイナーが手数料を最大化するのは直感的に理解できますが、 なぜマイニングを行わないノードのオペレーターがこのようなポリシーを実行しなければならないのでしょうか？ 先週の記事で説明したように、マイニングを行わないノードのmempoolの効用は、 マイナーのmempoolとの類似性に直接関係しています。 そのため、ノードオペレーターがmempoolの内容を使ってブロックを生成するつもりがなくても、 最もインセンティブに適合したトランザクションを維持することに関心があります。

トランザクションに手数料の支払いを要求するコンセンサスルールはありませんが、 手数料と手数料率は、ブロックスペースをめぐる競争を解決するための「公平な」方法として、 Bitcoinネットワークで重要な役割を果たしています。 マイナーは手数料率を使用して、受け入れ、退去および競合を評価し、 マイニングを行わないノードは、自分のmempoolの効用を最大化するためにその動作を反映します。

ブロックスペースの希少性は、トランザクションのサイズに低下圧力をかけ、 開発者がトランザクションをより効率的に構築するよう促します。 来週の記事では、オンチェーントランザクションの手数料を最小化するための実践的な戦略と技術を探ります。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● Passportファームウェア 2.1.1 リリース: ハードウェア署名デバイスPassportの最新のファームウェアは、 Taprootアドレスへの送金、BIP85機能のサポートに加え、 PSBTの処理やマルチシグ構成の改善をしています。

  • ● MuSigウォレットMunstrリリース: MuSigマルチシグトランザクションの署名に必要なラウンド通信を簡単にするために Nostrプロトコルを使用するMunstrソフトウェアのベータ版です。

  • ● CLNのプラグインマネージャーCoffeeリリース: Coffeeは、CLNプラグインのインストール、 設定、依存関係の管理およびアップグレードの側面を改善するCLNプラグインマネージャーです。

  • ● Electrum 4.4.3 リリース: Electrumの最新バージョンには、 コインコントロールの改善や、UTXOのプライバシー分析ツール、SCID（Short Channel Identifier）のサポートや、 他の修正、改善が含まれています。

  • ● Trezor SuiteがCoinjoinをサポート: Trezor Suiteソフトウェアは、CoinjoinコーディネーターzkSNACKsを使用するCoinjoinのサポートを発表しました。

  • ● Lightning LoopのデフォルトがMuSig2に: Lightning Loopは、スワッププロトコルのデフォルトとしてMuSig2を使用するようになり、 手数料の低減とプライバシーの向上を実現します。

  • ● Mutinynetがテスト用に新しいsignetを発表: Mutinynetは、ブロックタイムが30秒のカスタムsignetで、 ブロックエクスプローラやFaucet、 ネットワーク上で動作するテストLNノードやLSPを含むテストインフラを提供します。

  • ● NunchukがコインコントロールとBIP329のサポートを追加: NunchukのAndroidおよびiOSの最新バージョンでは、コインコントロールと BIP329ウォレットラベルエクスポート機能が追加されています。

  • ● MyCitadel Walletがminiscriptのサポートを強化: v1.3.0リリースでは、 タイムロックを含むより複雑なminiscript機能が追加されています。

  • ● Coldcard用のEdge Firmwareの発表: Coinkiteは、Coldcardハードウェアサイナー用の実験的なファームウェアを発表しました。 このファームウェアは、ウォレット開発者やパワーユーザーが新しい機能を試すために設計されています。 初期の6.0.0Xリリースには、Taprootのkeypath支払いと、Tapscriptのマルチシグ支払い、 BIP129のサポートが含まれています。

リリースとリリース候補

人気の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 #27021では、アウトプットの未承認の祖先トランザクションを特定の手数料率まで引き上げるのに どれだけのコストがかかるか計算するインターフェースが追加されました。 コイン選択が特定の手数料率で特定のアウトプットの使用を検討している場合、 その手数料率における祖先の手数料不足が計算され、その結果が有効値から差し引かれます。 これにより、他の使用可能なアウトプットがある場合に、 ウォレットが新しいトランザクションに対して手数料不足のアウトプットを選択するのを抑制することができます。 後続のPRでは、このインターフェースは いずれにせよ不足のあるアウトプットを選択する必要がある場合に、 ウォレットが余分な手数料（ 手数料引き上げ と呼ばれる）を支払うことを可能にするためにも使用され、 新しいトランザクションがユーザーが要求した実効手数料率を支払うことを保証します。

    このアルゴリズムは、未承認UTXOの関連する未承認トランザクションのクラスター全体を評価し、 ターゲットの手数料率でブロックに選択されたであろうトランザクションを剪定することで、 任意の祖先の一群に対して手数料の引き上げを評価することができます。 2つめの方法は、複数の未承認アウトプットにまたがる手数料の引き上げを集約して、 潜在的な祖先の重複を補正することができます。

  • ● LND #7668は、チャネルを開設する際に、最大500文字までのプライベートテキストを関連付ける機能を追加し、 オペレーターが後でその情報を取得できるようにします。これにより、 特定のチャネルを開いた理由を思い出すのに役立ちます。

  • ● LDK #2204は、ピアに通知するため、またはピアのアナウンスを解析する際に使用するための、 カスタム機能ビットを設定する機能を追加しています。

  • ● LDK #1841は、以前LN仕様に追加されたセキュリティ勧告（ニュースレター #128参照）を実装しています。 アンカー・アウトプットを使用するノードは、トランザクションを迅速に承認する必要がある場合、 複数の当事者が管理するインプットを一緒にバッチ処理しようとしてはなりません。 この実装により、他の当事者が承認を遅らせることができなくなります。

  • ● BIPs #1412は、ウォレットラベルエクスポート用のBIP329を更新し、 鍵のオリジン情報を格納するフィールドを追加しました。 さらに、仕様ではラベルの長さの制限を255文字にすることが提案されています。