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

Bitcoin Optech Newsletter #254

Jun 7, 2023

今週のニュースレターでは、MATT提案を使用してJoinpoolを管理し、 OP_CHECKTEMPLATEVERIFY提案の機能を再現することに関するメーリングリストでの議論を掲載しています。また、mempoolポリシーに関する限定週刊シリーズの新しい記事に加えて、新しいソフトウェアリリースとリリース候補の発表、人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

● CTVの再現とJoinpoolの管理にMATTを使用する: Johan Torås Halsethは、 MATT(Merklize All The Things)の提案（ニュースレター#226と#249を参照）の OP_CHECKOUTPUTCONTRACTVERIFY opcode（COCV）を使用して OP_CHECKTEMPLATEVERIFYの提案機能を再現することについて Bitcoin-Devメーリングリストに投稿しました。複数のアウトプットを持つトランザクションにコミットする場合、各アウトプットは異なるCOCV opcodeを使用する必要があります。それに比べて、単一のCTV opcodeはすべてのアウトプットにコミットすることができます。そのため、COCVの効率は低下しますが、彼が指摘するように「十分にシンプルで面白い」。

Halsethは、機能の説明だけではなく、Tapsimを使った動作のデモも提供しています。このツールは、「Bitcoinスクリプトのプリミティブを操作し、スクリプトのデバッグを支援し、スクリプト実行時のVMの状態を視覚化することを目的したBitcoin Tapscriptトランザクションのデバッグツール」です。

別のスレッドで、HalsethはMATTとOP_CATを使用してJoinpool （Coinpool や a Payment pool とも呼ばれる）を作成することについても投稿しました。ここでも、Tapsimを使ったインタラクティブなデモが提供されています。また、実験的な実装の結果に基づき、MATTの提案に含まれるopcodeの修正案をいくつか提示しています。 MATTの提案者であるSalvatore Ingalaは、好意的に答えています。

承認を待つ #4: 手数料率の推定

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

先週は、手数料率を考慮したトランザクションで支払われる手数料を最小限に抑えるための手法を紹介しました。しかし、その手数料率はどうあるべきなのでしょうか？理想的には、お金を節約するためにできるだけ低く、ユーザーの時間的な優先順位に応じたブロックのスポットを確保するのに十分な額であることです。

手数料（率）推定 の目標は、承認のための目標時間枠を、トランザクションが支払うべき最小手数料率に変換することです。

手数料の推定を複雑にする１つは、ブロックスペースの生産が不規則であることです。たとえば、ユーザーが１時間以内に販売者に支払いを行う必要があるとします。この場合、ユーザーは10分毎にブロックがマイニングされることを期待しているため、次の6ブロック以内のスポットを狙うでしょう。しかし、1つのブロックがマイニングされるのに 45分かかることも十分あり得ます。手数料の推定では、ユーザーが希望する緊急性や時間枠（「仕事終わりまでに承認してほしい」など）と、ブロックスペースの供給量（ブロック数）を調整する必要があります。多くの手数料推定は、時間に加えてブロック数で承認目標を表すことで、この課題に対処しています。

承認前ののトランザクションに関する情報がない場合は、どのような手数料率のトランザクションがブロックに入る傾向があるかについて過去のデータを使用する単純な手数料推定を構築できます。この推定ツールは、mempoolで承認を待っているトランザクションを認識しないため、ブロックスペース需要の予期せぬ変動や、時折発生する長めのブロック間隔に対して非常に不正確になります。もう１つの弱点は、マイナーが完全に管理する情報に依存していることです。マイナーは、ブロックに偽の高手数料率のトランザクションを含めることで、手数料率を上げることができます。

幸いなことに、ブロックスペースの市場はブラインドオークションではありません。最初の記事で、mempoolを保持し、ピアーツーピアのトランザクションリレーネットワークに参加することで、ノードがユーザーの入札を確認することができることを紹介しました。 Bitcoin Coreの手数料推定ツールも、履歴データを使用して、 nブロック以内に手数料率fでトランザクションが承認される確率を計算しますが、特にノードが最初にトランザクションを発見した高さと承認された高さを追跡します。この方法は、公開手数料市場の外で発生する活動を無視することで機能します。マイナーが人為的に高い手数料率のトランザクションを自分のブロックに含めても、承認される前に公にリレーされたトランザクションのデータのみを使用するため、この手数料推定ツールが歪められることはありません。

また、トランザクションがブロックに選択される方法についての洞察もあります。以前の記事で、ノードはインセンティブに適合するトランザクションを自分のmempoolに保持するために、マイナーのポリシーをエミュレートすることを紹介しました。このアイディアを発展させると、過去のデータだけを見るのではなく、マイナーが行うであることをシミュレートする手数料推定ツールを構築することができます。次のnブロック以内にトランザクションを承認するために必要な手数料率を見つけるために、手数料推定ツールは、ブロック構築アルゴリズムを使用して、 mempoolから次のn個のブロックテンプレートを予測し、ブロックnに入る最後のトランザクションに勝つ手数料率を計算することができます。

明らかに、この手数料推定ツールのアプローチの有効性は、自分のmempoolのコンテンツとマイナーのコンテンツの類似性に依存し、これは決して保証されるものではありません。また、承認のために帯域外で手数料を支払うトランザクションなど、マイナーが外的な動機によって含める可能性のあるトランザクションも認識できません。また予測では、現時点から予測されたブロックが見つかるまでの間にブロードキャストされた追加のトランザクションも考慮する必要があります。他のトランザクションを考慮し、予測されるブロックのサイズを減らすことでこれを実現できますが、どれくらいでしょうか？

この質問は、履歴データの有用性を再び浮き彫りにします。高度なモデルであれば、活動のパターンを組み込んで、典型的な営業時間や、企業でスケージュールされたUTXOの統合、Bitcoinの取引価格の変化に応じた活動など、手数料率に影響を与える外部イベントを考慮することができるかもしれません。ブロックスペースの需要予測という問題は、まだ探求の余地があり、常にイノベーションの余地があると思われます。

手数料推定は多面的で難しい問題です。悪い手数料推定は、手数料を過剰に支払うことで資金を浪費し、支払いにBitcoinを使用することに摩擦をもたらし、別の使用条件を持つタイムロックされたUTXOがある期間を逃すことでL2ユーザーが損失を被る可能性があります。良い手数料推定は、ユーザーがマイナーにトランザクションの緊急度を明確かつ正確に伝えることを可能にし、 CPFPやRBFにより、初期の見積もりが甘かった場合に入札の更新を可能にします。インセンティブに適合するmempoolポリシーと、よく設計された手数料推定ツールとウォレットを組み合わせることで、ユーザーはブロックスペースの効率的な公開オークションに参加することができます。

手数料推定ツールは、時間軸がどれくらい長くても、承認待ちのトランザクションがどれくらい少なくても、通常1sat/vBを下回る値を返すことはありません。多くの人が1sat/vBをBitcoinネットワークの事実上の下限手数料率と考えています。これは、（マイナーを含む）ネットワーク上のほとんどのノードが、 mempoolがどれだけ空いていても、この手数料率以下のものを決して受け入れないという事実があるためです。来週の記事では、このノードポリシーと、トランザクションリレーで手数料率を利用するもう1つの動機であるリソースの枯渇からの保護について説明する予定です。

リリースとリリース候補

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

● LND 0.16.3-betaは、この人気のLNノード実装のメンテナンスリリースです。リリースノートには、「このリリースには、バグ修正のみが含まれており、最近追加されたmempoolの監視ロジックを最適化し、不注意による強制クローズの疑いがあるいくつかの要因を修正することを目的としています」と記載されています。 mempool監視ロジックの詳細については、ニュースレター #248をご覧ください。

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

今週の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 #26485では、optionsオブジェクトパラメーターを受け入れるRPCメソッドが、名前付きパラメーターと同じフィールドを受け入れられるようになりました。たとえば、bumpfee RPCは、src/bitcoin-cli -named bumpfee txid options='{"fee_rate": 10}'の代わりに、 src/bitcoin-cli -named bumpfee txid fee_rate=10と呼び出すことができます。
● Eclair #2642は、ノードの閉鎖されたチャネルに関するデータを提供するclosedchannels RPCを追加しました。ニュースレター #245で紹介した Core Lightningの同様のPRもご覧ください。
● LND #7645は、OpenChannel、CloseChannel、SendCoins、SendManyのRPC呼び出しにおいて、ユーザーが提供する手数料率が「リレー手数料率」を下回らないようにしました。この変更には、「手数料率はバックエンドによって若干異なる意味があります。 bitcoindの場合、それは実質的にmax(リレー手数料、mempoolの最小手数料)になります。」と記載されています。
● LND #7726は、チャネルをオンチェーンで決済する必要がある場合、常にローカルノードに支払うすべてのHTLCを使用するようになりました。たとえ、それらを回収するのに、その金額以上にトランザクション手数料がかかるとしても、そのHTLCを回収しようとします。先週のニュースレターで紹介したEclairのPRと比較すると、 Eclairの方は経済的に見合わないHTLCを回収しようとはしません。 PRのスレッドのコメントでは、 LNDは（オフチェーンとオンチェーンの両方で）HTLCの決済に関連するコストと利益を計算する機能を強化する他の変更に取り組んでおり、将来的には最適な意思決定を行うことができるようになると記載されています。
● LDK #2293は、ピアから適切な時間内に応答がない場合、いったん切断してから再接続するようになりました。これは、他のLNソフトウェアが時々応答を停止し、チャネルが強制的に閉じられることがある問題を軽減する可能性があります。