今週のニュースレターでは、Bitcoin関連のMIMEタイプの提案と、 新しい分散型のマイニングプールの設計についての論文を掲載しています。 また、Bitcoin Core PR Review Clubミーティングの概要や、 Taprootの準備、新しいリリースとリリース候補、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点などの恒例のセクションも含まれています。

ニュース

  • ● Bitcoin関連のMIMEタイプ: Peter Grayは、PSBTや、 バイナリフォーマットのトランザクション、BIP21 URI用のMIMEタイプのIANAへの登録について、 Bitcoin-Devメーリングリストに投稿しました。 Andrew Chowは、以前PSBTのMIMEタイプを登録しようとしたものの、 その申請は却下されたことを説明しました。 彼は、MIMEタイプの登録にはIETF仕様（RFC）を作成する必要があり、 定まった文書にするためには相当な作業が必要になると考えていました。 Grayは、代わりに、Bitcoinアプリケーションで使用される非公式のMIMEタイプを定義するためのBIPの作成を提案しました。

  • ● P2Poolの代替Braidpool: P2Poolは、2011年からから分散型のプールベースのBitcoinマイニングに使用されているシステムです。 Bitcoin-Devメーリングリストに投稿された新しい論文では、 認識されているいくつかの欠陥と、2つの注目すべき改善点を持つ分散型プールの代替設計について説明しています。 第三者へのトラストを最小限に抑えたペイメントチャネルの使用により支払い用のブロックスペースをより効率的に使用し、 プールメンバー間のより高いレイテンシー接続に対する許容度を高めます。

Bitcoin Core PR Review Club

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

Use legacy relaying to download blocks in blocks-only modeは、 Niklas GöggeによるPRで、-blocksonly設定オプションを設定しているノードが、 ブロックのダウンロードに常にレガシーなブロックリレーを使用するようにするものです。 Review Clubでは、レガシーなブロックダウンロードとBIP152スタイルのCompact Blockダウンロードを比較し、 blocksonlyノードが後者の恩恵を受けれない理由を議論しました。

  • レガシーなブロックリレーではどんなメッセージシーケンスが使用されていますか？

    v0.10以降のノードでは、ヘッダーを最初に同期します: ノードはまずピアからブロックヘッダーを含むheadersメッセージを受信します。 ヘッダーを検証した後、メッセージを通知したピアにgetdata(MSG_BLOCK, blockhash)メッセージを送信して完全なブロックを要求し、 ピアは完全なブロックを含むblockメッセージで応答します。 ➚

  • BIP152の低帯域幅のCompact Blockリレーで使用されるメッセージシーケンスはどんなものですか？

    ピアは、接続の開始時にsendcmpctメッセージを送信することで、Compact Blockリレーを使用したいことを通知します。 低帯域幅のCompact Blockリレーは、レガシーなブロックリレーと非常によく似ています: ノードはブロックヘッダーを処理した後、getdata(MSG_CMPCT_BLOCK, blockhash)メッセージを使ってピアにCompact Blockを要求し、 その応答でcmpctblockを受信します。ノードはCompact Blockのshortidを使って、 mempool内と追加のトランザクションキャッシュからブロック内のトランザクションを探すことができます。 それでも未知のトランザクションがある場合は、getblocktxnを使ってそれをピアに要求し、 応答でblocktxnメッセージを受信します。 ➚

  • BIP152の高帯域幅のCompact Blockリレーで使用されるメッセージシーケンスはどんなものですか？

    ノードは、接続の開始時にhb_modeに1を設定したsendcmpctメッセージを送信することで、 最初に接続を確立する際にピアに高帯域幅のCompact Blockを要求することができます。 これは、ピアが最初にヘッダーを送信したり、ブロックのgetdata要求を待つことなく、 直ちにcmpctblockを送信できることを意味します。必要に応じて、 ノードはgetblocktxnおよびblocktxnを使用して、低帯域幅のCompact Blockリレーと同じように、 ブロックの未知のトランザクションを要求、ダウンロードすることができます。 ➚

  • ブロックのダウンロード中に、blocksonlyのノードが帯域幅を無駄にする理由は何ですか？どのくらいの帯域幅が無駄になりますか？

    Compact Blockリレーは、ブロック内のトランザクションの大半を再ダウンロードする必要がないため、 mempoolを持つノードの帯域幅使用量を削減します。しかし、blocksonlyモードのノードは、 トランザクションのリレーに参加せず、通常そのmempoolは空です。 つまり、いずれにせよすべてのトランザクションをダウンロードする必要があります。 shortidやgetblocktxn、blocktxnのオーバーヘッドを加味すると1ブロックあたり約38kBの無駄な帯域幅が発生し、 getblocktxnメッセージとblocktxnメッセージの余計な往復により、ブロックのダウンロードにかかる時間も増加します。 ➚

  • blocksonlyモードのノードはmempoolを保持しますか？

    blocksonlyノードは、トランザクションリレーには参加していませんが、mempoolは持っており、 それにはいくつかの異なる理由でトランザクションが含まれている場合があります。 例えば、ノードが通常モードであった後にblocksonlyモードで再起動した場合、mempoolは再起動の間も保持されます。 また、ウォレットやクライアントインターフェースを介して送信されたトランザクションは、 mempoolを使用して検証、中継されます。 ➚

  • blocksonlyとblock-relay-onlyの違いは何ですか？今回の変更はblock-relay-onlyの接続にも適用すべきものですか？

    blocksonlyモードはノードの設定で、block-relay-onlはピア接続の属性です。 ノードはblocksonlyモードで起動すると、すべてのピアとのversionハンドシェイクでfRelay=falseを送信し、 トランザクション関連のメッセージを送信するピアを切断します。 blocksonlyモードかどうかに関わらず、ノードはblock-relay-only接続を持つことがあり、 その場合、トランザクションの受信やaddrメッセージを無視します。 このように、block-relay-only接続の存在は、ノードのmempoolのコンテンツや、 Compact Blockメッセージからブロックを再構築する機能とは関係がないため、 これらの変更をblock-relay-only接続に適用すべきではありません。 ➚

Taprootの準備 #12: VaultとTaproot

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

Revault開発者Antoine Poinsotの寄稿

BitcoinのVaultは、コントラクトの一種で、 ユーザーが自分のウォレットのお金を使用するのに、2つの連続したトランザクションを必要とします。 このようなプロトコルは数多く提案されているため（シングルもしくはマルチパーティ、Covenantあり、なし）、 それらの共通する点にフォーカスします。

1つのオンチェーントランザクションで複数の支払いを実行するバッチ支払いとは対照的に、 Vaultは1つの支払いを実行するために複数のトランザクションを使用します。 最初のトランザクションであるUnvaultは、以下のいずれかに支払いをします:

  1. 相対的なタイムロックの後で公開鍵のセットに、もしくは
  2. タイムロックのない単一の公開鍵に

最初の支払いのパスは、メインケースで、ホットキーの使用が予想されます。2つめの支払いのパスでは、 トランザクションのキャンセル（クローバック、リカバリー、再Vault化トランザクションと呼ばれることもあります）を可能にします。

このように、BitcoinのVaultは、ほとんどのコントラクトがすべての参加者が署名に協力するハッピーパス（ そしてタイムロックが含まれる紛争解決パス）を持っているTaprootの洞察とは対照的で、むしろ逆です。 支払いトランザクションは、相対的なタイムロック1により妨げられているため、 taprootのscriptpathを使用しなければなりませんが、キャンセルトランザクションは理論的にはkeypathを使用できます。

マルチパーティのVaultは、実際には既に多くの対話を必要としているため、 理論的にはMusig2のようなBIP340によって可能になったマルチシグや 閾値署名スキームの恩恵を受けることができます。 しかし、これらのスキームには、新たな安全性の課題があります。 Vaultのプロトコルは、コールドストレージに使用することを目的としているため、 設計上の選択はより保守的で、Vaultはおそらくこれらの新しい技術を使用する最後の場になるでしょう。

Taprootに切り替えることで、Vaultはマークルブランチと（特にマルチパーティの場合）より短いBIP340署名の使用により、 若干のプライバシーと効率性の向上の恩恵を受けることにになるでしょう。 例えば、6個の「コールド」キーと3個の「アクティブ」キーを持つ（閾値を2とした）マルチパーティのセットアップにおける Unvaultのアウトプットスクリプトは、深さ2のリーフを持つTaprootで表現できます:

  • <X> CSV DROP <active key 1> CHECKSIG <active key 2> CHECKSIGADD 2 EQUAL
  • <X> CSV DROP <active key 2> CHECKSIG <active key 3> CHECKSIGADD 2 EQUAL
  • <X> CSV DROP <active key 3> CHECKSIG <active key 1> CHECKSIGADD 2 EQUAL
  • <cold key 1> CHECKSIG <cold key 2> CHECKSIGADD <cold key 3> CHECKSIGADD <cold key 4> CHECKSIGADD <cold key 5> CHECKSIGADD <cold key 6> CHECKSIGADD 6 EQUAL

Taprootでは、アウトプットを使用するために使用するリーフのみを明かすため、 トランザクションweightは、P2WSHスクリプトの場合よりもかなり小さくなります:

IF
  6 <cold key 1> <cold key 2> <cold key 3> <cold key 4> <cold key 5> <cold key 6> 6 CHECKMULTISIG
ELSE
  <X> CSV DROP
  2 <active key 1> <active key 2> <active key 3> 3 CHECKMULTISIG
ENDIF

失効ブランチは、支払いが成功した場合には隠すことができますが（そしてマルチシグの閾値を使用する場合、 その存在と参加者の数を難読化できます）、Vaultの使用パターンはオンチェーンで簡単に識別できるため、 プライバシーの向上は最小限となります。

最後に、Vaultプロトコルは、ほとんどの事前署名されたトランザクションプロトコルと同様に、 BIP118のSIGHASH_ANYPREVOUTのようなTaprootを基に提案されたBitcoinのアップグレードから大きな恩恵を受けるでしょう。 さらなる注意とプロトコルの調整が必要ですが、ANYPREVOUTやANYPREVOUTANYSCRIPTは、再バインド可能なキャンセル署名を可能にします。 これにより、対話を大幅に減らすことができ、0(1)の署名の保存が可能になります。 これは、DoS攻撃の対象を大幅に削減することができるため、Revaultプロトコルの緊急署名にとって特に興味深いものになります。 アウトプットにANYPREVOUTANYSCRIPT署名を含めることにより、 このコインを使用するトランザクションがアウトプットを作成する方法を制限するCovenantを効果的に作成します。 さらにカスタマイズ可能な将来の署名ハッシュにより、より柔軟な制限が可能になります。

リリースとリリース候補

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

  • ● Bitcoin Core 22.0rc3は、 このフルノード実装とそれに付随するウォレットおよび他のソフトウェアの次のメジャーバージョンのリリース候補です。 この新バージョンの主な変更点は、I2P接続のサポート、 Tor v2接続の廃止、ハードウェアウォレットのサポートの強化などです。

  • ● Bitcoin Core 0.21.2rc2は、Bitcoin Coreのメンテナンス版のリリース候補です。

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

今週のBitcoin Core、 C-Lightning、Eclair、LND、 Rust-Lightning、libsecp256k1、 Hardware Wallet Interface (HWI)、 Rust Bitcoin、BTCPay Server、 Bitcoin Improvement Proposals（BIP）、および Lightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #22009では、コイン選択時に 分枝限定法（BnB）アルゴリズムとナップサックアルゴリズムの両方を常に実行し、 結果の費用対効果を比較する新しいwaste scoreヒューリスティックを使用し最良の結果を選択するようウォレットを更新しました。 これまでは、変化のないBnBの結果が見つかった場合、常にそれを優先していました。

    waste scoreヒューリスティックは、すべてのインプットは最終的に10 sat/vBの手数料率で使用されなければならず、 お釣り用のアウトプットは回避可能であると仮定しています。 インプットは、現在の手数料率とベースラインの手数料率でのコストの差としてスコア化され、 手数料率が低いときにインプットを使用するとwaste scoreが減り、手数料率が高いときに使用するとwaste scoreが増えます。 お釣り用のアウトプットは、それを作成するためのコストと将来それを使用するためのコストから、 常にwaste scoreを増加させます。

    さまざまな手数料率で使用するウォレットにおいては、このアプローチにより一部のインプットの消費がより低い手数料率にシフトされ、 ウォレット全体の運用コストが削減されます。統合と節約のコイン選択動作を分離するベースライン手数料率は、 新しいオプション-consolidatefeerateで設定できます。 その後のPR Bitcoin Core #17526では、Single Random Drawに基づく、第3のコイン選択アルゴリズムの追加が提案されています。

  • ● Eclair #1907は、エクリプス攻撃を防ぐためにブロックチェーン watchdogを使用する方法（ニュースレター #123参照）を更新しました。 Torが利用可能な場合、Eclairは（可能な場合、ネイティブなオニオンエンドポイントを使用して） watchdogへのコンタクトにTorを使用するようになりました。 これにより、上流の攻撃者がwatchdogプロバイダーだけを選択的に検閲することがより困難になるでしょう。

  • ● Eclair #1910は、Bitcoin CoreのZMQメッセージインターフェースの使用方法を更新し、 新しいブロックの情報を得る際の信頼性を向上させました。ブロックの発見にZMQを使用している人は、 この変更を調査することをお勧めします。

  • ● BIPs #1143は、output script descriptorを定義したBIP 380-386を導入しました。 output script descriptorは、ウォレットやその他のプログラムが特定のScriptや関連するScriptのセットに対して作成された支払いや、 使用された支払いを追跡できるようにするために必要なすべての情報を含む単純な言語です。 BIP380は、その理念や一般的な構造、共有式、チェックサムについて定義しています。 残りのBIPは、各descriptorの機能そのものを定義しており、非segwit (BIP381)、 segwit (BIP382)、multisig (BIP383)、アウトプットの組み合わせ(BIP384)、 RAW Scriptとアドレス(BIP385)、ツリー(BIP386) のdescriptorに分類されます。

  • ● BOLTs #847では、2つのチャネルピアが協調クローズするトランザクションで支払う手数料を調整できるようになりました。 これまでは、1つの手数料のみが送信され、相手はその手数料をそのまま受け入れるか拒否するというものでした。

  • ● BOLTs #880では、openchannelメッセージとacceptchannelメッセージにchannel_typeフィールドを追加し、 送信ノードがノードの配信したfeature bitとは異なるチャネル機能を明示的に要求できるようにしました。 この後方互換性のある変更は、Eclair #1867やLND #5669で既に実装されており、 C-Lightning #4616の一部としてマージが待たれています。

  • ● BOLTs #824では、anchor outputチャネルのステートコミットメントプロトコルに若干の変更を加えています。 以前のプロトコルでは、事前署名されたHTLCの使用では手数料を含むことができましたが、 これはニュースレター #115で説明されている手数料を盗む攻撃ベクトルを生むことになりました。 この代替プロトコルでは、すべての事前署名HTLCの使用は、手数料ゼロのため、手数料を盗むことはできません。

脚注

  1. 事前に分かっていれば、特定のnSequenceを持つ支払いトランザクションに事前署名することができますが、 そうすると「アクティブ」なキーを使った別の支払いパスはまったく必要ありません。 また、通常コインを受け取った時点で、そのコインをどう使うかはわかりません。 ↩