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

Bitcoin Optech Newsletter #220

Oct 5, 2022

今週のニュースレターでは、新しいオプトイン型のトランザクションリレールールの提案と、 LNチャネルのバランスを保つための研究の要約を掲載しています。また、新しいソフトウェアリリースおよびリリース候補のリストや、人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更など、恒例のセクションも含まれています。

ニュース

● LNのペナルティ用に設計された新しいトランザクションリレーポリシーの提案: Gloria Zhaoは、トランザクションにオプトインで、トランザクションリレーポリシーのセットの変更を可能にする提案を、Bitcoin-Devメーリングリストに投稿しました。バージョンパラメータに3をセットしたトランザクションは以下のようになります:
- ● より高い手数料率と総手数料を支払うトランザクションによって未承認のトランザクションは置換できる（現在の主なRBFルール）
- そのトランザクションが未承認である限り、その子孫のトランザクションもすべてv3トランザクションであることを要求する。このルールに違反する子孫は、デフォルトでリレー、マイニングされない。
- v3の未承認の祖先が既に他の子孫をmempoolに持っている（もしくは、このトランザクションがパッケージにある）場合は、拒否される。
- 未承認のv3の祖先を持つ場合、1,000バイト以下であることをが要求される。
この提案されたルールに付随して、以前提案されたパッケージリレールール（ニュースレター #167参照）が簡略化されました。

v3リレールールと更新されたパッケージリレールールは、 LNのコミットメントトランザクションが最小限の手数料（場合によっては手数料ゼロ）で、子トランザクションによって実際の手数料が支払われ、かつPinning攻撃を防止するよう設計されています。ほぼ全てのLNノードは既にこのような仕組みアンカー・アウトプットを使用していますが、提案されているアップグレードにより、コミットメントトランザクションの承認がよりシンプルで堅牢なものになるはずです。

Greg Sandersは、2つの提案を返信しました:
- ● 一時的なdust: ゼロ値（もしくは経済的合理性のない値）のアウトプットに支払いをするトランザクションは、そのトランザクションがdustアウトプットを使用するパッケージの一部である場合、 dustポリシーが免除されるべきるである。
- ● 標準OP_TRUE: OP_TRUEのみで構成されるアウトプットに支払いをするトランザクションはデフォルトでリレーされるべきである。そのようなアウトプットは、誰もが使用でき、セキュリティはない。 LNチャネルのいずれかの参加者（もしくは第三者）が、そのOP_TRUEアウトプットを使用するトランザクションによる手数料の引き上げを容易にする。 OP_TRUEアウトプットを使用するのにスタックに入れるデータは必要ないため、コスト効率よく使用できる。
これらのいずれも、v3トランザクションのリレーの実装と同時に行う必要はありませんが、スレッドの回答者の中には、提案されたすべての変更に賛成している人もいるようです。
● LNのフロー制御: Rene Pickhardtは、フロー制御のバルブとしてhtlc_maximum_msatを使用することについて行った最近の研究の概要を Lightning-Devメーリングリストに投稿しました。 BOLT7で以前定義されたように、htlc_maximum_msatは、ノードが個々の支払いパーツ（HTLC）で、特定のチャネルで次のホップに転送する最大額です。 Pickhardtは、一方向に他方より多くの金額が流れ、最終的にその方向に流れる資金がなくなるチャネルが多いという問題に対処します。彼は、過度に使用される方向の最大値を制限することで、チャネルのバランスを保つことができると提案しています。たとえば、あるチャネルが、最初はどちらかの方向に1,000 satの送金を許可していた場合、バランスが悪くなると、使いすぎた方向の１回の送金額の上限を800 satに下げてみるのです。 Pickhardtの研究は、実際に適切なhtlc_maximum_msatの値を計算するのに使用できるいくつかのコードスニペットを提供しています。

またPickhardtは別のメールで、以前の手数料レートカードのアイディア（先週のニュースレター参照）が代わりに、 転送毎の最大金額レートカードになる可能性を示唆しています。少額の支払いには低い手数料率が、高額の支払いには高い手数料が課されます。元のレートカードの提案とは異なり、それらは絶対額で、チャネルの現在の残高に対する相対的なものではありません。 Anthony Townsは、htlc_maximum_msatの調整に基づくフロー制御では問題にならない、元のレートカードのいくつかの課題について説明しました。

ZmnSCPxjは、このアイディアのいくつかの面を批判し、支払人は最大レートの低いチャネルを介して同じ量の金額を送ることができ、全体の支払いをさらに小さなパーツに分割することで、再びバランスが取れなくなることを指摘しました。 Townsは、レート制限によってこれに対処できる可能性があることを示唆しました。

この要約が書かれた時点では、この議論は継続中のようですが、ノートオペレーターが各チャネルのhtlc_maximum_msatパラメーターを使って実験し始めると、今後数週間から数ヶ月の間に、いくつかの新しい洞察が得られると予想されます。

リリースとリリース候補

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

● Bitcoin Core 24.0 RC1は、ネットワークで最も広く使われているフルノード実装の次期バージョンの最初のリリース候補です。テストのガイドが利用できるようになっています。

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

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

● Eclair #2435は、トランポリンリレー使用時の、 非同期支払いの基本形式のオプションサポートを追加しました。ニュースレター #171に掲載したように、非同期支払いにより、資金を持つ第三者を信頼することなくオフラインノード（モバイルウォレットのような）への支払いを可能にするでしょう。非同期支払いの理想的な仕組みはPTLCに依存しますが、部分的な実装はオフラインノードがオンラインになるまで資金の転送を遅らせるだけで済みます。トランポリンノードは、その遅延を提供できるため、このPRはそれらを利用した非同期支払いの実験を可能にします。
● BOLTs #962は、元の固定長のOnionデータフォーマットのサポートを仕様から削除しました。アップグレードされた可変長のフォーマットは、3年以上前に仕様に追加され、コミットメッセージで言及されているテスト結果では、古いフォーマットを使用している人はほとんどいないことを示しています。
● BIPs #1370は、現在提案中の実装を反映するためにBIP330（reconciliationベースのトランザクション通知Erlay）を改訂しました。変更点は次のとおりです:
- トランザクションIDを削除し、トランザクションのWTXIDを使用するようになりました。これは、ノードが既存のinvおよびgetdataメッセージを使用できることを意味し、 invtxおよびgettxメッセージが削除されました。
- sendreconがsendtxrcnclに、reqreconcilがreqreconに、reqbisecがreqsketchtextにリネームされました。
- sendtxrcnclを使用したネゴシエーションのサポートの詳細が追加されました。
● BIPs #1367は、BIP 340と341を参照することで、可能な限りBIP118のSIGHASH_ANYPREVOUTの記述を簡略化しました。
● BIPs #1349は、BIP47とSilent Paymentに触発された暗号プロトコルを定義した「Private Payment」というタイトルのBIP351を追加しました。このBIPは、新しいPayment Code形式を導入し、参加者が公開鍵の次にサポートされるアウトプットタイプを指定します。 BIP47と同様に、送信者は通知トランザクションを使用して、受信者のPayment Codeに基いて受信者との共有シークレットを確立します。送信者は、受信者が使用時に通知トランザクションの情報から得られる共有シークレットから導出可能な一意のアドレスに複数の支払いを送信できます。 BIP47では、複数の送信者が受信者毎に同じ通知アドレスを再利用していましたが、この提案では、検索キーPPと送信者と受信者のペア固有の通知コードでラベル付されたOP_RETURNアウトプットを使用して、受信者の注意を引き、プライバシーを改善するための共有シークレットを確立します。
● BIPs #1293は、”Pay-to-contract tweak fields for PSBT”というタイトルのBIP372を追加しました。このBIPは、Pay-to-Contractプロトコルに参加するために必要なコントラクトのコミットメントデータ（ニュースレター #184参照）を署名デバイスに提供する追加のPSBTフィールドを含めるための標準を提案しています。
● BIPs #1364は、DrivechainのBIP300の仕様に、さらなる詳細を追加しています。また、Drivechainのブラインドマージマイニングルールを適用するBIP301の関連仕様も更新されています。