今週のニュースレターでは、Taprootのannexフィールドにデータを含むトランザクションの リレーを許可することについての議論と、サイレントペイメントのBIPドラフトのリンクを掲載しています。 また、mempoolポリシーに関する限定週刊シリーズの新しい記事に加えて、 Bitcoin Core PR Review Clubミーティングの要約や、新しいソフトウェアのリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● Taproot annexに関する議論: Joost Jagerは、 Taprootのannexフィールドに任意のデータを保存できるようにするために、 Bitcoin Coreのトランザクションリレーとマイニングポリシーの変更を求める要望を Bitcoin-Devメーリングリストに投稿しました。 このフィールドは、Taprootトランザクションのwitnessデータのオプション部分です。 このフィールドが存在する場合、TaprootとTapscript内の署名は、 そのデータにコミットしなければなりません（第三者が追加、削除、変更できないようにするため）が、 現時点ではそれ以外に定義された目的はなく、将来のプロトコルアップグレード、特にソフトフォークのために予約されています。

    annexのフォーマットを定義する提案は以前からありましたが、 広く受け入れられ実装されたものはありませんでした。Jagerは、 ソフトフォークにバンドルされる可能性のある将来の標準化の取り組みを著しく複雑にするこなく、 誰でも任意のデータをannexに追加できるようにするために使用できる2つのフォーマット（1、2）を提案しました。

    Greg Sandersは、Jagerが具体的にどんなデータをannexに保存したいのかを尋ね、 Bitcoin Inquisitionを使用したSIGHASH_ANYPREVOUTのソフトフォーク提案で、 LN-Symmetryプロトコルをテストするためにannexを使用した自分の使用法を説明しました （ニュースレター #244参照）。 Sandersはまた、annexの問題点を説明しました。マルチパーティプロトコル（Coinjoinなど）では、 各署名はその署名が含まれるインプットのannexのみにコミットし、 同じトランザクションの他のインプットのannexにはコミットしません。 つまり、アリス、ボブ、マロリーが一緒にCoinjoinに署名する場合、 アリスとボブは、マロリーが巨大なannexを持つバージョンのトランザクションをブロードキャストして 承認を遅らせることを防ぐことができません。Bitcoin Coreや他のフルノードは、 現在annexを含むトランザクションをリレーしないため、これは今のところ問題になっていません。 Jagerは、ソフトフォークを必要としないタイプのVaultのために、 一時鍵の署名を保存したいと答え、Bitcoin Coreのいくつかのこれまでの研究により、 マルチパーティプロトコルにおけるannexのリレーの問題に対処できる可能性があることを示唆しました。

  • ● サイレントペイメントのBIPドラフト: Josie BakerとRuben Somsenは、 サイレントペイメントのBIPドラフトをBitcoin-Devメーリングリストに投稿しました。 サイレントペイメントは、使用される度に一意のオンチェーンアドレスを生成し、 アウトプットのリンクを防止する再利用可能なペイメントコードの一種です。 アウトプットのリンクは、（トランザクションに直接関与していないユーザーも含む）ユーザーのプライバシーを著しく低下させる可能性があります。 ドラフトでは、この提案の利点、トレードオフ、ソフトウェアが効果的に利用する方法について詳しく説明されています。 BIPのPRには、すでにいくつかの洞察に満ちたコメントが投稿されています。

承認を待つ #5: ノードリソースの保護に関するポリシー

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

私たちは、Bitcoinのプライバシーと検閲耐性の多くはネットワークの分散化された性質に起因していると述べて、 このシリーズを始めました。ユーザーが自分のノードを実行することで、 障害、監視、検閲の中心点を削減することができます。そのため、 Bitcoinノードソフトウェアの主な設計目標の１つは、ノードを実行するための高いアクセシビリティです。 各Bitcoinユーザーに、高価なハードウェアを購入したり、特定のオペレーティングシステムを使用したり、 また運用コストとして毎月数百ドルを費やすことを要求すると、ネットワーク上のノード数が減少する可能性が非常に高くなります。

さらに、Bitcoinネットワーク上のノードは、未知のエンティティへのインターネット接続を持つコンピュータであり、 ノードがメモリ不足に陥りクラッシュするようなメッセージを作成したり、 新しいブロックを受け入れるために意味のないデータに計算リソースや帯域幅を費やしたりすることで、 サービス拒否（DoS）攻撃を行う可能性があります。 これらのエンティティは設計上匿名であるため、ノードは接続前にそのピアが正直か悪意があるかを事前に判断することはできず、 攻撃が観測された後でも効果的に禁止することができません。したがって、 DoSから保護し、フルノードの実行コストを制限するポリシーを実装することは、単なる理想ではなく、必須なことです。

リソースの枯渇を防ぐために一般的なDoS保護がノードの実装に組み込まれています。 たとえば、Bitcoin Coreノードが１つのピアから多くのメッセージを受信した場合、 最初の１つだけを処理し、残りは他のピアのメッセージの後に処理されるようにワークキューに追加されます。 また、ノードは通常、ブロックをダウンロードして検証する前に、まずブロックヘッダーを最初にダウンロードし、 そのProof of Work（PoW）を検証します。したがって、ブロックリレーによってノードのリソースを枯渇させようとする攻撃者は、 まず有効なPoWを計算するために不釣り合いなほど膨大なリソースを費やす必要があります。 PoWの計算にかかる膨大なコストと検証にかかる些細なコストの非対称性により、 ブロックリレーにDoS耐性を組み込む自然な方法が提供されます。 この特性は、未承認 トランザクションのリレーには適用されません。

一般的なDoS保護では、ノードのコンセンサスエンジンがピアツーピアネットワークからの入力にさらされることを許容するだけの 十分な攻撃耐性を提供しません。最大限の計算量を必要とするコンセンサスが有効なトランザクションを作ろうとする攻撃者は、 #364292 ブロックにあった1MBの“メガトランザクション”のようなものを送信するかもしれません。 このトランザクションは、署名検証と二乗的なsighash計算によって検証に異常に長い時間を要しました。 攻撃者は、最後の署名以外はすべて有効な署名を作成し、ノードにトランザクションの検証に数分をかけさせ、 最後にそれがゴミであることがわかるようなものを作ることもできます。 その間、ノードは新しいブロックの処理を遅らせます。この種の攻撃は、 次のブロックで先手を打つために、競合するマイナーを標的にしていると想像できます。

非常に計算量の多いトランザクションの作業を回避するために、 Bitcoin Coreノードは、各トランザクションに対して、最大標準サイズと 最大署名操作数（または「sigops」）を課し、ブロックのコンセンサス制限よりも厳しく制限しています。 また、Bitcoin Coreノードは、祖先と子孫の両方のパッケージサイズに制限をかけることで、 ブロックテンプレートの作成と退去のアルゴリズムをより効果的にし、 トランザクションの祖先と子孫のセットを更新する必要があるmempoolの挿入と削除の 計算量を制限しています。 これは、一部の正当なトランザクションが受理またはリレーされないことを意味しますが、 そのようなトランザクションは稀であることが予想されます。

これらは トランザクションリレーポリシー の例で、 ノードが未承認トランザクションに適用する、コンセンサスに加えて行う一連の検証ルールです。

デフォルトでは、Bitcoin Coreノードは、1sat/vBの最小リレー手数料率（「minrelaytxfee」）を 下回るトランザクションを受け入れず、この要件を受け入れる前にいかなる署名も検証せず、 自分のmempoolに受け入れられない限りトランザクションをリレーしません。 ある意味、この手数料率ルールは、ネットワークの検証とリレーの最小「価格」を設定します。 マイニングを行わないノードは手数料を受け取ることはなく、 手数料はトランザクションを承認したマイナーにのみ支払われれます。 手数料が確認されるまでにネットワーク帯域幅の一部は既に使用されていますが、手数料は攻撃者にとってのコストになります。 検証とリレーを必要とするトランザクションを極端に多く送信する人は、やがて手数料を支払うお金がなくなります。

Bitcoin Coreに実装されているReplace by Feeポリシーは、 置換トランザクションは直接競合する各トランザクションよりも高い手数料率を支払う必要があり、 置き換えられるすべてのトランザクションよりも高い総手数料を支払う必要があります。 追加の手数料を置換トランザクションの仮想サイズで割った値は、少なくとも1sat/vBでなければなりません。 言い換えれば、元のトランザクションと置換トランザクションの手数料率に関係なく、 新しいトランザクションは1sat/vBで独自の帯域幅のコストをカバーするために「新しい」手数料を支払わなければなりません。 この手数料ポリシーは、インセンティブの互換性に主眼を置いたものではありません。 むしろ、これにより、帯域幅を浪費する攻撃を抑制するために、 トランザクションを繰り返し置換する最小限のコストを発生させます （たとえば、置換の度に1 satoshiだけ追加するようなもの）。

ブロックとトランザクションを完全に検証するノードは、メモリや計算リソース、ネットワーク帯域幅を含むリソースを必要とします。 ノードの実行を容易にし、ノードを攻撃から守るためには、必要なリソースを低く抑える必要があります。 一般的なDoS保護だけでは不十分なため、ノードは未承認トランザクションを検証する際に、 コンセンサスルールに加えてトランザクションリレーポリシーを適用します。 しかし、ポリシーはコンセンサスではないため、2つのノードが異なるポリシーを持っていても、 現在のチェーンの状態について合意することは可能です。来週の記事では、個人の選択としてのポリシーについて説明します。

Bitcoin Core PR Review Club

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

Allow inbound whitebind connections to more aggressively evict peers when slots are fullは、 Matthew Zipkin（pinheadmz）によるPRで、特定のケースでノードオペレーターが 希望するピアをノードに設定する機能を改善します。 具体的には、ノードオペレーターが潜在的なインバウンドピア（たとえば、ノードオペレーターが管理する軽量クライアント）を ホワイトリストに登録している場合、このPRがなければ、 ノードのピアの状態によっては、この軽量クライアントの接続試行をノードが拒否する可能性があります。

このPRにより、目的のピアがノードに接続できる可能性が大幅に高まります。 これは、このPRがなければ排除対象外だった既存のインバウンドピアを排除することで行われます。

  • なぜこのPRはインバウンドピアのリクエストのみに適用されるのですか？

    私たちのノードは、アウトバウンド接続を 開始 します。このPRは、 ノードがインバウンド接続リクエストに 反応する 方法を変更します。 アウトバウンドノードは排除することはできますが、それは全く別のアルゴリズムで行われます。 ➚

  • SelectNodeToEvict()のforceパラメーターは、戻り値にどのような影響を及ぼしますか？

    forceをtrueに設定すると、非nobanのインバウンドピアが存在する場合、 それらが排除対象外であっても、確実にピアが返されます。 このPRがないと、すべてのピアが排除対象外である場合、ピアは返されません。 ➚

  • このPRでは、EraseLastKElements()関数のシグネチャはどのように変更されますか？

    戻り値がvoidから、排除候補リストから削除された最後のエントリーを返すように変更されました。 （この保護されたノードは、必要であれば排除されるかもしれません。） しかし、Review Clubでの議論の結果、PRはその後簡素化され、 この関数は変更されなくなりました。 ➚

  • EraseLastKElementsはテンプレート関数でしたが、このPRでは、 2つのテンプレート引数を削除しています。これはなぜですか？この変更にはなにか不都合があるのでしょうか？

    この関数は、以前も（このPRでも）一意のテンプレート引数で呼び出されていたため、 この関数をテンプレート化する必要はありません。PRによるこの関数の変更は取り消され、 これを変更するのはPRの範囲を超えるため、まだテンプレート化されたままになっています。 ➚

  • SelectNodeToEvict()に40個の排除候補を渡すとします。このPRの前後で、 排除から保護できるTorノードの理論上の最大数はいくつですか？

    PRの有無に関わらず、nobanやインバウンドでないと仮定すると、その数は40の内34になります。 ➚

リリースとリリース候補

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

  • ● Core Lightning 23.05.1は、このLN実装のメンテナンスリリースです。 リリースノートには、「これはバグ修正のみのリリースで、実際に報告されているいくつかのクラッシュを修正しています。 これは、v23.05を使用しているすべての人に推奨されるアップグレードです。」と記載されています。

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

今週の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 #27501では、ユーザーがprioritisetransactionで作成したすべての手数料デルタのマップを txidでインデックスして返すgetprioritisedtransactionsを追加しました。 このマップは、各トランザクションがmempoolに存在するかどうかも示します。 ニュースレター #250もご覧ください。

  • ● Core Lightning #6243は、listconfigsRPCを更新し、 すべての設定情報を１つの辞書にまとめ、すべての設定オプションの状態を再起動したプラグインに渡すようにします。

  • ● Eclair #2677は、max_cltvのデフォルト値を1,008ブロック（約1週間）から、 2,016（約2週間）に増やしました。これは、支払いの試行がタイムアウトするまでのブロック数の最大許容値を延長します。 この変更は、ネットワーク上のノードが、オンチェーン手数料率の高さに対応して、 期限切れのHTLC（cltv_expiry_delta）に対処するための予約時間枠が引き上げられたことに起因しています。 同様の変更がLNDとCLNにマージされています。

  • ● Rust bitcoin #1890は、非Tapscriptスクリプトの署名操作（sigops）の数をカウントするメソッドを追加しました。 sigopsの数は、ブロック毎に制限されており、Bitcoin Coreのマイニング用トランザクションの選択コードは、 サイズ（weight）あたりのsigopsの比率が高いトランザクションを、より大きなトランザクションのように扱い、 事実上、そのトランザクションの手数料率を下げます。そのため、トランザクション作成者は、 この新しいメソッドのようなものを使用して、自分が使用しているsigopsの数を確認することが重要になる可能性があります。