今週のニュースレターは、Bitcoin Coreのリリース候補（RC）のテスト支援募集、BIP119 OP_CHECKTEMPLATEVERIFY提案に関する議論についてです。また、Bitcoinのコードとドキュメントの主要な変更についてもお送りします。

今週のニュースレターでは、C-Lightning 0.8.1のリリースの発表、Bitcoin Coreメンテナンスリリースのテスト募集、taprootとMASTおよびschnorr署名の個別実装に関する議論の要約、LNチャネル構築でのPoDLEの使用に関する新しいアイデアについての説明、プライバシーが強化されたLNの非公開チャネルへの支払いに関する説明をまとめています。また、Bitcoinのサービス、クライアントソフトウェア、およびインフラストラクチャプロジェクトの主要な変更についてもお送りします。

Action items

  • ● C-Lightning 0.8.1へのアップグレード: このリリースではいくつかの新機能（以下のNotable code and documentation changesで説明されている機能含む）が追加され、複数のバグ修正が提供されます。詳細については、変更ログを参照してください。

  • ● Bitcoin Core 0.19.1rc2のテスト支援: 今回のメンテナンス・リリース には、いくつかのバグ修正が含まれています。経験豊かなユーザーは、予期した通りに動くか、テストで確認することをお勧めします。

News

  • ● Taprootと代替案についての議論: 匿名のままにすることを好む開発者グループ（したがって、Anonと呼びます）は、BitcoinでMASTおよびSchnorr署名を有効にする代替手法と比較して、Taprootを批判しています。Anonは、Anonの懸念の概要と複数のBitcoinコントリビューターが投稿した回答を整理するために、以下の5つの質問をまとめました。

    1. Anonは、「Taprootは、実際にMASTとschnorrを個別に使用するよりもプライベートですか？個別に使用した際、匿名性の実際の利点は何ですか？」と聞きました。

      Anthony Townsは、「はい（よりプライベートです）、single-pubkey-single-signatureが依然一般的な認証パターンであると仮定して」と回答しています。 Townsは、シングルシグでの送金が現在、すべてのトランザクション・アウトプットの57％以上を占めていることを示しています（P2SHでラップされたP2WPKHを頻繁に使用する場合、この数字はさらに大きくなる）。シングルシグを使用できる人の数は、schnorrが利用可能になった場合、増加します。これは、インタラクティブn-of-nマルチシグ、インタラクティブk-of-nしきい値署名、onchainでのシングルシグ支払いのようなアダプター署名（スクリプトレススクリプト）などの使用をシンプルにするためです。

      しかし、より多くの人々がマルチシグや高度な契約に目を向けると、ほとんどの場合単一の署名（シングルシグ）で満たすことができる実用的なユースケースが増えていますが、それでもスクリプトの使用が必要な場合があります。TaprootではなくMASTのみを使用する場合、これらのユースケースでは常にMASTを使用する必要があります。MASTはシングルシグ支出にも使用できますが、純粋なシングルシグ構造よりも大きなトランザクションとより多くのフィーが必要になるため、シングルシグユーザーはおそらくMASTを使用しないでしょう。これにより、MASTを使用する支出と使用しない支出との間のチェーン分析の明確な区分が作成されます。

      Taprootは、シングルシグを使用できてもフォールバックスクリプトも持っているユーザーが同様に見える、安価なシングルシグ支出を提供することにより、この問題を解消します（ただし、実際にはフォールバックスクリプトの使用はオンチェーンで識別できます）。これにより、単一の署名を使用することもあればスクリプトを使用することもあるグループが実際に存在する限り、MASTとschnorrを別々に実行するよりも大きな匿名性を保てます。

    2. Anonは「Taprootは、MASTとschnorrをそれぞれ実行する場合より（フィーは）安いのですか？」と聞きました。Anonは、Taprootがキーパスの支出に対してMAST + Schnorrと比較して67バイトを節約するが、スクリプトパスの支出に対して67バイトを追加すると主張しました。

      TownsはAnonの計算で冗長なデータフィールドを指摘し、Taprootが実際にスクリプトパスの支出ケースで約33バイトしか追加しないことを示しており、Taprootが優れた費用対効果分析を持つと分析を行いました。David Hardingは、余分なサイズ（8.25vbyteに変換される）は、スクリプトパスのユーザーがUTXOを使用するために提供する必要がある他のすべてのデータと比較して、非常に小さいことを言及しています。（例えば41vbyteの入力データ、16vbyteの署名またはさまざまなサイズの他のウィットネス、1つ以上の8vbyteのマークルノード、および実行するスクリプトなど）

    3. Anonは、「MASTとSchnorrを別々で利用した時と比較して、Taprootはリスクは高いですか？」と聞きました。

      Townsは「そうは思わない。複雑な暗号部分のほとんどは、MuSig、しきい値署名、アダプター署名、スクリプトレススクリプトなどのアプリケーション層にあるからです。」と答えています。また、詳細を知りたい人のためにいくつかのリソースをリンクしています。（1, 2, 3）

    4. Anonは、「[Nothing Up My Sleeve] NUMSポイント要件を無視し、それが直接ハッシュルートであるかどうかを確認できませんか？」と聞きました。これは、ウォレットがキーパスの使用を意図していないため、単なるランダムな曲線ポイントであっても、Taprootの内部キーを作成して後で公開するための要件です。Anonは要するに、支出者が内部キーの公開をスキップして、スクリプトパスの検証に直接進むことを許可することを提案しています。

      これについてTownsは、「匿名性を大幅に減らすだろう」と答えています。その理由は、存在しない内部キーは、支出時にキーパスの使用を意図していないことを明らかにし、キーパスの使用がオプションである他の支出と区別するためです。Townsはさらに、内部キーを公開しないと8vbyteしか節約できないことを言及しました。

      Jonas NickとJeremy Rubinは、それぞれ独自の分析を提供しています。 Nickは「(なぜなら)ビットコインの匿名性は永続的であり、ソフトウェアは誰もが予想するよりも長く展開される傾向があるため、現実的にはTaprootは(Anonの提案した)最適化よりも優れている」と結論づけています。Rubinは反論を提示しており、Anonの提案またはRubin自身の提案された代替案を支持しています（それでも同じ匿名性の損失には繋がります）。

    5. Anonは、「ビットコインの開発に一度に多くの機能を詰め込もうとする開発モデルはそもそもいいのか？」と聞きました。

      Townsは、「これらの特定の変更を一緒にバンドルすると、Taprootの利点が得られる」と答えました。キーパスまたはスクリプトパスの支出を使用できる柔軟性、「キーパスは、taprootを使用しない場合コストがかからないこと」、「スクリプトパスは、使用しなくてもコストがかからないこと」、「スクリプトの状態をオフチェーンでインタラクティブに検証できる場合は、常にキーパスを使用できること」を展開しました。

      これらの議論はまだ明らかな結論には達していません。その他の注目すべき開発がある場合は、今後のニュースレターで報告します。

  • ● LNでのPoDLE利用: Newsletter#83で説明されているように、LN開発者は、デュアル・ファンディング・トランザクション・チャネルおよびチャネル・スプライシングに向けたステップとして、ファンディング・トランザクションのインタラクティブな構築のためのプロトコル開発に取り組んでいます。デュアル・ファンディング・チャネル設定の問題の1つは、誰かがあなたとチャネルを開くことを提案し、UTXOの1つ以上を学習してから、トランザクションに署名してフィーを支払う前にチャネル設定プロセスを放棄できることです。この問題に対する提案された解決策は、JoinMarketが同じタイプの費用のかからないUTXO開示アタックを回避するために使用する、離散対数等価性の証明（Proof of Discrete Logarithm Equivalence またはPoDLE)）を含むチャネルオープンの提案を要求することです。

    今週、Lisa Neigutは、インタラクティブなファンディングのためのPoDLEアイデアの分析を公開しました。彼女はまた、不正なマロリーが正直なアリスがPoDLEを送信するのを待ち、それを使用して他のノードにアリスをブラックリストに入れさせる攻撃を別に説明しました。Neigutは緩和策を提案しましたが、JoinMarketの開発者Adam Gibsonにより、よりコンパクトな代替緩和策が提案されています。 Gibsonのアプローチでは、PoDLEが受信すると予想されるノードにコミットする必要があり、他のノードで悪意を持って再利用されることを防ぎます。Gibsonはまた、JoinMarketによるPoDLEの使用に関する設計上の決定事項についても説明し、LN開発者がLN独自の制約に対して異なるトレードオフを使用する方法を提案しています。

  • ● デコイ・ノードと軽量ランデブー・ルーティング: Bastien Teinturierは、BOLT11インボイスに含まれるデータと、支払いを受け取るチャネルのファンディング・トランザクションとの間のリンクの切断について以前投稿しました（Newsletter#82参照）。さらなる議論と改良の後、Teinturierは、彼のスキームの副次効果としてランデブー・ルーティングを可能にすることがあることに注目しました（受信ノードも送信ノードも互いのネット​​ワークIDについて何も学習しない、プライバシー強化の支払いルーティング）。詳細については、スキームに関するTeinturierのドキュメント、Newsletter#22のランデブー・ルーティングの以前の議論、または月曜日に開催されたLN開発者仕様会議でトピックの議論を参照してください。

Changes to services and client software

この月刊セクションでは、Bitcoinウォレットとサービスの注目すべきアップデートをお送りしています。

  • ● 署名にHWIを使用するBTCPay Vault: BTCPay Vaultは、HWIを使用してさまざまなハードウェアウォレットとの署名トランザクションを調整するデスクトップアプリケーションです。 BTCPay ServerがBTCPay Vaultを作成しましたが、このソフトウェアを他のアプリケーションで使用するために再利用することもできます。

  • ● HSMにPSBTを使用するCKBunker: CKBunkerを使用すると、ユーザーはオンラインのTor対応Coldcardハードウェアウォレットのルールベースの支出条件を構成できます。 Coldcardはその後HSM（ハードウェア・セキュリティ・モジュール）のように機能し、Torヒドゥン・サービスを介して、配信されるPSBTsに署名します。

Notable code and documentation changes

今週のBitcoin Core、C-Lightning、Eclair、LND、libsecp256k1、ビットコイン改善提案（BIP）、およびLightning BOLTの注目すべき変更点。

  • ● Bitcoin Core #18104は、Bitcoin Coreリリースプロセスの一部としてLinux用の32ビットx86バイナリのビルドのサポートを終了します。Windows用の対応する32ビットバイナリは、数か月前に以前に削除されました（Newsletter #46参照）。 32ビットLinuxバイナリは、Bitcoin Coreのコンティニュアス・インテグレーション・テスト（CIT）の一部としてまだビルドされており、ユーザーは引き続き手動でビルドできますが、実利用と開発者テストが追いついていないため、バイナリはプロジェクトによって配布されなくなりました。

  • ● C-Lightning #3488は、Bitcoinデータに対するC-Lightningのリクエストを標準化し、Bitcoin Core以外をバックエンドとしてC-Lightningを実行できるようにします。このPRは、C-Lightning #3354で提案されているように、C-LightningがBitcoinバックエンドとインタラクションする方法をより自由にするためのより大きなプロジェクトの一部です。バックエンド・インタラクションを汎用的に保つことにより、プラグインは標準のRPC呼び出しを行ったり、RPCを組み合わせてより抽象的なメソッドにしたり、通知を作成することもできます。bitcoin-cliを介したbitcoindインタラクションはデフォルトのままですが、このプロジェクトはモバイル・インテグレーションの可能性を広げる（C-Lightning #3484を参照）か、オンラインにたまにしか接続しない可能性のあるユーザー（チャネル・マネジメントやモニタリングのため）に対して、esploraインスタンスなどのブロックエクスプローラーを共有できるようにします。

  • ● C-Lightning #3500は、どちらの当事者も他方に資金を送信できないため、チャネルがスタックする可能性がある問題の、シンプルな解決策を実装します。スタックファンドの問題は 、支払いにより、チャネルに資金を提供した当事者が現在の残高よりも多くの価値を支払う責任を負う場合に発生します。たとえば、アリスはチャンネルに資金を供給し、ボブに利用可能な全残高を支払います。アリスはこれ以上お金を使うことができませんが、ボブはコミットメントトランザクションのサイズとそれに対応するフィー（資金提供者アリスが支払う責任がある手数料）を増やす必要があるため、アリスに支払うこともできません。これにより、チャネルが両方向で使用できなくなります。 C-Lightningのマージは、ユーザーが資金提供者である場合、利用可能な残高をすべて使い切ることを制限し、効果的な短期的な修正を提供します。C-Lightning #3501で代替ソリューションが提案されていますが、すべてのLN実装メンテナー間のさらなる議論の結果を待っています。

  • ● C-Lightning #3489では、複数のプラグインをhtlc_acceptedプラグイン・フックに接続できます。これにより将来、他のフックに複数のプラグインを接続できるようになる見通しです。 htlc_acceptedフックの場合、これにより、プラグインはHTLCを拒否するか、HTLCを解決する（つまり、preimageを返すことで支払いを請求する）か、HTLCをフックにバインドされた次のプラグインに渡すことができます。

  • ● C-Lightning #3477により、プラグインは、ノードのBOLT1 initメッセージ、BOLT7 node_announcementメッセージ、またはBOLT11インボイスの機能ビットフィールド（フィールド9）で送信される機能フラグを登録できます。これにより、プラグインは、ノードがアドバタイズされた機能を処理できることを他のプログラムに通知できます。

  • ● Libsecp256k1 #682は、Java Native Interface（JNI）バインディングを削除します。「JNIバインディングはJava開発者にとって有用であり続けるためにもっと作業が必要になりますが、libsecpのメンテナーと通常のコントリビューターはJavaにあまり馴染みがありません。」PRは、ACINQがプロジェクトでバインディングを使用することが知られており、ライブラリの独自のフォークを維持していることに言及しています。