今週のニュースレターでは、新しいマネージドJoinpoolプロトコルの提案と、 Nostrプロトコルを使用したトランザクションリレーのアイディアを掲載しています。 また、mempoolポリシーに関する限定週刊シリーズの新しい記事に加えて、 Bitcoin Stack Exchangeに投稿された注目すべき質問とその回答や、 新しいソフトウェアリリースとリリース候補のリスト、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● マネージドJoinpoolプロトコルの提案: 今週、Burak Keceliが、 Bitcoin-Devメーリングリストに Ark という新しいJoinpool形式のプロトコルのアイディアを投稿しました。 このプロトコルでは、ビットコインの所有者が、 一定期間内のすべての取引においてカウンターパーティを共同署名者として使用することを選択できます。 所有者は、タイムロックの有効期限が切れた後に、オンチェーンでビットコインを一方的に引き出すか、 タムロックの期限が切れる前にカウンターパーティに即座にトラストレスにオフチェーンで転送することができます。

    他のBitcoinユーザーと同様に、カウンターパーティはいつでも自身の資金のみを使用するオンチェーントランザクションを ブロードキャストすることができます。そのトランザクションのアウトプットが、 所有者からカカウンターパーティに資金を転送するオフチェーントランザクションのインプットとして使用された場合、 オンチェーントランザクションが適切な時間内に承認されない限り、オフチェーン転送が無効になります。 この場合、カウンターパーティは、署名されたオフチェーントランザクションを受け取るまで、 オンチェーントランザクションに署名しません。これにより、 トラストレスなシングルホップ、所有者からカウンターパーティへの単一方向のアトミックな転送プロトコルが提供されます。 Keceliは、このアトミックな転送プロトコルの3つの用途について説明しています:

    • ● コインのミキシング: Joinpool内の複数のユーザーは、 カウンターパーティの協力の下、現在のオフチェーンの金額と同等の新しいオフチェーンの金額との間で アトミックスワップを行うことができます。オンチェーンコンポーネントに障害が発生すると、 スワップが単に巻き戻され、すべての資金が元の状態に戻るだけなので、これは迅速に実行できます。 一部の既存のCoinjoin実装で使用されているものと同様のブラインドプロトコルを使用することで、 どのユーザーがどのビットコインを手に入れたかをユーザーやカウンターパーティが特定することを防ぐことができます。

    • ● 内部送金: あるユーザーは、 オフチェーンの資金を同じカウンターパーティの別のユーザーに送金することができます。 アトミック性により、受取人が資金を受け取るか、支払人が払い戻しを受け取ることが保証されます。 受取人が支払人とカウンターパーティの両方を信頼していない場合、通常のオンチェーントランザクションと同じくらいの承認を待つ必要があります。

      Keceliとコメンテーターは、二重使用トランザクションの両方のバージョンを観察したマイナーが コインを請求することができるFidelity bondとゼロ承認の支払いを組み合わせることで、 二重使用を経済的に不利にすることができることを説明した以前の研究のリンクを掲載しています。 これにより、受取人は、他の参加者を信頼していなくていも、支払いを数秒以内に受け入れることができます。

    • ● LNインボイスの支払い: カウンターパーティがシークレットを知っている場合、 ユーザーはオフチェーン資金をカウンターパーティに支払うことを即座にコミットすることができ、 カウンターパーティを通じてLNスタイルのHTLCインボイスに支払うことができます。

      内部送金の問題と同様に、ユーザーはトラストレスに資金を受け取ることはできないため、 支払いが十分な数の承認を受けるか、説得力のあるFidelity bondで担保されるまで、 シークレットを明らかにすべきではありません。

    Keceliは、基本プロトコルは、Joinpoolのメンバー間の頻繁なやりとりを利用して、 現在のBitcoinに実装することができると述べています。 OP_CHECKTEMPLATEVERIFYや、 SIGHASH_ANYPREVOUT、 OP_CAT + OP_CHECKSIGFROMSTACKなどのCovenantの提案が実装されれば、 Joinpoolのメンバーは、Coinjoinに参加したり、支払いをしたり、 オフチェーン資金のタイムクロックを更新する際にのみカウンターパーティとやりとりする必要があります。

    Coinjoin、支払い、更新のいずれにおいても、オンチェーントランザクション内でコミットメントを公開する必要がありますが、 基本的に無制限の数の操作をすべて同じ小さなトランザクションにまとめることができます。 操作を素早く完了させるために、Keceliは、ユーザーがそれ以上待つ必要がないように、 約5秒毎にオンチェーントランザクションを作ることを提案しています。 各トランザクションは別個のもので、Replace-by-Feeを利用して 複数のトランザクションのコミットメントを結合するようなことは、 コミットメントを破壊したり、以前のラウンドに参加したすべてのユーザーの参加を必要としない限り不可能であるため、 個々のトランザクションは小さいものの、1つのカウンターパーティにつき年間630万件以上のトランザクションを承認しなければならない必要があります。

    メーリングリストに投稿されたプロトコルに関するコメントは以下のとおりです:

    • ● さらにドキュメントを求める声: 少なくとも2人の回答者が、 メーリングリストに提供されたハイレベルな説明では分析が難しいとして、 システムの仕組みに関する追加のドキュメントを求めました。 Keceliはその後、仕様のドラフトを公開し始めています。

    • ● LNと比べて受け取りが遅いという懸念: 何人かのメンバーは、 初期設計では、十分な数の承認を待たずにJoinpoolから（オフチェーンでもオンチェーンでも） 支払いをトラストレスに受け取ることはできないと指摘しました。 これには数時間かかる可能性があり、一方、多くのLNの支払いは現在1秒未満で完了しています。 Fidelity bondがあっても、LNの方が平均的には速いでしょう。

    • ● オンチェーンフットプリントが大きいという懸念: ある回答は、5秒ごとに1つのトランザクションを作成すると、 約200のカウンターパーティがブロックの全スペースを消費することになると指摘しました。 別の回答では、カウンターパーティのオンチェーントランザクションは、 LNのチャネル開設や協調クローズのトランザクションとほぼ同じサイズになると想定しており、 年間630万件のオンチェーントランザクションを作成する100万人のユーザーを持つカウンターパーティは、 同数のユーザーが年間平均6.3チャネルを開設またはクローズするのと同じスペースを使用します。 したがって、大規模なスケールに達するまでは、LNのオンチェーンコストは、 カウンターパーティを使用するよりも低くなる可能性があります。

    • ● 多額のホットウォレットと資本コストに関する懸念: カウンターパーティは、ユーザーが近い将来使うかもしれない金額と同量のビットコインを手元に （おそらくホットウォレットに）おいておく必要があるという回答がありました。 現在の設計案では、支払い後、カウンターパーティは最大28日間ビットコインを取り戻すことができません。 カウンターパーティが資本に対して年1.5%の低金利を課した場合、 これはカウンターパーティの関与で実行されるすべてのトランザクション（Coinjoin、内部送金およびLN支払いを含む）の金額対して、 0.125%の同等の手数料を課すことになります。これに対し、 この記事を書いている時点で利用可能な公開統計（1MLで収集）によると、 LN送金のホップごとの手数料率の中央値は0.0026%で、ほぼ50分の1です。

    また、メーリングリストに寄せられたコメントの中には、この提案に興奮し、 KeceliらがマネージドJoinpoolの設計スペースを探求するのを楽しみにしているというものもありました。

  • ● Nostrを利用したトランザクションリレー: Joost Jagerは、 リレーサービスを提供するBitcoinフルノードのP2Pネットワークでうまく伝播しない可能性のあるトランザクションのリレーに Nostrプロトコルを使用するというBen Carmanのアイディアについてのフォードバックを求めるために、 Bitcoin-Devメーリングリストに投稿しました。

    特に、JagerはトランザクションパッケージのリレーにNostrを使用する可能性を検討しています。 たとえば、最小受け入れ額以下の手数料を持つ祖先のトランザクションを、 祖先の不足分を補うために十分な手数料を支払う子孫とバンドルしてリレーします。 これにより、CPFPによる手数料の引き上げはより信頼性が高く効率的になります。 これは、Bitcoin Coreの開発者がBitcoin P2Pネットワークに実装しようとしている パッケージリレーと呼ばれる機能です。 パッケージリレーの設計と実装をレビューする際の課題は、 新しいリレー方法が、個々のノードやマイナー（またはネットワーク全体）に対して 新しいサービス拒否（DoS）の脆弱性を生じさせないようにすることです。

    Jagerは、Nostrリレーには、トランザクションをリレーするのに少額の支払いを要求するなど、 P2Pリレーネットワークとは別のタイプのDoS保護を簡単に使用できる機能があると指摘しています。 悪意あるトランザクションやパッケージがノードのリソースを少し消費する可能性があるとしても、 パッケージリレーや他の代替トランザクションのリレーを許可することが現実的であることを示唆しています。

    Jagerの投稿には、この機能をデモンストレーションした動画のリンクが含まれていました。 この記事を書いている時点では、彼の投稿にはまだ数件の返信しかありませんでしたが、 いずれも好意的なものでした。

承認を待つ #3: ブロックスペースの入札

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

先週、トランザクションは送金した額ではなく使用するブロックスペースに対して手数料を支払うと述べ、 マイナーは収集できる手数料を最大化するためにトランザクションの選択を最適化することを確認しました。 その結果、ブロックが見つかったときにmempoolの最上位に存在するトランザクションのみが承認されることになります。 この記事では、手数料を最大限に活用するための実践的な戦略について説明します。 手数料率の見積もりの適切な情報源があると仮定します。手数料率の見積もりについては、来週の記事で詳しく説明します。

トランザクションを構築する際、トランザクションのいくつかの部分は、他の部分よりも柔軟性があります。 すべてのトランザクションにはヘッダーフィールドが必要で、受信者のアウトプットは行われる支払いによって決まり、 ほとんどのトランザクションにはお釣りのアウトプットが必要です。 送信者と受信者の両方が、将来のトランザクションアウトプットの支払いコストを削減するために、 ブロックスペース効率の良いアウトプットタイプを優先すべきですが、 トランザクションの最終構成とweightを変更する余地が最も大きいのは、 インプットの選択時です。 トランザクションは、手数料率[fee/weight]で競争するため、 軽いトランザクションは同じ手数料率に達するのにより低い手数料ですみます。

Bitcoin Coreウォレットなど一部のウォレトは、お釣りのアウトプットが必要ないように、 インプットを組み合わせようとします。お釣りを避けることは、 現在のアウトプットのweightを節約するだけでなく、後でお釣りのアウトプットを使用するという将来のコストも削減します。 しかし、ウォレットがさまざまな額を持つ大きなUTXOプールを持っていない限り、 このようなインプットの組み合わせはめったにありません。

最新のアウトプットタイプは、古いアウトプットタイプよりもブロックスペース効率が高くなっています。 たとえば、P2TRインプットを使用すると、P2PKHインプットの2/5以下のweightしか発生しません。 （トランザクションサイズ計算ツールで試してみてください） マルチシグウォレットの場合、最近完成したMuSig2方式やFROSTプロトコルによって、 マルチシグ機能をシングルシグインプットのように見えるものにエンコードすることができ、 大幅なコスト削減が可能になります。特にブロックスペースの需要が急増した時には、 最新のアウトプットタイプを使用するウォレットは、それだけで大きなコスト削減につながります。

Overview of input and output weights

スマートウォレットは、手数料率に応じて選択の戦略を変更します。 手数料率が高い場合は、インプットのセットのweightをできるだけ小さくするために、 少ないインプットと最新のインプットタイプを使用します。 常に最も軽いインプットのセットを選択することで、現在のトランザクションのコストを局所的に最小化することができますが、 同時にウォレットのUTXOプールを小さな断片にすることになります。 このため、ユーザーはその後、高い手数料率で巨大なインプットのセットを持つトランザクションを作ることになります。 したがって、ウォレットが低手数料率でより多くの重いインプットを選択し、 その後のブロックスペース需要の急増を見越して、 より少ない最新のアウトプットに資金を集約することは先見の明があると言えます。

大量の支払いをするウォレットは、1回あたりの支払いのトランザクションweightを減らすために、 複数の支払いを1つのトランザクションにまとめることがよくあります。 支払い毎にヘッダーバイトとお釣り用のアウトプットのオーバーヘッドを負担するのではなく、 すべての支払いで共有されるオーバーヘッドコストだけを負担します。 いくつかの支払いをまとめるだけでも、支払い毎のコストはすぐに削減されます。

Savings from payment batching with P2WPKH

しかし、多くのウォレットが過払いな手数料率を推定しているにもかかわらず、 ブロックが遅くなったり、トランザクションの送信が急増すると、 トランザクションが予定よりも長く未承認のままになることがあります。 このような場合、送信者または受信者のどちらかがトランザクションの優先順位を変更したいと思うかもしれません。

一般に、ユーザーは自分のトランザクションの優先順位を上げるために、 CPFP（Child Pays For Parent）とRBF（Replace By Fee）の2つのツールを使うことができます。 CPFPでは、ユーザーは自分のトランザクションのアウトプットを使用して、高手数料率の子トランザクションを作成します。 先週の記事で説明したように、マイナーには手数料の高い子を含めるために親をブロックに含めるインセンティブがあります。 CPFPはトランザクションによて支払いを受けるユーザーなら誰でも利用できるため、 受信者または送信者（お釣り用のアウトプットを作成した場合）のどちらでも利用できます。

RBFでは、送信者は元のトランザクションより高い手数料率の置換トランザクションを作成します。 置換トランザクションは、元のトランザクションとの競合を確実にするため、 元のトランザクションから少なくとも１つのインプットを再利用しなければならず、 2つのトランザクションの内、1つだけがブロックチェーンに含まれます。 通常、この置換には元のトランザクションの支払いが含まれますが、 送信者は置換トランザクションの資金をリダイレクトしたり、 複数のトランザクションの支払いを置換トランザクションに統合したりすることもできます。 先週の記事で説明したように、ノードは元のトランザクションを退去させ、 よりインセンティブの高い置換トランザクションを採用します。

ブロックスペースの需要と生産は、どちらも私たちのコントロールが及ばないものですが、 ウォレットがブロックスペースを効果的に競り落とすために使えるテクニックはたくさんあります。 ウォレットは、お釣り用のアウトプットを排除したり、ネイティブsegwitアウトプット使用したり、 低手数料率の環境でUTXOプールをデフラグしたりすることで、より軽いトランザクションを作成して手数料を節約できます。 CPFPとRBFをサポートするウォレットは、控えめな手数料率から始めて、 必要に応じてCPFPまたはRBFを使ってトランザクションの優先順位を更新することもできます。

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

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

リリースとリリース候補

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

  • ● Bitcoin Core 25.0は、Bitcoin Coreの次期メジャーバージョンのリリースです。 このリリースでは、新しいscanblocks RPCが追加され、bitcoin-cliの使用が簡素化され、 finalizepsbt RPCにMiniscriptのサポートが追加され、 blocksonly設定オプションでデフォルトのメモリ使用量が削減され、 コンパクトブロックフィルターが有効になっている場合の ウォレットの再スキャンが高速化されるなど、多くの新機能、パフォーマンス改善、バグ修正が追加されています。 詳細はリリースノートを参照ください。

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

今週の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 #27469では、1つ以上のウォレットが使用されている場合のIBD（Initial Block Download）を高速化しました。 この変更により、ウォレットの誕生日（ウォレット作成時にウォレットに記録された日付）以降にマイニングされたブロックに対してのみ、 特定のウォレットに一致するトランザクションをスキャンするようになりました。

  • ● Bitcoin Core #27626では、ノードに高帯域幅モードでの コンパクトブロックリレーを使用するよう要求したピアは、 ノードが配信した最新ブロックから最大3つのトランザクションを要求できるようになりました。 ノードが最初にコンパクトブロックを提供しなかった場合でも、要求に応じます。 これにより、他のピアからコンパクトブロックを受信したピアが、不足しているトランザクションを要求できるようになり、 その他のピアが応答しなくなった場合に役立ちます。これにより、ピアがブロックを迅速に検証できるようになり、 マイニングなどの時間が重要な機能でより早くブロックを使用できるようになる可能性もあります。

  • ● Bitcoin Core #25796は、後で署名またはファイナライズをするのに役立つ情報でPSBTを更新するために使用できる 新しいdescriptorprocesspsbtを追加しました。RPCに提供されたディスクリプターは、 mempoolとUTXOセットから情報を取得するのに使用されます（利用可能な場合は、 ノードがtxindex設定オプションで起動した場合、承認されたトランザクションを完了します）。 そして、取得した情報はPSBTを埋めるために使用されます。

  • ● Eclair #2668は、EclairがオンチェーンでHTLCを解決する際に、 そのHTLCの解決によって得られる価値よりも多くの手数料を支払おうとするのを防止します。

  • ● Eclair #2666は、HTLCを受け取ったリモートピアが、 そのHTLCを受け入れるために支払わなければならない手数料によって、 ピアの残高が最小チャネルリザーブを下回ることになる場合でも、その受け入れを許可するようにします。 チャネルリザーブは、ピアが古い状態でチャネルを閉じようとした場合に、 少なくとも少額のお金を失うことになることを保証するために存在し、ピアが盗難を試みるのを阻止することを目的としています。 しかし、リモートピアが成功した場合に支払われるHTLCを受け入れる場合、 いずれにせよリザーブよりも多くをステークすることになります。成功しなかった場合は、 その残高は以前の金額に戻り、リザーブを上回ることになります。

    これは、スタックファンドの問題の緩和策です。この問題は、手数料の支払い責任を負う参加者が、 支払いによって、現在利用可能な残高よりも多くの額を支払う必要がある場合に発生します。 この問題に関する以前の議論については、ニュースレター #85を参照ください。

  • ● BTCPay Server 97e7eは、Payjoinの支払いに BIP78minfeerate（最小手数料率）パラメーターを設定するようになりました。 このコミットのきっかけになったバグレポートもご覧ください。

  • ● BIPs #1446は、Bitcoin関連プロトコルのSchnorr署名の仕様BIP340に 小さな変更と多くの追加を行いました。この変更は、署名されるメッセージの長さを任意に設定できるようにするものです。 ニュースレター #157で説明したLibsecp256k1ライブラリの関連する変更もご覧ください。 TaprootとTapscriptの両方 （それぞれBIP341と342）で使用される署名は32バイトのメッセージを使用するため、 この変更はコンセンサスアプリケーションにおけるBIP340の使用には影響しません。

    今回の追加では、任意の長さのメッセージを効果的に使用する方法、 ハッシュされたタグプレフィックスの使用方法の推奨、 異なるドメインで同じ鍵を使用する場合（トランザクションへの署名や、 平文メッセージへの署名など）の安全性を高める推奨事項を説明しています。