今週のニュースレターでは、PSBTをデコード・変更するための新しいWebベースのツールと、 eltooベースのLNのペイメントチャネルの概念実証の実装およびブログ記事のリンクを掲載しています。 また、Taprootの準備や新しいソフトウェアのリリース候補の発表、 人気のあるBitcoinインフラストラクチャプロジェクトの注目すべき変更点の要約など、 恒例のセクションも含まれています。

ニュース

  • ● BIP174.org: Alekos Filiniは、 彼とDaniela Brozzoniが作成したPSBTを人が読める形式のリストにデコードする ウェブサイトについてBitcoin-Devメーリングリストに投稿しました。 フィールドの内容を編集し、シリアライズされたPSBTに再エンコードすることができ、 これにより開発者はBIP174実装のテストを素早く作成することができます。 Christopher Allenは、このツールがQRコード（標準的なQRコードコード、 または3KB以上のPSBTを扱うための代替 ニュースレター #96参照） の作成にも対応するよう提案しました。

  • ● eltooのチャネル例: Richard Myersは以前、 AJ TownsのSIGHASH_ANYPREVOUTの実装をベースに、 Bitcoin Coreの結合テストを使ってeltooチャネルの例を実装しました（ニュースレター #63参照）。 Bitcoin-Devメーリングリストで言及されているように、 彼は現在eltooチャネルが使用できるトランザクションを説明する詳細なブログ記事を書いています。 彼の結合テストと組み合わせて、eltooに興味ある人は誰でもそれを試すことができます。 また、今後の研究に興味ある人のためにeltooの改善点についても解説されています。

Taprootの準備 #11: LNとTaproot

ブロック高709,632のTaprootのアクティベーションに向けて、 開発者やサービスプロバイダーがどのような準備をすればよいかについての週刊シリーズです。

LNプロトコル開発者ZmnSCPxjの寄稿

この投稿では、TaprootがLNで可能にする2つのプライバシー機能について説明します:

  • LN上のPTLC
  • P2TRチャネル

LN上のPTLC

PTLCは多くの機能を可能にしますが、 LNにとっての主な機能は、経路をランダム化することなく支払いを非相関化する機能です。1 シングルパスやマルチパスの経路に沿ったすべてのノードに、 転送される各PTLCを調整するために使用されるスカラーを与えることができ、 個々の転送が各LN支払い用の一意な識別子を漏らすことのない支払いの非相関化を可能にします。

PTLCはプライバシーの万能薬ではありません。 監視ノードが特定のタイムロックと量を持つ転送を発見し、 その直後に2つめの監視ノードがより小さなタイムロックと僅かに少ない量を持つ転送を発見した場合、 たとえ監視ノードが一意に識別可能なハッシュを介してそれらを相関させることができなくなったとしても、 これらの転送が同じ支払いのパスに属する可能性は非常に高いです。しかし、得るものはあります:

  • 分析の不確実性が増します。監視者が扱うことのできる確率が低くなり、情報の価値ははるかに低くなります。
  • マルチパス支払いでは、より多くの非相関化が行われます。 個別のパスには、それぞれタイムロックや量に強い相関関係はないでしょうし、 LNが成功すれば、タイミングの相関関係も信頼できないほど十分な支払いがあるでしょう。
  • HTLCと比較してコストは増加しません （マルチシグの効率化により、わずかにコストが減少する可能性もあります）。

原則として、Taproot前のチャネルは、チャネルを閉じて再度開くことなく、 PTLCをサポートするようアップグレードすることができます。 既存のチャネルは、既存の非Taprootのファンディング・アウトプットを PTLCを含むTaprootアウトプットへ送信するオフチェーントランザクションを作成することで、PTLCをホストすることができます。 つまり、LN上でPTLCのサポートを追加しても、 各ノードとそのチャネルピアがソフトウェアをアップグレードする以上のコストがユーザーにかかることはないということです。

しかし、PTLCを実際に使用するためには、送信者から受信者までのすべての転送ノードがPTLCをサポートする必要があります。 つまり、十分な数のノードがアップグレードするまで、PTLCのサポートはほとんど使われない可能性があります。 すべてのノードが同じプロトコルを使用する必要はありませんが（複数のPTLCプロトコルが存在する可能性があります）、 すべてのノードが何らかのPTLCプロトコルをサポートする必要があります。 複数のPTLCプロトコルをサポートすることになると、メンテナンスの負担が増えるため、 そのようなプロトコルが多くならないことを願っています（理想的には１つだけ）。

P2TRチャネル

ベースレイヤーとLNレイヤー間の非相関化を改善するための1つのソリューションは、 LN上でその存在がゴシップされないチャネルである非公開チャネルでした。

残念ながら、すべてのLNチャネルは2人の署名者の協力を必要とし、現在のTaproot前のBitcoinでは、 すべての2-of-2のScriptがオープンにコーディングされています。 LNは2-of-2マルチシグの最も一般的なユーザーであるため、ブロックチェーンエクスプローラであれば、 これが閉じられたLNチャネルであることを示すことができます。 そこから資金を辿ることができ、それが別のP2WSHアウトプットに向かっていれば、 それは別の非公開チャネルである可能性が高くなります。 このように、非公開チャネルであっても、ある程度の誤検出はあるものの、閉じるとオンチェーンで特定することができます。

Taprootは、Schnorr署名を使用することで、 n-of-nを1-of-1と全く同じように見せることができます。 少し工夫すれば、k-of-nでも1-of-1（およびn-of-n）と同じように見えます。 そして、LNチャネルがP2TR UTXO、つまりP2TRチャネルを使うことで、 非公開チャネルのオンチェーンプライバシーを向上させることができます。2

この（かなり小さな）プライバシーの向上は、公開チャネルにも役立ちます。 公開チャネルは、公開されている間だけゴシップされるので、 公開チャネルを探そうとしても、過去のチャネルについて知ることはできません。 監視者がすべての公開チャネルを確認したい場合、そのデータをすべて自身で保持しなければならず、 アーカイブノードに頼ることはできません。

さらに、Taprootのkeypathによる使用は、LNの既存のP2WSHの使用に比べて38.5 vbyte (40%)小さくなります。 残念ながら、既存のTaproot前のチャネルをP2TRチャネルにアップグレードすることはできません。 既存のチャネルは、既存のP2WSH 2-of-2スキームを使用しており、 P2TRチャネルに切り替えるにはチャネルを閉じなければなりません。

理論的には、実際のファンディング・トランザクションのアウトポイントは、 チャネルを使用する2つのノードにのみ関係します。 ネットワーク上の他のノードは、2つのノード間のチャネルのセキュリティには関心がありません。 しかし、公開チャネルはLNのゴシップネットワーク上で共有されます。 ノードがゴシップされた公開チャネルを受信すると、ノードは自身の信頼できるBitcoinフルノードを参照し、 ファンディングのアウトポイントが存在するか、さらに重要なことに正しいアドレスを持っているかを確認します。 アドレスを確認することで、チャネルゴシップの仕組みをスパムするのが困難になります。 チャネルゴシップを送信するためには、実際にブロックチェーン上に資金が必要です。 したがって、実際には、P2TRチャネルであってもある程度のリモート互換性が必要です。 そうでなければ、送信者はこれらのチャネルが存在することを検証できないため、 これらのチャネルを無視してルーティングを行います。

タイムフレーム

分散型FOSSプロジェクトで機能のタイムフレームを作るには、過去の機能とそれにかかった時間を調べ、 それらの機能を実際に展開するのにかかる時間を基準にするのが、最良の方法だと思います。3

最近の新機能の中で、LNを介したPTLCとスコープが似ていると思うのはデュアル・ファンディングです。 Lisa NeigutがBOLTs #524でデュアル・ファンディングの最初の提案をし、 その約2年6ヶ月後にmainnetで最初のデュアル・ファンディングチャネルが開設されました。 デュアル・ファンディングに必要なのは、直接のピアとの互換性だけです。 LN上のPTLCは、受信者を含む選択した経路上のルーティングノードとの互換性を必要とします。 そのため、この機能には追加の複雑さを理由に+50%の時間補正をするのが妥当だと考えており、 具体的なPTLCプロトコルが提案されてから、3年9ヶ月を目安にしています。

P2TRチャネルについては、これは2つの直接のピア間のみの話で、利点も少ないことに注意してください。 そのため優先度は低くなると思います。ほとんどの開発者がPTLC-over-LNを優先すると仮定すると、 P2TRチャネルは、基礎となるSIGHASH_ANYPREVOUTや、 Decker-Russell-Osuntokun(“Eltoo“)を実装する他の方法が利用可能になる頃には、 作業が開始されると予想されます。

リリースとリリース候補

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

  • ● Bitcoin Core 22.0rc3は、 このフルノード実装とそれに付随するウォレットおよび他のソフトウェアの次のメジャーバージョンのリリース候補です。 この新バージョンの主な変更点は、I2P接続のサポート、 Tor v2接続の廃止、ハードウェアウォレットのサポートの強化などです。

  • ● Bitcoin Core 0.21.2rc2は、 Bitcoin Coreのメンテナンス版のリリース候補です。

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

今週の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 GUI #384では、 禁止されたピアテーブルのピアのIP/ネットマスクをコピーするコンテキストメニューオプションが追加されました。 これにより、GUIユーザーは禁止リストから個々のアドレスをより簡単に共有できるようになります。

    Screenshot of GUI Copy IP/Netmask Context Menu Option

  • ● C-Lightning #4674では、PluginがC-Lightningデータベースにデータを保存・管理するための datastore、deldatastore、listdatastoreコマンドが追加されました。 また各コマンドのセマンティクスを詳細に説明したマニュアルページも含まれています。

  • ● LND #5410では、ノードがTorの背後で実行されていないサービスへの直接接続を確立し、 ネットワークのTorのみのセグメントとクリアネットのみのセグメントをブリッジできるようになりました。

  • ● LND #5621では、Pingメッセージのignoredフィールドの一部として、 最も作業されているブロックのブロックヘッダを含むようになりました。 ピアノードはこの情報を、ブロックチェーンのビューが最新であり、 Bitcoinネットワークから排除されていないことを確認するための追加チェックとして使用できます。 将来的には、このデータソースを使用して、ユーザーに警告したり、リカバリーのためのアクションを自動的に取ることができます。

脚注

  1. 支払者は、HTLCの相関分析を誤らせるために、 非常に複雑なパス（つなり経路のランダム化）を選択することができますが、 それには欠点があります:

    • 複雑なパスは、コストがかかり、かつ信頼性も低いものになります （より多くのノードに支払いを行い、支払いが宛先に到達するためには より多くのノードが転送に成功する必要があります）。
    • 複雑なパスは長いので、支払者は支払いについてより多くのノードに伝えることになり、 監視ノードに当たる可能性が高くなります。 このように複雑なパスは、必ずしもプライバシーを完全に改善するものではありません。

    ↩

  2. 非公開チャネルを検討する際には、タンゴを踊るには二人必要なことを思い出してください。 非公開チャネルを閉じる場合、もう1人の参加者（例えばLNサービスプロバイダー）が残りの資金を公開チャネルに使用した場合、 ブロックチェーンエクスプローラは、資金のソースが閉鎖された非公開チャネルであった可能性をある程度推測できます。 ↩

  3. 確かに詳細は重要ですが、それだけではありません。高い視点から見ると、 開発のある側面での予期せぬ困難と、開発の他の側面での予期せぬ非困難は相殺され、 すべての主要な機能は、ある平均的なタイムフレームにほぼ沿っていることになります。 感覚的な見積もりではなく、正確な見積もりをしたいのであれば、 計画錯誤を避ける方法を使うべきです つまり、過去に完成した似たような機能を探し、その詳細をわざと無視して、 その機能の実装にかかった時間だけを見るのです。 ↩