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

Bitcoin Optech Newsletter #139

Mar 10, 2021

今週のニュースレターでは、提案されているTaprootのアクティベーション方法に関する継続的な議論の要約と、 Taprootに基づいて構築されている既存のソフトウェアの文書化の取り組みのリンクを掲載しています。また、Bitcoin Core PR Review Clubミーティングの概要やリリースとリリース候補の発表、人気のあるBitcoinのインフラストラクチャプロジェクトの注目すべき変更点の解説などの通常のセクションが含まれています。

ニュース

● Taprootのアクティベーションに関する議論: 先週のアクティベーションに関する議論では、BIP8でLockinOnTimeout=true (LOT=true)とするか、 LOT=falseとするかで意見が割れたため、今週のメーリングリストでの議論のほとんどは、代替となるアクティベーションメカニズムに焦点を当てていました。いくつかの提案は以下のとおりです:
- ● User Activated Soft Fork (UASF): Bitcoin CoreのソフトフォークにBIP8 LOT=trueを実装するための計画が議論されています。この計画では、（広く提案されているように）2022年7月までにTaprootのアクティベートするようマイナーに要求しますが、マイナーはそれよりも早くアクティベートすることも可能です。
- ● フラグ・デイ: 今から約18ヶ月後に（提案されている）Taprootをアクティベートする特定のブロック高や時間をノードにプログラムするいくつかの提案（1、2）。アクティベーションにマイナーのシグナルは必要なく、早期のアクティベーションはできません。 Anthony Townsが実装のドラフトを書きました。
- ● 閾値の減少: 新しいコンセンサスルールがロックインされる前に、マイナーがTaprootの準備ができていることを通知する必要のあるブロックの数を、時間の経過とともに徐々に減少させるいくつかの提案（1、2）。ニュースレター #107で紹介したAnthony Townsの昨年の提案も参照。
- ● 設定可能なLOT: BIP8のLOTの値を設定オプションにするという以前議論された提案（ニュースレター #137参照）に加えて、 RPCコマンドを呼び出す外部スクリプトによってLOT=trueを適用する方法を示す大まかなコードが投稿されました。また、LOT=trueがブロックチェーンを不安定にすることを懸念するノード運用者が反対する方法を示す追加のコードも作成されました。
- ● 短期間のマイナーアクティベーションの試み: Taprootのアクティベーションロジックを実装したフルノードのリリース直後からマイナーがTaprootをロックインするまでに約3ヶ月の期間を与えるという更新された提案。この試みが失敗した場合、コミュニティには他のアクティベーション方法への移行が推奨されます。試みが成功した場合も、エコノミーのほとんどがノードをアップグレードできるよう、 Taprootがアクティベートされるまでに数ヶ月の遅延が発生します。この提案のために、Bitcoin Coreの既存のBIP9のコードをベースにしたものと、以前提案されたBIP8の実装をベースにした実装のドラフトが、それぞれAnthony TownsとによってAndrew Chow書かれました。
どの提案も、ほぼすべての人の第一希望になることはないと思われましたが、 Speedy Trialという名の短期間の試みを受け入れてもいいという人は多いようでした。一方、次のようないくつかの懸念事項もありました:
- ● 強制的なアクティベーションに利用される可能性: マイナーが早期にTaprootをサポートする通知をしない場合に他のアクティベーションの試行を推奨していますが、早期の強制アクティベーションを求めるユーザーのグループに利用されるのではないかという懸念が表明されました。ただし、このような危険なほど短いタイムラインで強制アクティベーションの試行を表明したグループはこれまでいません。
- ● 時間ベースのパラメーターか、高さベースのパラメーターか: 本提案では、（直近11ブロックの中央値に基づく）タイムスタンプかブロック高のいずれかを使用して、 start、timeoutおよびminimum_activationパラメーターを設定する際のトレードオフについて説明しています。タイムスタンプを使用すると、Bitcoin Coreへのパッチが最も小さく、レビューも容易になります。ブロック高を使用すると、特にマイナーにとって、少し予測可能性が高くなり、BIP8を使用する他の試みと互換性があります。
- ● 近視眼的: 提案が短期的なものに焦点を合わせすぎていることが懸念されました。 IRCで要約されているように、”Speedy Trialは、マイナーがTaprootをアクティベートする（可能性の高い）ケースに完全に備えるものですが、 Segwitがタイムリーにアクティベートできなかったことから得られた教訓を体系化したものではありません。 Taprootのアクティベーションは、今後のアクティベーションのテンプレートを作成する機会です。このテンプレートは、最良の結果だけでなくアクティベーションを進行するためのあらゆる方法において、開発者、マイナー、マーチャント、投資家およびエンドユーザーの役割と責任を明確に定義します。特に、Bitcoinの実用上のユーザーが持つ最終決定者の役割を有効にし、正式に記します。これを定義することは、将来ますます困難になるでしょう。なぜなら、それを定義するのはすでに危機に陥っているときのみで、 Bitcoinの成長は、将来の合意がより大きな規模で行われる必要があり、それはより困難になることを意味するからです。”
- ● スピード: この提案はIRCのチャネル ##taproot-activation での最初の議論に基づき、マイナーにTaprootをロックインするのに約3ヶ月与え、（ロックインが達成された場合）アクティベートまでにシグナルの計測開始から固定の6ヶ月待つことを提案しています。これに対して、もう少し短いタイムラインや長いタイムラインを求める声がありました。
さまざまな提案に関する議論を引き続き追跡し、今後のニュースレターで重要な進展をまとめます。
● Taprootを利用する、Taprootに依拠する意思の文書化: アクティベーション方法に関する議論の中で、Chris Belcherは、ソフトフォークのアクティベートに関する議論において開発者がSegwitを実装する意思があること表明したソフトウェアの大規模なリストが編集されたことを指摘しました。彼は、同様のリストを作成し、Taprootを支持する総計を後世のために記録することを提案しました。そうすれば、Taprootがどのような方法でアクティベートされることになったとしても、エコノミーの大部分がTaprootを望んでいることが明らかになるでしょう。

Jeremy Rubinは、Bitcoin-Devメーリングリストに開発者がTaprootの新機能の提案に基づいて構築されたプロジェクトのリンクを投稿できる、それに似たwikiページへのリンクを投稿しました。これにより、Taprootが人々が実際に望むソリューションを提供し、その機能が利用されるように設計されていることを保証することができます。

Bitcoin Core PR Review Club

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

Erlay: bandwidth-efficient transaction relay protocolは、 Gleb NaumenkoによるPR（#18261）で、 BIP330をBitcoin Coreに実装することを提案しています。

Review Clubでは、Erlayに関連するトレードオフ、実装および潜在的な新しい攻撃ベクトルに焦点を当てて議論しました。その後のミーティングでは、 Erlayの効率的なリレープロトコルの基礎となるPinSketch set reconciliation アルゴリズムを実装したライブラリであるMinisketchについて議論しました。

Erlayとは？

帯域幅の効率やスケーラビリティおよびネットワーク・セキュリティを向上させるために、 フラッディングとset reconciliationの組み合わせをベースにした新しいトランザクションリレー方法です。このアイディアは、2019の論文Bandwidth-Efficient Transaction Relay for Bitcoin で発表され、BIP330で規定されています。
Erlayがもたらすメリットは?

ノード運用に必要な帯域幅のおよそ半分を占めるトランザクションリレーのための帯域幅使用量が減少し、ピア接続のスケーラビリティが向上することで、ネットワークが分断攻撃に対してより堅牢になり、単一ノードがエクリプス攻撃に対してより耐性を持つようになります。
Erlayのトレードオフは何ですか？

トランザクションの伝播レイテンシーがわずかに増加します。Erlayでは、すべてのノード間で未確認のトランザクションをリレーする時間が3.15秒から5.75秒に増加すると推定されます。これは全体のトランザクション処理時間である約10分のごく一部です。もう１つのトレードオフは、コードの追加と計算の複雑さです。 ➚
なぜErlayで導入されるset reconciliationはフラッディングよりもスケールするのですか？

各ノードが受信したすべてのトランザクションをそのピアに通知するフラッディングによるトランザクション伝播は、帯域幅の効率が悪く、冗長性が高くなります。これはネットワークの接続が向上するとより顕著になりますが、ネットワーク接続の向上はネットワークの成長とセキュリティには望ましいことです。 Erlayは、非効率なフラッディングによって送信されるトランザクションデータを減らし、より効率的なset reconciliationに置き換えることで、スケーラビリティを向上させます。
既存のP2Pメッセージタイプの頻度はどう変化しますか？

Erlayでは、invメッセージの頻度は減り、getdataとtxメッセージの頻度は変わりません。 ➚
2つのピアはどうやってErlayのset reconciliationの使用に合意するのですか？

version-verackのハンドシェイク中に交換される新しいsendreconP2Pメッセージを介して合意します。 ➚

リリースとリリース候補

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

● Eclair 0.5.1は、このLNノードの最新のリリースで、起動速度の向上、ネットワークグラフの同期時に消費する帯域幅の削減、 Anchor Outputのサポートに向けた一連の小さな改善が行われています。
● HWI 2.0.0RC2は、HWIの次期メジャーバージョンのリリース候補です。

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

今週の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 #20685では、I2P SAMプロトコルを使用したI2Pプライバシーネットワークのサポートが追加されています。この機能は長い間要望されていましたが、addr v2の追加によって最近可能になりました。 I2Pの実行を希望するノード運用者のためのドキュメントはまだ作成中ですが、 Bitcoin Stack Exchange Q&Aに開始するためのヒントが記載されています。
● C-Lightning #4407は、listpeersRPCを更新し、各チャネルの現在の一方的なクローズ・トランザクションに関する手数料（手数料の総額と手数料率の両方）を含む情報を提供するフィールドを追加しました。
● Rust-Lightning #646は、マルチパス支払いのサポートを追加できるように、支払いのための複数のパスを検索する機能を追加しました。
● BOLTs #839では、ファンディング・トランザクションの確認に失敗した場合に、ファンディング手数料を節約するためのファンディング・トランザクションのタイムアウトに関する推奨事項が追加され、チャネルの資金提供者と受給者に強力な保証を提供します。新しい推奨事項では、資金提供者が2016ブロック以内にファンディング・トランザクションが確実に承認されることをコミットし、受給者が2016ブロック以内にそれを確認できない場合、保留中のチャネルを忘れることを推奨しています。
● BTCPay Server #2181は、BIP21のURIをQRコードとして提示する際にbech32アドレスを大文字にします。これにより、大文字の部分文字列をより効率的にエンコードできるため、QRコードの密度が低くなります。この変更に先立ち、BIP21 URIスキームを持つウォレットの広範な互換性調査が行われました。