今週のニュースレターでは、先週のTaprootのアクティベーションミーティングの要約へのリンクと、 来週に予定されている次のミーティングの告知、さらに最近のDiscreet Log Contractsの進捗状況と、 それを議論するための新しいメーリングリストについて説明します。また、Bitcoin Core PR Review Club のミーティングの要約、リリースとリリース候補の説明および人気のBitcoinインフラストラクチャソフトウェアの 注目すべき変更点のリストなどの通常のセクションも掲載しています。

ニュース

  • ● Taprootのアクティベーションミーティングの要約とフォローアップ: Michael Folksonは、Taprootのアクティベーション方法について議論するために予定されていたミーティング （ニュースレター #133参照）の要約を投稿しました。 参加者の間では、アクティベーションコードを含むBitcoin Coreの最初のリリースから最速で約２ヶ月後にアクティベーションされ、 最も遅いアクティベーションは最初のデプロイメントから約１年後とするBIP8アクティベーション方式が支持されているようでした。

    より議論を呼んだのは、LockinOnTimeout (LOT) パラメーターのデフォルトをtrueにするか （マイナーは最終的に新しいルールを支持するシグナルを出すか、チェーン分岐のリスクを冒すかのどちらかを要求されます）、 falseにするか（マイナーはすぐに結論を出す必要がなく、好きなようにシグナルを送ることができ、 一部のユーザーは後からLOT=trueを有効にすることができます）ということでした。 Folksonは、メーリングリストに２つめの投稿を行い、２つの異なるオプションについてみられた議論の要約と、 それら（およびあまり議論の余地のない問題）について議論するためのフォローアップミーティングを2月16日19:00 UTCから Freenodeの##taproot-activationチャンネルで開催することを発表しました。

  • ● Discreet Log Contractsの新しいメーリングリスト: Nadav Kohenは、Discreet Log Contracts (DLC)に関連するトピックを議論するための 新しいメーリングリストの作成を発表しました。 彼はまた、複数の互換性のある実装、ECDSAアダプター署名の使用や、 数値の結果を条件とするDLCに対する効果的な圧縮アルゴリズム、”オラクル間である程度の制限のある差異が許可される数値のケースもサポートする” オラクルからのk-fo-nしきい値署名のサポートなど、DLCの開発の現状を要約しました。

Bitcoin Core PR Review Club

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

Only support compact blocks with witnessesは、 BIP152 Compact Blockの非Segwitバージョンのサポートの削除を提案する John NewberyのPR（#20799）です。

Review Clubの議論では、コードの変更に飛び込む前に、Compact Block、高帯域幅モードと低帯域幅モードおよび バージョン管理と互換性の理解に焦点が当てられました。

  • Compact Blockとは？

    BIP152で定義されているCompact Blockは、BitcoinのP2Pネットワークネットワークを介して、 帯域幅の使用量を抑えてブロックを中継する方法です。それは、トランザクションの伝播中に、 ピアが受信したブロックに含まれるほとんどのトランザクションを既に知っているという事実を利用しています。 Compact Blockは、高帯域幅モードもしくは低帯域幅モードで中継することができます。 高帯域幅モードで中継する場合、Compact Blockはブロックの伝播を高速化することもできます。 

  • Compact Blockを機能させるために必要なことは何ですか？

    受信者はブロックに含まれる可能性が高いトランザクションを含むmempoolを持っていなければなりません。 そのため、Compact Blockはブロックチェーンの先端もしくはその近くのブロックを中継する場合にのみ有用です。 古いブロックの場合、受信者はmempoolにトランザクションを持っておらずgetblocktxnメッセージを使ってそれらを要求する必要があります。 このようなケースでは、ブロック全体を要求するだけの方が効率的です。 

  • Compact Blocksはどうやって帯域幅を節約しているのですか？

    完全なトランザクションIDの代わりに、Compact Blockには、 サイズは小さくともトランザクションを一意に識別するのに十分な短縮IDが含まれています。 Compact Blockを受信したノードは、各短縮IDをmempool内のトランザクションと一致させて完全なブロックを再構築します。 これによりブロックリレーの帯域幅が大幅に削減されます。 ➚

  • “高帯域幅”モードと”低帯域幅”モードの違いは何ですか？

    高帯域幅モードでは、Compact Blockは一方的に送信され、より高い帯域幅を使ってレイテンシーを向上させます。 一方、低帯域幅モードでは、invメッセージまたはheadersメッセージを受信後に要求に応じて送信されます。 高帯域幅モードでは、完全な検証の前にCompact Blockメッセージを中継することができ、 中継する前にブロックヘッダーが有効である必要があるだけです。 ➚

  • 高帯域幅モードのピアをどうやって選択するのでしょうか？

    最近、新しい有効なブロックを送信したピアを最大３つ選択します。 このロジックはnet processing関数MaybeSetPeerAsAnnouncingHeaderAndIDsにあります。 ➚

  • なぜバージョン１のCompact Blockのサポートをやめることができるのでしょうか？

    BIP152は、バージョン１（witnessなし）とバージョン２（witnessあり）の２つのバージョンをサポートしています。 バージョン２はSegwitブロックの再構築に必要です。Segwitは2017年8月にアクティベーションされたため、 ピアにバージョン１のSegwit前のCompact Blockを提供することはもはや有用ではありません。 witnessがないと、ピアはブロックがコンセンサスルールに従っていることを検証することができません。 ➚

  • 実際、バージョン１のサポートをどうやってやめることができるのでしょうか？

    バージョン１のsendcmpctメッセージを無視し、バージョン１のサポートを示すsendcmpctを送信しないようにし、 NODE_WITNESSピアへのsendcmpctメッセージの送信のみを行い、sendcmpctメッセージおよびblocktxn メッセージには、witnessシリアライズされたブロックおよびトランザクションで応答するようにします。 

リリースとリリース候補

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

  • ● LND 0.12.1-beta.rc1は、LNDのメンテナンスリリースのリリース候補です。 誤ってチャネルが閉鎖される可能性があるエッジケースと、一部の支払いが不必要に失敗する可能性があるバグの修正に加えて、 いくつかのマイナーな改善とバグ修正が行われています。

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

今週の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 #19509では、ノード間のピア毎のメッセージのキャプチャと、それらのログからJSON出力を生成する機能が追加されています。 新しく導入されたコマンドライン引数-capturemessagesを使用すると、ノードが送受信する全てのメッセージがログに記録されます。 同様の機能を持つツールは長い歴史がありますが、今回の追加により、 あまり積極的にメンテナンスされていないオプションに代わるネイティブな選択肢が提供されます。

  • ● Bitcoin Core #20764では、bitcoin-cli -netinfoを使って生成される出力に追加情報が追加されました。 新しい詳細情報には、ピアの種類（フルリレーやブロックオンリーなど）、手動で追加されたピアの数、 BIP152“高帯域幅”（高速）ブロックリレーモードを使用しているピア、 I2P匿名ネットワーク（別のPRで作業中）を使用しているピアなどが含まれます。

  • ● Rust-Lightning #774では、Bitcoin CoreのRESTおよびRPCインターフェースからブロックとヘッダーをフェッチするサポートが追加されています。 さらに、BlockSourceインターフェースが追加され、カスタムソースで動作するよう拡張することができます。

  • ● HWI #433は、OP_RETURNアウトプットを持つPSBTへの署名のサポートを追加しています。

  • ● BIPs #1021では、BIP8ソフトフォークアクティベーション方式が更新され、 lockin on timeout機能の強制を選択したノードの動作が変更されました。 以前は、強制的なアクティベーション期間中にアクティベーションのシグナルを出さなかったブロックは、ノードによって拒否されていました。 この変更後は、アクティベーションを保証するのが可能な最大数まで非シグナリングブロックを許容するようになりました。 これにより不必要に拒否される可能性のあるブロックの数が減り、マイナーとノードオペレータ間の誤通信の可能性が減ります。

  • ● BIPs #1020は、最近追加されたMust Signal期間に必要なシグナリングを使って アクティベーションを保証できるようになったため、Locked In期間中のシグナリングを不要とするようBIP8を更新しました。

  • ● BIPs #1048では、数週間前にメーリングリストで提案された（ニュースレター#130参照） generic message signingのためのBIP322の提案の大部分を書き換えました。 この変更により、完全なチェックセットを実装していないウォレットは、理解できないスクリプトを使用する署名に対して、 “不確定”の状態を返すことができるようになりました。また、実装手順を明確にし、署名のシリアライゼーションに不要なデータを削除しています。

  • ● BIPs #1056では、以前メーリングリストで議論されていた（ニュースレター#131参照） bech32の変更された仕様（bech32m）であるBIP350を追加しています。 BIP173のbech32アドレスのこの修正版は、計画されているTaprootのアドレスと、 Segwitのwitness scriptを使用する今後の改善に適用されます。

  • ● BIPs #988では、 空のインプットフィールドを初期化する既存の要件と同様に、 Creatorロールで動作するプログラムが空のアウトプットフィールドを初期化するようPSBTの仕様BIP174を更新しています。 Bitcoin Coreのような既存のPSBT Creatorは既にこれを行っています。

  • ● BIPs #1055は、独自仕様の拡張の形式を明確にするためBIP174を更新し、 フィールドの表を異なるバージョンのPSBTでどのように適用されるかを示す行で拡張し、 PSBTのオリジナルバージョン 0についてBIPをFinalとしてマークします。

  • ● BIPs #1040では、親のBIP32キーチェーンから、鍵とキーチェーンを作成するための仕様BIP85を更新しました。 今回の更新では、親のキーチェーンを使用して、GPG互換のスマートカードにロード可能なRSAベースのPGP署名鍵を作成する方法について説明しています。

  • ● BIPs #1054では、Segwitのコンセンサスの変更の仕様BIP141を更新し、OP_CHECKMULTISIGおよびOP_CHECKMULTISIGVERIFY を使用した場合の署名操作（sigops）のカウント方法を明確にしました。以前の文章では、これらはP2SHを使用した時と同じようにカウントされると 記載されていましたが、今回の更新では直観的ではない特殊性が説明されています: “公開鍵の総数が1から16の場合、CHECKMULTISIGはそれぞれ１から16のsigopsとしてカウントされ、 公開鍵の総数が17から20の場合、20 sigopsとカウントされます。”

  • ● BIPs #1047は、フレーズからBIP32シードを決定論的に生成する仕様BIP39を更新し、 英語以外の単語リストの使用は広くサポートされていないため実装には推奨しない、という警告を追加しています。