今週のニュースレターでは、PoWswapプロトコルに関する論文と、 Bitcoin Core PR Review Clubミーティングの要約、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションが含まれています。 また、Bitcoin Optechの5周年と250回目のニュースレターを祝う短いセクションも含まれています。

ニュース

  • ● PoWswapプロトコルに関する論文: Thomas Hartmanは、 Jeremy Rubinが最初に提案したPoWSwapプロトコルについて、 彼がGleb NaumenkoとAntoine Riardと共に書いた論文を Bitcoin-Devメーリングリストに投稿しました。 PoWSwapは、ハッシュレートの変化に関連したオンチェーンで強制可能なコントラクトの作成を可能にします。 基本的なアイデアは、プロトコルによって強制される時間とブロック生成の関係を利用し、 時間またはブロックのいずれかでタイムロックを表現する能力を利用するものです。たとえば、 次のようなスクリプトを考えてみましょう。

    OP_IF
  <アリスの鍵> OP_CHECKSIGVERIFY <time> OP_CHECKLOCKTIMEVERIFY
OP_ELSE
  <ボブの鍵> OP_CHECKSIGVERIFY <height> OP_CHECKLOCKTIMEVERIFY
OP_ENDIF

    現在の時刻が t 、現在のブロック高が x であるとしましょう。 ブロックが平均10分間隔で生成されているとすると、<time>を t + 1000分 、 <height>を x + 50 と設定すると、ボブは上記のスクリプトで管理されているアウトプットを、 アリスがそれを使うことができるよりも平均500分早く使うことができると予想されます。 しかし、ブロックの生成速度が突然2倍以上になったら、アリスがボブより先にアウトプットを使用できる可能性があります。

    このようなタイプのコントラクトには、いくつかの応用が想定されます:

    • ● ハッシュレート上昇保険: マイナーは、どれだけの収入が得られるかはっきりしないうちに設備を購入しなければなりません。 たとえば、ネットワークの現在の総報酬の1%を受け取るのに十分な機器を購入したマイナーは、 他のマイナーもネットワークの総ハッシュレートを2倍にするだけの機器を購入したことに気づき、 結果そのマイナーは1%ではなく0.5%の報酬しか得られないかもしれません。 PoWSwapを使うと、マイナーは、ある日までにハッシュレートが増加した場合にマイナーに支払いをする相手と トラストレスなコントラクトを作成することができ、マイナーの予想外の低収入を相殺することができます。 その代わり、マイナーは前払いのプレミアムを支払うか、ネットワーク全体のハッシュレートが同じか減少した場合に、 より多くの金額を支払うことに同意します。

    • ● ハッシュレート低下保険: Bitcoinのさまざまな問題により、ネットワーク全体のハッシュレートが大幅に低下する可能性があります。 マイナーが権力者によって閉鎖させられたり、 既存のマイナー間で大量のフィー・スナイピングが突然発生したり、 マイナーにとってのBTCの価値が突然低下したりすると、ハッシュレートは低下します。 このような事態に備えたいBTC保有者は、マイナーや第三者とトラストレスなコントラクトを作ることができます。

    • ● 為替レートコントラクト: 一般的に、BTCの購買力が上がれば、マイナーは（受け取る報酬を増やすために）提供するハッシュレートの量を増やしたいと考えます。 購買力が低下すると、ハッシュレートも低下します。多くの人が、 Bitcoinの将来の購買力に関連するトラストレスなコントラクトに興味を持つかもしれません。

    PoWSwapのアイディアは数年前から広まっていますが、この論文では、 これまでに見たことのないより詳細な分析が提供されています。

リリースとリリース候補

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

Bitcoin Core PR Review Club

この毎月のセクションでは、最近のBitcoin Core PR Review Clubミーティングを要約し、 重要な質問と回答のいくつかに焦点を当てます。 以下の質問をクリックしてミーティングでの回答の要約を確認してください。

Add getprioritisationmap, delete a mapDeltas entry when delta==0は、 Gloria Zhao (glozow)によるPRで、Bitcoin Coreの機能を改善し、 マイナーが有効なmempool手数料を変更できるようにし、 特定のトランザクションのマイニング優先度（高いか低いか）を変更できるようにします（prioritisetransaction RPC参照）。 手数料の増加（正の場合）または減少（負の場合）は、 手数料デルタ と呼ばれます。 トランザクションの優先順位付けの値は、mempool.datファイル内のディスクに永続化され、ノードの再起動時に復元されます。

マイナーがトランザクションの優先順位付けをする理由の１つは、 帯域外のトランザクション手数料の支払いを考慮するためです。 マイナーのブロックテンプレートに含めるトランザクションを選択する際に、 影響を受けるトランザクションは、より高い手数料を持つものとして扱われます。

このPRでは、優先順位付けされたトランザクションのセットを返す新しいRPC、getprioritisationmapを追加しています。 また、ユーザーがデルタをゼロに戻した場合に発生する可能性のある、不要な優先順位付けエントリを削除します。

  • mapDeltasデータ構造とは何ですか？どうして必要なのですか？

    トランザクション毎の優先順付けされた値が格納されます。 これらの値は、ローカルのマイニングと排除の決定および、祖先と子孫の手数料率の計算に影響します。 ➚

  • トランザクションの優先順位付けは手数料推定アルゴリズムに影響しますか？

    いいえ。手数料の推定は、マイナー（この場合、 他の マイナー）の予想される決定を正確に予測する必要があり、 これらのマイナーは、私達と同じ優先順位を持っていません。優先順位はローカルのものなので。 ➚

  • mapDeltasへのエントリーはどのように追加されますか？ また、いつ削除されるのですか？

    prioritisetransaction RPCによって追加され、またノードの再起動時には、mempool.dat内のエントリーに起因します。 トランザクションを含むブロックがチェーンに追加された時や、トランザクションが置換された際に削除されます。 ➚

  • トランザクションがmempoolから出る際に（たとえば、期限切れや手数料率が最小手数料率を下回って排除された場合など）、 そのエントリーをmapDeltasから削除すべきでないのは何故ですか？

    トランザクションは再びmempoolに戻ってくるかもしれません。 mapDeltasのエントリーが削除された場合、ユーザーはトランザクションの優先順位付けを再度行う必要があります。 ➚

  • トランザクションがブロックに含まれたためmapDeltasから削除され、その後ブロックが再編成された場合、 そのトランザクションの優先順位は再設定されなければならないのではないでしょうか？

    はい。しかし再編成は稀であると予想されます。また、帯域外の支払いは実際にはBitcoinトランザクションの形である可能性があるため、 そちらもやり直しが必要な場合があります。 ➚

  • なぜ、mempoolに存在しないトランザクションを優先的に処理できるようにしなければならないのでしょう？

    そのトランザクションがまだmempoolに存在しないかもしれないからです。 そして、そもそもそのトランザクションは（優先順位付けしなければ）自身の手数料でmempoolに入ることさえできないかもしれません。 ➚

  • mapDeltasをクリーンアップしない場合、どのような問題が起きますか？

    主な問題は、無駄なメモリ割り当てです。 ➚

  • mempool.dat（mapDeltasを含む）は、 いつメモリからディスクに書き込まれますか？

    クリーンシャットダウン時かsavemempoolを実行した際です。 ➚

  • このPRがない場合、 マイナーはどうやってmapDeltasをクリーンアップするのでしょうか（つまり、優先順位がゼロのエントリーを削除するのでしょうか）？

    唯一の方法はノードを再起動することです。ゼロ値の優先順位付けは、再起動中にmapDeltasにロードされないからです。 PRでは、値がゼロに設定されるとすぐにmapDeltasのエントリーが削除されます。 これには、ゼロ値の優先順位付けがディスクに書き込まれないという利点もあります。 ➚

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

今週の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 #26094では、getbalancesとgettransaction、getwalletinfoに ブロックハッシュと高さのフィールドを追加しました。これらのRPC呼び出しは、 最新のブロックであることを確認するためchainstateをロックするので、 有効なブロックハッシュと高さをレスポンスに含めるのは有益です。

  • ● Bitcoin Core #27195では、Bitcoin Coreの内部ウォレットから bumpfeeRPCを使用して置き換えられるトランザクションからすべての外部受信者を削除できるようになりました。 ユーザーは、置換トランザクションの唯一のアウトプットをユーザー自身のアドレスに支払うようにすることでこれを行います。 置換トランザクションが承認されると、元の受信者のいずれにも支払いが行われなくなるため、 Bitcoin支払いを「キャンセルする」と表現されることがあります。

  • ● Eclair #1783は、1つ以上のトランザクションをCPFPにより手数料を引き上げるための cpfpbumpfees APIを追加しました。このPRはまた、手数料引き上げのトランザクションの作成が実行可能であることを保証するために、 Bitcoin Coreを実行するための推奨パラメーターのリストを更新しています。

  • ● LND #7568は、ノードの起動時に追加のLN機能ビットを定義する機能を追加しました。 また、実行中にハードコードまたは定義された機能ビットを無効にする機能も削除しました（ただし、 追加ビットは追加した後で無効にできます）。BLIPs #24の関連する提案の更新では、 カスタムBOLT11機能ビットの最大値が5114に制限されることが指摘されています。

  • ● LDK #2044は、BOLT11インボイスに対するLDKのルートヒントにいくつかの変更を加えています。 ルートヒントは、受信側のLNノードが送信側のノードが使用するルートを提案するために使用できる仕組みです。 このマージにより、提案されるのは3つのチャネルのみとなり、 LDKのファントムノードのサポートが改善され（ニュースレター #188参照）、 選択された3つのチャネルは効率とプライバシーを考慮して選択されます。 PRの議論では、ルートヒントの提供がプライバシーに与える影響について、 いくつかの示唆に富んだコメントが含まれています。

祝・Optech Newsletter #250

Bitcoin Optechは、「企業とオープンソースコミュニティの連携を促進する」ことを目的として設立されました。 この週刊ニュースレターは、Bitcoinを使用する企業の幹部や開発者に、 オープンソースコミュニティが構築しているものについてより深く理解してもらうことを目的として開始されました。 そのため、当初は事業に影響を与える可能性のある作業を文書化することに重点を置きました。

しかし、この情報に興味を持つのは、企業の読者だけではないことがすぐにわかりました。 Bitcoinプロジェクトの多くのコントリビューターは、プロトコル開発のメーリングリストの議論をすべて読んだり、 他のプロジェクトの大きな変更を監視したりする時間がなかったのです。 そんな彼らにとって、自分たちが興味を持ちそうな、あるいは自分たちの仕事に影響を与えそうな開発について、 誰かが知らせてくれることはありがたいことでした。

この5年近く、そのようなサービスを提供することができたのが、私たちの喜びです。 私たちは、このシンプルなミッションをさらに発展させるべく、 ウォレット技術の互換性ガイドや、 100以上の興味深いトピックのインデックス、 そして私たちに記事を書く機会を与えてくれた多くのコントリビューターをゲストに迎えた 週刊のディスカッションポッドキャストを提供することにしています。

これらはすべて、過去1年間で以下のような多くの貢献者の存在なくしては実現できませんでした: Adam Jonas、 Copinmalin、 David A. Harding、 Gloria Zhao、 Jiri Jakes、 Jon Atack、 Larry Ruane、 Mark “Murch” Erhardt、 Mike Schmidt、 nechteme、 Patrick Schwegler、 Shashwat Vangani、 Shigeyuki Azuchi、 Vojtěch Strnad、 Zhiwei “Jeffrey” Hu、 そして特定のテーマで特別寄稿してくれた他の多くの方々。

また、創立スポンサーであるWences Casares、John Pfeffer、Alex Morcos、 そして多くの資金援助者の方々にも感謝しています。

お読みいただきありがとうございます。今後発行する次の250号も、引き続きお読みいただければ幸いです。