今週のニュースレターでは、LND 0.9.0-betaのリリースの発表、Bitcoin Coreのリリース候補(RC)に対するテスターの公募、UTXOと未公開LNチャネル間のリンクを削除する提案の説明、eltooベースのペイメント・チャネルでの支払い管理をシンプルにすると期待されているSIGHASH_ANYPREVOUTANYSCRIPT署名ハッシュの変更に対する要約をお送りします。また、注目すべきBitcoin StackExchangeのQ＆A、主なBitcoinインフラストラクチャおよびドキュメント・プロジェクトなどの主要な変更についてもお送りします。

Action items

  • ● LND 0.9.0-betaへのアップグレード: この新しいメジャーバージョン・リリースは、アクセス制御・リストメカニズム（通称「マカロン」）の改善、マルチパス・ペイメントの受信サポート、暗号化されたオニオン・メッセージで追加データを送信する機能をもたらし（Newsletter#81参照）、ネイティブ・リバランスのサポート（Newsletter#74参照）、チャネルクローズ出力の指定されたアドレスへの支払いリクエスト機能、（例えばハードウェア・ウォレットなど、Newsletter#76参照）その他の多くの機能とバグ修正が含まれます。

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

News

  • ● UTXOと未公開チャネル間のリンクの削除: Bastien Teinturierは、未公開チャネル（LNネットワーク上、公開されていない、通常は他のユーザーの支払いをルーティングしていないチャネル）に送信される支払いのBOLT11・インボイスに追加されるデータの変更について、Lightning-Devメーリングリストに投稿しました。提案された変更により、チャネルのデポジットUTXOを識別するために使用されるインボイスから情報が削除され、1回限りのインボイスごとのキーペアと、そのキーペアから派生したシークレットに置き換えられ、オニオン暗号化ペイメントの一部としてルーティングされます。これには、支払者と未公開チャネルにルーティングできるピアの両方からの特別なサポートが必要になりますが、ルーティングパスに沿った他のノードの実装を変更する必要はありません。Teinturierは、（本提案における欠点とも言える）暗号化されたシークレットを支払いに含める必要性を排除する方法に関する提案を含め、このアイデアに対するフィードバックを求めています。

  • ● eltooによる階層化されたコミットメント: Anthony Townsは、eltooベースのLNチャネルをシンプルにできる、前回彼が出したanyprevout提案（SIGHASH_NOINPUTの派生）の変更について説明しました。現在提案されているように、eltooベースのLN実装は、支払いの一方的なクローズに含まれる遅延条件（to_self_delay）の前に、支払いのタイムアウトに伴う払い戻し(cltv_expiry_delta)を受け入れないようにする必要があります。そうでないと、受信ノードが正当に支払いを請求する十分な機会を得る前に、支払ノードが支払いを取り戻すことが出来てしまいます（アダプタ署名（「ポイントロック」）を使用してこれは行われます）。これは、タイムアウト(cltv_expiry_delta)と遅延条件（to_self_delay）を独立した形で選択できる現在のスタイルのLN払いとは異なります。

    eltooが同様のタイムアウトと遅延パラメーターの独立性を実現するために、TownsはSIGHASH_ANYPREVOUTANYSCRIPT署名ハッシュ（sighash）フラグを使用して作成された署名から入力値（sha_amounts）へのBIP341コミットメントを削除することを提案します。これには、tapscriptのOP_CODESEPARATORオペコードのバリエーションの使用など、eltooで使用されるスクリプトの変更も必要です。

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchangeはOptech Contributor達が疑問に対して答えを探しに（もしくは他のユーザーの質問に答える時間がある場合に）アクセスする、数少ない情報ソースです。この月刊セクションでは、前回アップデート以降にされた、最も票を集めた質問・答えについて共有しています。

Notable code and documentation changes

今週のBitcoin Core、 C-Lightning、Eclair、LND、 libsecp256k1、Bitcoin Improvement Proposals (BIPs)および Lightning BOLTsの注目すべき変更点。

  • ● Bitcoin Core #17492を使用すると、ユーザーがウォッチ・オンリーウォレットで、トランザクションをフィー・バンプしようとすると、Bitcoin Core GUIが部分署名ビットコイン・トランザクション（PSBT）をクリップボードに配置します。ユーザーは、署名のためにPSBTを別のプログラム（HWIなど）に貼り付けることができます。

  • ● C-Lightning #3376は、支払者と受信者のブロックの高さが一致しない場合、リトライによりこの事象を解消する処理します。実装を簡素化するために仕様を変更する必要があるかどうかについては、PRで議論されていますが、この状況につながった仕様の変更によりプライバシーリークが解消されることが指摘されています。

  • ● LND #3809は、BumpFee RPCにforceパラメーターを追加して、作成するトランザクションに「非経済的なUTXO」を含めることができるようにし、Newsletter #79で説明されている変更を拡張します。「非経済的なUTXO」は、そのものの価値（アマウント）よりも送付に多くのフィーがかかるUTXOです。提案されたアンカー・アウトプットのフィー・バンピング方法がLNプロトコルに採用された場合、LNDがこの方法を使用できることが重要となります。

  • ● BIPs #875は、BIP119をOP_CHECKTEMPLATEVERIFY提案に割り当てます。提案が採用されると、ユーザーは特定のトランザクションまたは一連のトランザクションでのみ使用できるUTXOを作成でき、一種の契約(covenants)を提供します。これは、支払いを一時的にオフチェーンに保つが、支払い先のアウトプットを取り消したり変更する方法がない（不可能である）ことを最終的な受信者に対して保証する必要があるプロトコルで役立ちます。

  • ● BIPs #876は、schnorr-taproot-tapscript提案の各部分に1つずつ、3つのBIPを割り当てます。

    • ● BIP340は、「secp256k1のSchnorr署名」に割り当てられます。これは、ビットコインが使用するsecp256k1楕円曲線と互換性のある署名スキームを記述しています。署名は、バッチ検証と、MuSigなどのキーおよび署名集約スキームと互換性があります。Schnorr署名は、次の2つのBIP（341および342）で使用できます。詳細については、BIPまたはschnorr署名を参照してください。

    • ● BIP341は、「Taproot: SegWitバージョン1の支払いルール」に割り当てられます。これは、ユーザーがschnorrスタイルの署名、もしくはマークル・ツリーを介した特定のスクリプト（スクリプトの条件も満たされたとして）へのキーのコミット証明を利用して支払える、schnorrスタイルの公開キーを含むソフトフォーク提案の一部を説明します。詳細については、BIPまたはtaprootを参照してください。

    • ● BIP342は、「Taprootスクリプトの検証」に割り当てられます。これは、taproot（tapscript）と組み合わせて使用​​されるスクリプトを評価するためのルールを記述しています。tapscriptのほとんどすべての操作は、従来のBitcoin Scriptと同じですが、いくつかは異なる点があります。tapscriptにアップグレードする既存のユーザーにとって最も重要な変更点は、すべての署名チェックのオペコード（OP_CHECKSIGなど）がschnorr公開キーと署名を使用することです。また、注目に値するのは、OP_CHECKMULTISIGが削除されたことです。スクリプト作成者は、代わりに新しいOP_CHECKSIGADDオペコードを使用するか、スクリプトを再設計することで対応します。他のいくつかの新しいルールは、ユーザーには影響を与えません。さらに、tapscriptには、将来のソフトフォークアップグレードを容易にするための新機能がいくつか含まれています。詳細については、BIPまたはtapscriptを参照してください。

    BIPリポジトリへの多くのマージには、複数の人々からのコントリビューションが含まれますが、このマージにはこれまで見た中で最も多くの貢献者がいました：163件のコミットで28人の異なる人々からのコンテンツと編集が含まれ、ここに含まれない他の貢献者、このリポジトリを可能にした基礎を作り出した開発者、および多くの「構造化されたレビューの参加者」に感謝します。

  • ● BOLTs #697は、BOLT4で説明されているsphinxパケットの構造を変更して、宛先ノードがソースノードに戻るパスの長さを発見できるプライバシーリークを修正します。リークの詳細については、Newsletter #72を参照してください。Optechが追っている3つの実装すべて（C-Lightning、Eclair、およびLND-Onionライブラリ）もリークを修正するためにコードを更新しました。

  • ● BOLTs #705は、実験的でアプリケーション固有のメッセージにBOLT1メッセージタイプ32768–65535を割り当てます。また、コンフリクトを防ぐために、この範囲内で自分自身にメッセージタイプを割り当てる人について使用している番号をBOLT #716に投稿するよう要求するなど、実装者向けのガイドラインも提案しています。