今週のニュースレターでは、古いバックアップ状態に対するFraud Proofについて掲載しています。 また、サービスやクライアントソフトウェアの最近の変更や、新しいリリースとリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更など恒例のセクションも含まれています。

ニュース

  • ● 古いバックアップ状態のFraud Proof: Thomas Voegtlinは、 最新バージョン以外の状態のバックアップをユーザーに提供した場合にペナルティを受けるサービスのアイディアを Lightning-Devメーリングリストに投稿しました。 基本的な仕組みはシンプルで:

    • アリスはバックアップしたいデータを持っています。データにはバージョン番号が含まれており、 データに対する署名を作成し、ボブにデータと署名を渡します。

    • ボブは、アリスのデータを受け取った直後に、データのバージョン番号と現在時刻の両方にコミットする署名をアリスに送信します。

    • その後、アリスはデータを更新し、バージョン番号をインクリメントし、 ボブに更新したデータとそのデータに対する署名を提供します。ボブは、 新しい（より高い）バージョン番号と新しい（より高い）現在時刻にコミットした署名を返します。 両者はこのステップを何度も繰り返します。

    • 最終的に、アリスはボブをテストするために自分のデータを要求します。 ボブは、データのバージョンとそのデータに対する彼女の署名を送り、 それが実際に彼女のデータであることを証明することができます。 ボブはまた、データのバージョン番号と現在時刻にコミットした署名も送ります。

    • もしボブが不正をして、古いバージョン番号の古いデータをアリスに送った場合、 アリスは、Fraud Proof を生成することができます。つまり、 ボブが以前、ボブが提供した署名コミットメントよりも前の時間により高いバージョン番号に署名したことを示すことができます。

    ここまでの説明で、最新状態のFraud Proofを生成するこの仕組みには、Bitcoin特有のものはありません。 しかし、Voegtlinは、ソフトフォークでOP_CHECKSIGFROMSTACK (CSFS)とOP_CAT opcodeが Bitcoinに追加された場合、このFraud Proofをオンチェーンで使用することが可能になると指摘しています。

    たとえば、アリスとボブは、アリスがこの種のFraud Proofを提供できれば、 アリスがチャネルの資金をすべて使用できるという追加のtaprootの条件を含むLNチャネルを共有します。 チャネルの通常の動作に追加のステップが加わります。つまり、チャネルを更新するたびに、 アリスはボブに現在の状態（状態番号を含む）に対する署名を渡します。 その後、アリスはボブと自然に再接続するたびに、最新のバックアップを要求し、 上記の仕組みを使用してその整合性を検証します。ボブが古いバックアップを提供した場合、 アリスはFraud ProofとCSFSの使用条件を使ってチャネルの全残高を使用することができます。

    この仕組みは、アリスが実際にデータを失った場合に、 ボブから提供された状態を最新のチャネルの状態として使用することが安全になるようにします。 現在のLNのチャネル設計（LN-Penalty）では、ボブがアリスを騙してアリスに古い状態を使用させると、 ボブはチャネル内の彼女の全残高を盗むことができます。 LN-Symmetryのような提案されているアップグレードを使用しても、 アリスが古い状態を使用すると、ボブは彼女から資金を盗むことができる可能性があります。 最新の状態を偽ったボブに対して金銭的なペナルティを科すことが可能になれば、 ボブがアリスに嘘をつく可能性は低くなるでしょう。

    この提案には多くの議論がありました:

    • ● Peter Toddは、基本的な仕組みは一般的なものであると指摘しました。 これはLN特有のものではなく、さまざまなプロトコルで有用である可能性があります。 彼はまた、アリスがボブと自然に再接続するたびに、Fraud Proofを必要とせず ボブから最新の状態をダウンロードするだけのより単純な仕組みも指摘しました。 もし、ボブが古い状態を提供した場合、アリスはボブとのチャネルを閉じ、彼が将来の支払いから得る転送手数料を拒否します。 これは、BOLTs #881で定義されたピア・ストレージや、 今年初旬にCore Lightningで実験的に実装されたバージョン（ニュースレター #238参照）、 （Bastien Teinturierのメッセージによると） LN用のPhoenixウォレットで実装された方式のバージョンと非常によく似ています。

    • ● ghost43による返信では、金銭的なペナルティにつながるFraud Proofは、 匿名のピアとデータを保存するクライアントにとって強力なツールであると説明されました。 大手の人気サービスであれば、クライアントに嘘をつくのを避けるために評判を気にするかもしれませんが、 匿名のピアには失う評判はありません。また、ghost43によって提案されたのはプロトコルを対称的に修正することで、 アリスがボブとの間で彼女の状態を保存する（そしてボブが嘘をついた場合にペナルティを受ける）のに加えて、 ボブはアリスとの間で彼の状態を保存してもらい、アリスが嘘をついた場合にペナルティを受けさせることができるというものです。

      Voegtlinは、このアイディアを広げ、ウォレットソフトウェアのプロバイダーには良い評判が非常に重要で、 ソフトウェアが可能な限り最高に機能していたとしても、ユーザーが資金を失った場合には評判が失われると警告しました。 したがって、ウォレットソフトウェアの開発者として、ピア・バックアップのような仕組みを使っているElectrumユーザーから 匿名のピアによって盗まれるリスクを最小限に抑えることは彼にとって重要なことです。

    議論に対する明確な解決策はありませんでした。

サービスとクライアントソフトウェアの変更

この毎月の特集では、Bitcoinのウォレットやサービスの興味深いアップデートを取り上げています。

  • ● Scaling Lightningのフィードバックの募集: Scaling Lightningは、regtestおよびsignet上のライトニングネットワークのテストツールキットです。 このプロジェクトは、さまざまな構成とシナリオで異なるLN実装をテストするためのツールを提供することを目的としています。 このプロジェクトは、コミュニティに向けに最近のアップデート動画を提供しました。 LN開発者や研究者およびインフラ運用者は、フィードバックを提供することが推奨されます。

  • ● Torq v1.0リリース: エンタープライズユーザーを対象としたLNノード管理ソフトウェアTorqは、 LSP（Lightning Service Provider）機能や、自動化ワークフロー、大規模ノード運用者向けの高度な機能を含む v1.0のリリースを発表しました。

  • ● Blixt Wallet v0.6.8リリース: v0.6.8のリリースには、HOLDインボイスや ゼロ承認チャネルのサポート、その他の改善が含まれています。

  • ● Sparrow 1.7.8リリース: Sparrow 1.7.8は、P2TRアドレスを含むBIP322のメッセージ署名のサポートが追加され、 RBFおよびCPFPによる手数料引き上げ機能にさまざまな改善が加えられています。

  • ● オープンソースのASICマイナーbitaxeUltraのプロトタイプ: bitaxeUltraは、既存の商用マイニングハードウェアをベースにした ASIC（Application-Specific Integrated Circuit）を使用するオープンソースマイナーです。

  • ● FROSTソフトウェアFrostsnapの発表: チームは、実験的なFROST実装であるsecp256kfunを使用して、 FROST閾値署名方式を構築するというビジョンを発表しました。

  • ● Libflorestaライブラリの発表: Utreexoを搭載したFlorestaノードに関する以前の研究を基に構築された Libflorestaは、UtreexoベースのBitcoinノード機能をアプリケーションに追加するためのRustライブラリです。

  • ● Wasabi Wallet 2.0.4リリース: Wasabi 2.0.4は、RBFまたはCPFPによる手数料引き上げ機能の追加、 Coinjoinの改善、ウォレットロード処理の高速化、RPCの機能強化、その他の改善とバグ修正が含まれています。

リリースとリリース候補

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

  • ● Core Lightning 23.08rc3は、この人気のLNノード実装の次期メジャーバージョンのリリース候補です。

  • ● HWI 2.3.1は、ハードウェア署名デバイスを扱うためのこのツールキットのマイナーリリースです。

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

今週の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 #27981は、２つのノードが互いにデータを受信できなくなる可能性があったバグを修正しました。 アリスのノードがボブのノードに送信するためにキューに入れられた多くのデータを持っている場合、 アリスのノードはボブから新しいデータを受け入れる前にそのデータを送信しようとします。 もし、ボブのノードもアリスのノードに送信するためにキューに入れられた多くのデータを持っている場合、 ボブのノードもアリスから新しいデータを受け入れることはないでしょう。 このため、どちらも相手からデータをいつまでも受け取ろうとしない可能性があります。 この問題は、もともとElements Projectで発見されました。

  • ● BOLTs #919では、LNの仕様が更新され、ある金額を超えるトリムされるHTLCを受け付けなくなりました。 トリムされるHTLCは、チャネルのコミットメントトランザクションにアウトプットとして追加されない転送可能な支払いです。 代わりに、トリムされるHTLCの金額と同額の金額がトランザクション手数料に割り当てられます。 これにより、オンチェーンで経済的でない支払いをLNを使用して転送することが可能になります。 しかし、トリムされるHTLCが保留中のままチャネルを閉じる必要がある場合、 ノードはその資金を回収する方法がないため、その種の損失に対するノードのエクスポージャーを制限するのは理にかなっています。 この制限を追加するさまざまな実装については、 LDKはニュースレター #162を、Eclairはニュースレター #171を、 Core Lightningはニュースレター #173を、 また関連するセキュリティ上の懸念についてはニュースレター #170をご覧ください。

  • ● Rust Bitcoin #1990は、オプションでbitcoin_hashesをSHA256、 SHA512および約半分のサイズのRIPEMD160のより遅い実装でコンパイルできるようにしました。 これは頻繁にハッシュ計算を行う必要のない組み込みデバイス上のアプリケーションに適しています。

  • ● Rust Bitcoin #1962は、互換性のあるx86アーキテクチャ上でハードウェアに最適化されたSHA256演算を使用する機能を追加しました。

  • ● BIPs #1485では、DrivechainのBIP300の仕様が更新されました。 主な変更は、特定の文脈におけるOP_NOP5をOP_DRIVECHAINに再定義したことです。