今週のニュースレターでは、LNチャネルの相互クローズに関する通信を簡素化するプロトコルと、 LN開発者の最近のミーティングの要約のノートを掲載しています。また、 Bitcoin Stack Exchangeで人気のある質問と回答、新しいリリースとリリース候補の発表、 人気のBitcoinインフラストラクチャプロジェクトの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● LNクローズプロトコルの簡素化: Rusty Russellは、 2つのLNノードが共有するチャネルを相互クローズするプロセスを簡素化する提案を Lightning-Devメーリングリストに投稿しました。 新しいクローズプロトコルでは、ノードがピアにチャネルをクローズしたいことを伝え、支払うトランザクション手数料の金額を示します。 クローズ処理のイニシエーターは手数料全額を負担しますが、通常の相互クローズトランザクションの両方のアウトプットはすぐに使用可能なため、 通常どちらもCPFPによる手数料の引き上げが可能です。 新しいプロトコルは、プライバシーを強化し、オンチェーン手数料コストを低減するLNで開発中のアップグレードの一部である MuSig2ベースのスクリプトレスマルチシグ用の情報交換とも互換性があります。

    この記事の執筆時点では、Russellの提案に関するコメントは、メーリングリストに投稿されていませんでしたが、 完全な提案と一緒にいくつかの初期コメントがプルリクエストに投稿されていました。

  • ● LN Summitノート: Carla Kirk-Cohenは、 ニューヨーク市で開催された最近のLN開発者ミーティングでのいくつかの議論の概要をLightning-Devメーリングリストに投稿しました。 議論されたトピックには以下が含まれています:

    • ● 信頼性の高いトランザクション承認: パッケージリレーやv3トランザクションリレー、 エフェメラルアンカー、クラスターmempoolおよび トランザクションリレーとマイニングに関連するその他のトピックは、 LNのオンチェーントランザクションが、トランザクションのPinningの脅威や、 CPFPまたはRBFを使用した手数料の引き上げをする際の手数料の過払いなどなしに、 より信頼性の高い方法で承認されるようにするための明確な道筋をどのように提供するかという文脈で議論されました。 ほぼすべてのセカンドレイヤープロトコルに影響を与えるトランザクションリレーポリシーに関心のある読者には、 現在進行中のいくつかの取り組みについてLN開発者から提供された洞察に満ちたフィードバックのメモを読むことを強くお勧めします。

    • ● TaprootとMuSig2チャネル: P2TRアウトプットとMuSig2署名を使用するチャネルの進捗に関する簡単な議論。 この議論のメモの重要な部分は、簡素化された相互クローズプロトコルに関するもので、 その議論の結果の1つは、前のニュース項目を参照ください。

    • ● チャネルアナウンスの更新: LNゴシッププロトコルは現在、 2-of-2のOP_CHECKMULTISIGスクリプトにコミットするP2WSHアウトプットを使用して資金提供されているチャネルの場合に、 新しいまたは更新されたチャネルのアナウンスをリレーします。MuSig2ベースの スクリプトレスマルチシグコミットメントのP2TRアウトプットに移行するためには、 ゴシッププロトコルを更新する必要があります。 前回のLN開発者の対面ミーティング（ニュースレター #204参照）でも 議論されたトピックは、 P2TRアウトプットのサポートを追加するだけの最小限のプロトコルアップデート（v1.5ゴシップと呼ばれる）を行うか、 どんなタイプのUTXOの有効な署名でもアナウンスに使用することをより広範に許可する より一般的なプロトコルアップデート（v2.0と呼ばれる）を行うかということでした。 どのようなアウトプットでも使用できるようにするということは、 チャネルのアナウンスに使用されたアウトプットが、実際にチャネルを運用するために使用されるアウトプットである可能性が現在よりも低くなり、 アウトプットとチャネル資金の間の公開リンクを破壊することになります。

      追加で議論されたのは、金額 n のUTXOが n より大きなキャパシティを持つチャネルをアナウンスすることを許可するかどうかということでした。 これにより、チャネル参加者は、ファンディングトランザクションの一部を非公開にすることができます。 たとえば、アリスとボブは互いに2つの別々のチャネルを開くことができ、 1つのチャネルを使用してチャネルの金額以上のアナウンスを作成し、 UTXOに関連付けられていない、よりプライベートなもう一方のチャネルを使用して、 そのチャネルのキャパシティよりも大きいLN支払いを転送できることを明確にしました。 これにより、LNでゴシップされたことのないアウトプットであっても、 ネットワーク上のあらゆるアウトプットがLNのチャネルに使用されているという可能性を高めるのに役立ちます。

      ノートには、「任意のスクリプトの使用を許可するが、 利用可能な金額にはコミットする「v1.75ゴシップ」という妥協案が示されていました。

    • ● PTLCと冗長な過払い: ノートには、主に署名アダプターに関連して、 プロトコルへのPTLCのサポートが簡単に議論されていました。 ノートでは、プロトコルの類似部分に影響を与える改善点として、 冗長な過払いが可能なインボイスと、 過払いの大部分または全額を返金する機能について、より多くの文章が割かれていました。 たとえば、アリスが最終的にボブに1 BTCを支払いたい場合。 アリスは最初に、それぞれ0.1 BTCの20個のマルチパス支払いをボブに送信します。 数学（Boomerang と呼ばれる手法を使用、ニュースレター #86参照）か、 レイヤー化されたコミットメントと余分な通信ラウンド（Spear と呼ばれる）を使用し、ボブは最大10個分の支払いしか請求できません。 ボブのノードに到達した他の支払いはすべて拒否されます。 このアプローチのメリットは、アリスのMPPシャードの最大10個まではボブに届かなくても、遅れることなく支払いができることです。 デメリットは、余分な複雑さと、（Spearの場合）すべてのシャードがボブに到達する最良のケースよりも処理が遅くなる可能性があることです。 参加者は、冗長な過払いをサポートするための変更を、PTLCに必要な変更と同時に行うことができるかどうかについて議論しました。

    • ● チャネルジャミングの緩和提案: ノートのかなりの部分は、チャネルジャミング攻撃を緩和する提案についての議論を要約したものでした。 議論は、既知の単一の解決策（レピュテーションや前払い手数料など）は、 受け入れがたい欠点を生むことなく、それ自体で問題に満足に対処することはできないという主張から始まりました。 レピューテーション自体は、レピューテーションのない新しいノードや、自然に失敗するHTLCの割合を考慮する必要があります。 攻撃者が引き起こす被害が現在よりも少ないとしても、それでもいくらかの被害を引き起こすことができます。 前払い手数料自体は、攻撃者の意欲をそぐのに十分な金額に設定する必要がありますが、 それが高すぎると誠実なユーザーの意欲もそぎ、ノードが意図的に支払いを転送しないようにする逆のインセンティブを生む可能性があります。 代わりに、いくつかの方法を併用することで、最悪の場合のコストを発生させることなく、 メリットを得られる可能性があると提案されました。

      現時点の理解を考察した後、議論のノートでは、 ニュースレター #226で掲載されたローカルレピューテーション方式のテストと、 それに伴う低額の前払い手数料というその後の実装のためのステージ設定に関する詳細に焦点が当てられました。 ノートによると、参加者はこの提案をテストすることを支持しているようでした。

    • ● 簡略化コミットメント: 参加者は、どちらのピアもいつでも新しいコミットメントトランザクションを提案できるようにするのではなく、 どちらのピアに次のコミットメントトランザクションの変更を提案する責任があるかを定義する、 簡略化コミットメントプロトコルのアイディア（ニュースレター #120参照）について議論しました。 1つのピアに担当させることで、アリスとボブの両方が同時にHTLCを追加したい場合のような、 2つの提案がほぼ同時に送信される場合の複雑さが解消されます。 ノートで議論された特に複雑なケースは、ピアの1つが他のピアの提案を受け入れなくない場合で、 現在のプロトコルでは対処するのが複雑になります。簡略化コミットメントアプローチの欠点は、 次の変更を提案する担当でないピアが、処理を進める前に取引相手にその権限を要求する必要があるため、 場合によってはレイテンシーが増加する可能性があることです。 ノートには、この議論に対する明確な解決策は示されていませんでした。

    • ● 仕様プロセス: 参加者は、現行のBOLTやBLIP、その他のドキュメント化のアイディアを含め、 仕様化のプロセスとそれが管理するドキュメントを改善するためのさまざまなアイディアについて議論しました。 議論は多岐にわたり、ノートからは明確な結論は見られませんでした。

Bitcoin Stack Exchangeから選ばれたQ&A

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

リリースとリリース候補

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

  • ● HWI 2.3.0は、ソフトウェアウォレットがハードウェア署名デバイスと通信できるようにするこのミドルウェアのリリースです。 DIY Jadeデバイスのサポートと、MacOS 12.0以降のAppleシリコンハードウェアでhwiプログラムを実行するためのバイナリが追加されています。

  • ● LDK 0.0.116は、LN対応ソフトウェアを作成するためのこのライブラリのリリースです。 これには、アンカーアウトプットおよび、 keysendによるマルチパスペイメントのサポートが含まれています。

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

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

  • ● Bitcoin Core GUI #740では、PSBTの操作ダイアログが更新され、 自分のウォレットに支払うアウトプットが「own address」とマークされるようになりました。 これにより、インポートされたPSBTの結果、特にトランザクションが送信者にお釣りを返す場合の評価が容易になります。