今週のニュースレターでは、Bitcoinで汎用的なスマートコントラクトを可能にする提案と、 LNのチャネルジャミング攻撃への対処に関する論文を掲載しています。 また、サービスやクライアントソフトウェアの変更や、新しいリリースおよびリリース候補の発表、 人気のあるBitcoinインフラストラクチャソフトウェアの注目すべき変更を含む 恒例のセクションも含まれています。

ニュース

  • ● CovenantによるBitcoinの汎用的なスマートコントラクト: Salvatore Ingalaは、 マークルツリーを使用して、 あるオンチェーントランザクションから別のトランザクションに状態を遷移させることができる スマートコントラクトの作成を可能にする新しいタイプのCovenantの提案（ソフトフォークを必要とする）を Bitcoin-Devメーリングリストに投稿しました。 Ingalaの投稿の例では、2人のユーザーがチェスのゲームで賭けをし、 コントラクトにゲームのルールを保持し、ボード上のすべての駒の位置を状態として保持し、 各オンチェーントランザクションでその状態を更新することができるようになります。 もちろん、よく設計されたコントラクトであれば、ゲーム終了時の決済トランザクションのみをオンチェーンにし、 オフチェーンでゲームを行うことができます（ペイメントチャネルなど、別のオフチェーン構成でゲームが行われた場合、 オフチェーンのままでも可能）。

    Ingalaは、この研究がJoinpoolやOptimistic rollup（ニュースレター #222参照）、 その他のステートフルな構成の設計にどのように役立つか説明しています。

  • ● チャネルジャミング攻撃に関する論文: Clara ShikhelmanとSergei Tikhomirovは、 チャネルジャミング攻撃の解決策について書いた論文を Lightning-Devメーリングリストに投稿しました。 2015年に初めて報告されたこの攻撃は、攻撃者にとってごくわずかなコストで、 大量のチャネルを長期間使用不能にすることができます。

    著者らは、ジャミング攻撃を2つのタイプに分類しています。 1つは、チャネルの限られたスロットや支払い転送用の資金を長期間使用できなくするスロー・ジャミングで、 正当な支払いではほとんど発生しません。もう1つは、スロットや資金が短時間だけブロックされるファスト・ジャミングで、 これは通常の支払いで頻繁に発生し、ファスト・ジャミングを緩和するのは難しいかもしれません。

    彼らは2つの解決策を提案しています:

    • ● 無条件の手数料： （以前のニュースレターに掲載した前払い手数料と同じで） 支払いが受信者まで届かなかった場合でも、転送ノードにいくらかの手数料が支払われるというものです。 著者らは、支払額に依存しない基本前払い手数料と、支払額に応じて増加する比例前払い手数料の両方を提案しています。 2つの別々の手数料は、HTLCスロットへの妨害と流動性への妨害に対処するものです。 手数料はファスト・ジャミングを防止するためのものなので、非常に少額にすることができます。 ファストジャミングでは、偽の支払いを頻繁に再送信する必要があり、 その際に毎回前払い手数料を支払う必要がでてくるため、攻撃者のコストが上昇します。

    • ● 転送を伴うローカルのレピュテーション： 各ノードは、転送された支払いが保留されている期間と、徴収した転送手数料に関するピアの統計情報を保持します。 手数料あたりの保留時間が高い場合、そのピアを高リスクとみなし、 ローカルノードのスロットと資金を限定します。それ以外の場合は、ピアを低リスクとみなします。

      ノードが低リスクとみなすピアから転送された支払いを受け取ると、 そのピアが支払いを低リスクとしてタグ付けしているかどうかを確認します。 上流の転送ノードと、支払いの両方が低リスクである場合、その支払いは利用可能なスロットと資金を使用することができます。

    この論文は、メーリングリスト上でいくつかの議論を呼び、特にローカルレピュテーション方式が賞賛されました。

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

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

  • ● Sparrow 1.7.0リリース: Sparrow 1.7.0では、RBF(Replace-By-Fee)対応による トランザクションキャンセル機能のサポートやその他のアップデートが行われました。

  • ● Blixt WalletがTaprootをサポート: Blixt Wallet v0.6.0は、Taprootアドレスへの送受信をサポートしました。

  • ● Specter-DIY v1.8.0リリース: Specter-DIY v1.8.0は、再現可能なビルドと Taprootのkeypathによる支払いをサポートしました。

  • ● Trezor Suiteがコインコントロール機能を追加: Trezorは最近のブログ記事で、Trezor Suiteがコインコントロール機能をサポートしたことを発表しました。

  • ● StrikeがTaprootへの送金をサポート: Strikeのウォレットで、bech32mアドレスへの送金ができるようになりました。

  • ● 取引所KolliderがLightningのサポートを開始: Kolliderは、LNの入出金機能を備えた取引所とブラウザベースのLightningウォレットを発表しました。

リリースとリリース候補

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

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

    警告: このリリース候補には、mempoolfullrbf設定オプションが含まれており、 以前のニュースレター#222と#223で説明したように、 一部のプロトコルおよびアプリケーション開発者は、マーチャントサービスに対して問題を引き起こす可能性があると考えています。 また、ニュースレター #224に掲載しているように、トランザクションリレーにも問題が発生する可能性があります。

  • ● LND 0.15.5-beta.rc1は、LNDのメンテナンスリリースのリリース候補です。 予定されているリリースノートによると、小さなバグ修正のみが含まれているます。

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

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

  • ● Core Lightning #5681は、RPCのJSON出力をサーバー側でフィルタリングする機能を追加しました。 サーバー側でのフィルタリングにより、帯域幅の制限されたリモート接続使用時に、 不要なデータの送信を回避することができます。将来的には、 いくつかのRPCはフィルタリングされたデータの計算を回避できるようになり、 より速く結果を返せるようになる可能性があります。 フィルタリングはすべてのRPC、特にプラグインによって提供されるRPCについて、 保証されているわけではありません。フィルタリングが利用できない場合、 フィルタリングされていない完全な出力が返されます。 詳細は、追加されたドキュメントをご覧ください。

  • ● Core Lightning #5698は、実験的な開発者モードを更新し、 任意のサイズのonionでラップされたエラーメッセージを受信できるようになりました。 BOLT2は、現在256バイトのエラーを推奨していますが、それ以上のエラーメッセージを禁止しておらず、 LNの最新のTLV（Type-Length-Value）セマンティクスを使用してエンコードされた 1024バイトのエラーメッセージの使用を推奨するBOLTs #1021が公開されています。

  • ● Core Lightning #5647は、recklessプラグインマネージャーを追加しました。 このプラグインマネージャーは、lightningd/pluginsリポジトリからCLNのプラグインを名前でインストールするために使用されます。 プラグインマネージャーは、依存関係を自動的にインストールし、インストールの検証をします。 また、プラグインの有効化や無効化およびプラグインの状態を設定ファイルに保存することができます。

  • ● LDK #1796は、Confirm::get_relevant_txids()を更新し、 txidだけでなく参照されたトランザクションを含むブロックのハッシュも返すようにしました。 これは、ブロックチェーンの再編成がいつトランザクションの承認数を変更したかを、 より上位のアプリケーションが判断しやくします。もし、あるtxidのブロックハッシュが変わったとしたら、 それは再編成が発生したということになります。

  • ● BOLTs #1031は、簡略化されたマルチパスペイメントを使用する際、 支払人が受取人に要求された金額より少し多めに支払うことを許可します。 これは、選択された支払い経路がルーティング可能な最小額のチャネルを使用する場合に必要になることがあります。 たとえば、アリスが合計900 satを2つに分けたいものの、 選択した経路が両方とも最低500 satを必要とする場合です。この仕様変更により、 アリスは2つの500 satの支払いの送信ができるようになり、自分の好きな経路を使用するために合計100 satの過払いを選択することができます。