ethresear.ch と Delving Bitcoin の研究議論。
説明エフェメラル・ロールアップ：イーサリアムの新しい「L1.5」（イーサリアム研究フォーラムの技術議論）
要約本投稿は、利用者の状態をウォレットに置き、L1が共有状態と各状態遷移の検証を担い、その間の計算は次の作業に必要な状態を保持しない参加者が行い、結果をL1へ直接決済する「L1.5」というアーキテクチャの型を提案しています。EIP-8141、EIP-8250、EIP-8288などの提案を踏まえ、プライベートな決済の場面での実現可能性を論じ、L2との違いも説明しています。
説明情報ハザードと安全な削除：ビットコイン開発者フォーラムの議論で、特定データを保存・拡散したくないユーザー向けの選択肢を検討する投稿です。
要約投稿者は、主観的な情報ハザードがブロックチェーンに書き込まれる可能性があり、現時点では一般的な防御策がないと述べています。完全なアーカイブノードの機能をできる限り維持しつつ、ユーザーが情報ハザードと見なすデータを安全に削除できる仕組みについて議論を呼びかけ、関連する取り組みの情報を求めています。任意のデータのブロックへの書き込みを制限することは議論の対象外とされています。
説明ビットコイン決済への長い道のり：普及が進まない理由と、それを変えうる大胆な構想の募集
要約この技術コミュニティの議論は、ライトニングネットワークなど決済技術が成熟しているにもかかわらず、ビットコイン決済が普及していない理由を検討しています。主な障壁は需要の不足であり、大手決済事業者はステーブルコインを採用しつつあり、価格変動も大きいと指摘しています。筆者は、ビットコイン決済の状況を変えうる大胆なアイデアを募り、開発者、決済事業者、資金提供者に実験への参加を呼びかけています。
説明bitcoin-dev メーリングリストを読みやすくしたミラー：15年、24,699通
要約bitcoin-dev メーリングリストのアーカイブを毎日更新される読みやすいミラーとして公開しました。public-inbox と比べ、スレッドごとのページ、引用の折りたたみ、Message-ID による固定パーマリンク、話題・BIP・投稿者別の3種類の索引を提供します。メッセージ本文は原文のままで、各メッセージは元のアーカイブへのリンクがあります。作者名の統合方法とスレッドの紐付けについて意見を求めています。
説明Proof of One：暗号化投票用紙による「一人一身分」投票の設計と参考コード、厳格なレビューを求める
要約オープンソースの非営利プロジェクト Proof of One の維持者が、イーサリアム研究フォーラムに投稿した投票設計です。参加者は全員が実在の一人であり、運営者を含め誰も回答を個人と結び付けられず、各投票者は自分の投票記録を検証でき、公開データから誰でも再集計できることを目指しています。登録ではパスポートのICチップと零知識証明を使い、投票にはしきい値ElGamal暗号を用います。作者は、現在の設計と コードの大部分がAIエージェントの支援で作成され、独立した人間によるレビューはまだ受けていないと明記し、批判的な意見を求めています。
説明コンセンサス層P2Pのポスト量子移行に関する棚卸し
要約この Ethereum Research フォーラムの投稿は、コンセンサス層のP2Pネットワーク（Discovery v5、ENR、libp2p、QUIC/TLS 1.3）がポスト量子移行で直面する課題を整理しています。バリデーターのBLS署名を置き換えるだけでは、ネットワーク上のIDやハンドシェイクは更新されないと指摘しています。ENRは300バイト、Discoveryパケットは1,280バイトという構造上の制約もあります。アルゴリズム、エンコーディング、導入時期は選定されていません。
説明EIP-7002のLean形式検証：システムコールの成功と先入れ先出しのリクエスト
要約このイーサリアム研究フォーラムの投稿は、EIP-7002の展開済みバイトコードについて二つの性質をLean 4で証明したと述べています。システムコールはストレージの状態によらず成功し、消費ガスは210,000以下です。また、バリデータ退出と部分引き出しのリクエストは提出された順序どおりに出力されます。証明はJauneの実行意味論に基づき、Prague、Osaka、BPO1、BPO2の各フォークを対象としています。
説明自己発行型識別子向けのコストに基づくシビル攻撃耐性の提案
要約この議論は、自己発行型識別子の大量生成に実際の資源コストを課す構成を提案しています。生成者は256 MiBのメモリ領域で、連続するビットコインブロックヘッダーに結び付けられたメモリ依存の処理を実行し、その証拠を対象に記録します。独立した検証者は仕様に照らして測定し、6つの処理区間を無作為に再計算します。敵対的条件下で意味のある限界コストが生じるかは未解決であり、批判的なレビューが求められています。
説明ゼロ知識証明に関する疑問点と今後について（イーサリアム研究フォーラムの技術議論）
要約イーサリアム研究フォーラム（ethresear.ch）に投稿された技術議論のスレッドです。
説明FinalisCore の最新状況と未解決の論点（決定的 BFT ファイナリティとジェネシスからの秘匿 UTXO）
要約ビットコインを基盤とする FinalisCore プロジェクトの進捗が報告されています。テストネット 2 は 2026 年 10 月 24 日から稼働し、リーダー選出の VRF は RFC 9381 に移行しました。メインネットはまだ開始されていません。作者は、各高さで遷移が最大一つだけ確定すること、機密取引が価値を生み出せないこと、委員会・チェックポイント・報酬が確定済みの履歴のみから決定的に導出されることなど、中核的な主張について主網前の独立した検証を求めています。
説明ハッシュのみで動くロールアップ：OP Stack L2 のアカウントを Lamport 型ハッシュチェーンで実装し、L2 内に ECDSA を使わない設計
要約本投稿は、Ethereum メインネット上で稼働する OP Stack ロールアップを紹介しています。L2 のトランザクションには署名がなく、アカウントは keccak-256 ハッシュチェーンの末端として表されます。支出時に次のプリイメージを公開し、コミット・リビール方式でフロントランニングを防ぎます。著者は既知の問題点や他の信頼仮定も挙げ、議論を求めています。
説明CLN：自己参照チャネル告知によるDoS脆弱性の開示
要約Core Lightning v25.02からv26.04では、node_id_1とnode_id_2が同一のchannel_announcementを受け取るとクラッシュし、運用者が手動で記録を削除するまで再起動のたびにクラッシュし続けます。攻撃者は自分が管理する未使用の2-of-2出力があれば攻撃でき、コストはオンチェーン手数料のみです。修正はv26.04.1に含まれ、node_id_1がnode_id_2より小さくない告知を拒否するようになりました。
説明量子耐性案「Proof-of-Decay」（未移行の休眠UTXO向け暗号学的半減期）
要約本投稿はBitcoin開発者フォーラムに寄せられた提案で、量子攻撃への対策として、移行期限後も抗量子アドレスへ移されず鍵が露出したままの出力について、ブロック高に応じて残高を段階的に減少させる仕組みを示しています。減少したサトシは焼却されるか、マイナーへの報酬プールに回される想定です。作者は、ハードフリーズと放置の中間案としての評価と、合意レイヤーでの実装や経済的インセンティブについて意見を求めています。
説明BIP300（ドライブチェーン）に対する最も優れた批判は何か？
要約ビットコインのプロトコル開発を議論する Delving Bitcoin に投稿された討論スレッドで、投稿者は BIP300（ドライブチェーン）などの提案への批判を募っています。本文では、署名の偽造、マイナーによる資金の窃取の可能性、サイドチェーンの時間枠、スケーリングと過去の取引履歴の扱いといった一般的な疑問への応答が書かれています。
説明Paranoid EIP-8288：認証済みクラスバンクによる異種再帰
要約著者はParano1dで、認証された有限の検証器クラスバンクを用いる異種再帰集約を実装したと述べています。これにより、再帰ステップが複数の承認済み証明サイズを使えるようになり、小規模な集約はより小さな証明関係を利用できます。本稿では、異なるクラス間で遅延された行列評価の検証をどう引き継ぐかを説明し、EIP-8288の集約バックエンドへの応用と未解決の課題を論じています。
説明暗号化メンプールにおける公開の選択権：送信者の無料オプションはどれほど大きく、ポスト量子的にどう除去するか
要約本投稿は、暗号化メンプールで送信者が取引の公開を選べることによる無料オプションの価値を論じ、強制的な開示の限界とLUCID手数料方式の役割を分析しています。著者は、参加者が有用な情報を見る前に確定的にコミットする「盲目的同時公開（BSR）」方式を提案し、ハッシュのみを用いるためポスト量子的とされています。論文にはLean 4による形式検証が付いていますが、ハードウェア速度差の前提は実測されていません。
説明商店がより簡単・安価にビットコインを導入するための複数のプロジェクト
要約著者は過去2年間に取り組んできた、特にライトニング（Lightning）での商店導入を容易にするためのいくつかのプロジェクトを紹介しています。Electrum ウォレット用の CLINK プラグイン（nostr リレー経由で支払いを受け取り、ポート開放が不要）、入金流動性を自動で確保するプラグイン、Electrum のスワップサーバーを GUI で操作するツール、そして一般的なウェブホスティングや Windows デスクトップで動作し BTCPay と互換性のある商店向けソフトウェア BareBits が含まれます。BareBits は1%の手数料があり、オープンソースで自己ホスティング可能と説明されています。
説明SEACAST：イーサリアム向けの高速・軽量ブロードキャスト（実行可能な仕様と形式モデル付き）
要約著者は、イーサリアムで大きなメッセージを素早く配信するためのプロトコル SEACAST を提案しています。ノードは全体を受け取る前にチャンクを転送し、符号化とサンプリングにより必要な部分だけを届けます。投稿によれば、50 Mbps のネットワークで ECBroadcast や gossipsub より高速かつ少ない通信量で配信でき、仕様と形式モデルも公開されています。
説明コスト上限付きトランザクションフィルタリング言語
要約著者はトランザクションフィルタリングのポリシー用DSLを設計し、Rustで実装されたビットコインフルノードsatdに組み込みました。ノード運用者は、コンセンサスの正しさに影響を与えずに、中継やブロックテンプレートへの取り込みを行うトランザクションの形を決められます。ルールは非チューリング完全で、該当トランザクションを拒否ではなく隔離（quarantine）し、ポリシーを可視化・調整しやすくしています。
説明機密UTXOステートマシン上での決定的BFTファイナリティの評価
要約著者は、C++でゼロから実装されたオープンソースのレイヤー1プロトコル「FinalisCore」の設計を紹介し、その状態遷移モデルについて議論を求めています。このプロトコルは32ブロックのエポックごとに、委員会の定足数が署名した時点でブロックが確定し、secp256k1-zkpによるPedersenコミットメントで取引の秘匿性を実現します。文中では、委員会の急速な交代時のメモリプール無効化と、範囲証明のバッチ検証の処理負荷という2つの課題が挙げられており、現在はすべて非商業のテストネットで運用されています。
説明btc-verified 10月の進捗：形式モデルと実際のBitcoin Coreの挙動の照合
要約btc-verifiedプロジェクトはLeanでビットコインの合意モデルを形式化しています。本稿では、libbitcoinkernelインターフェースを利用し、bitcoinfuzz方式の差分ファジングによって、トランザクションの解析、シリアライズ、一部のトランザクション単体の検証について、モデルとBitcoin Coreの挙動が一致するかを比較する手法を説明しています。現在、9つのカーネル関数がLean実装で支えられています。
説明より高速で集約可能、量子耐性のあるプライバシープール（Privacy Pools）
要約著者らは Tornado Cash 型のプライバシープールを、耐量子性が見込まれる二元体上の SNARK 方式 Flock へ移植し、ハッシュに SHA-256 を用いて深さ 32 の出金証明を 30 ミリ秒未満で生成できることを示しています。また、ウォレットがノートの秘密値をシードから導出するだけで既存のプールを離散対数の破綻後も回復できる、簡単な復旧プロトコルも説明しています。
説明BABE方式における可変支払額の議論（Lichenへの適用）
要約本記事はBitcoinプロトコル開発のコミュニティでの技術的議論です。BABE方式が見届け暗号（witness encryption）を用い、有効なGroth16証明を持つ者だけがビットコインのコントラクトを解錠できる仕組みを説明しています。著者は、支払額を設定時ではなく後から決められるようにする手法を提案し、Lichenの例で検証者と証明者の署名のやり取りを示しています。
説明マルチパーティウォレット向けSilent Payments（静的支払い）プロトコルの提案
要約ビットコインプロトコル開発の議論フォーラムへの投稿で、複数の署名者で管理されるウォレットが安全にSilent Paymentを行うためのプロトコルを提案しています。各署名者のECDH共有値を重み付きで合計し、AggDLEQによって個々の証明を1つのBIP-374証明にまとめる方式です。投稿時点では安全性証明は内部レビュー中で、未公開とされています。
説明スクリーニングで「1秒」をどれだけ買えるか：AMMにおける更新頻度と情報優位取引の選別
説明P2Pの現金からエリートの決済レイヤーへ：2,100万枚の上限は新たな貴族階級を生むのか？
要約本投稿は、ビットコインが当初「ピア・ツー・ピアの電子現金」として構想されたものの、現在は政府・ETF・企業による準備資産としての保有が増え、日常的な支払いへの利用は減少していると論じています。筆者は、固定された2,100万枚の供給上限が一般の人々を徐々に締め出し、保有を富裕層や権力者に集中させるのではないかと問いかけ、単位数ではなく価値に上限を設け、日常の活動に支えられる「humanitycoin」という構想を提示しています。
説明分割証明を用いた高速ブロック：状態を超えて有効な実行証明（投稿の概要）
要約イーサリアム研究フォーラム（ethresear.ch）に投稿された技術議論です。ブロックの実行証明を三つに分割し、トランザクション証明は状態ルートに依存せず入力と出力のみを扱う案を提案しています。入力が有効であれば、証明はスロットをまたいで再利用できると説明されています。著者自身が、これは未証明・未測定のアイデア段階だと述べています。
説明Bitcoin Core 32.0rc4 リリース候補版の公開
要約Bitcoin Core の新しいメジャーバージョン 32.0 に向けたリリース候補 v32.0rc4 が公開されました。バイナリとソースコードの入手先、草案段階のリリースノートおよびテストガイドへのリンクが記載されています。テスターは指定の Issue に問題や意見を投稿できます。重大な問題が見つからなければ、v32.0 として正式にタグ付けされる予定です。
説明イーサリアムのブロック前方の優先手数料と取引種別の測定（2025年7月〜2026年10月）
要約著者はオープンソースツール TEMBRI を用い、16日分・約11.5万ブロックのイーサリアム実行データを分析しました。ブロック先頭10%のガス位置にある取引は、後方（30%〜60%）よりも優先手数料が高く、スワップ取引では平均で約8〜17倍でした。2026年8月から10月にかけて、先頭の無チップ・スワップは大きく減少しており、その多くは Titan ビルダーによるものです。
説明オープンソースのビットコイン マルチシグ調整ツール：共有署名キュー、ハードウェアウォレット、signet デモ
要約作者は btc-safe を公開しました。自己ホス型でウォッチオンリーのビットコイン マルチシグ調整ツールです。提案者が取引を作成すると、各共同署名者が共有キューで確認し、自分のデバイスで署名します。M of N の署名が揃うとブロードキャストされます。サーバーは xpub とディスクリプタのみを保存し、秘密鍵は保持せず署名も行いません。Ledger、Trezor、Sparrow、Caravan、PSBT ファイルに対応し、TOTP 二要素認証と役割ごとの権限を備えます。signet テストネットで試せ、実際の資金は使いません。
説明イーサリアム研究フォーラム：独立ブロックのためのパイプライン型コンセンサス（第二版）
要約本投稿は、直前のブロックに依存しないブロック設計を提案しています。各ブロックはその履歴の状態上で実行され、参照ブロックのフィルターを尊重するため、リオルグなしにブロックを投票で除外できます。履歴ルール、スロットごとのウィンドウ投票、安全性の概略、シミュレーション、モデル検査、メインネットでの測定（約87%の取引が高速経路で処理）を含みます。
説明情報化拡散：自宅のビルダーでも高速に公開できるようにする設計
要約本稿はEIP-8411シリーズの続編で、ペイロード拡散を四つの層に分けた設計を提案している。第1層はペイロードを単独で検証できるチャンクに分割し、受け取ったチャンクを全体の到着を待たずに転送する。第4層は各ノードが隣接ノードについて把握している情報をもとに転送を調整し、自宅回線のビルダーでも約3秒の期限内に配信できることを目指す。著者は、模擬した各種の負荷条件において第4層がこの期限内に収まったと報告している。
説明ERC-8403：アカウントを1つのハッシュで表し、耐量子鍵に対応する案
要約このフォーラム投稿は、アカウントがルートを1つだけ保持し、鍵の追加・ローテーション・失効はルートの更新で行い、アドレスは変わらないとする草案ERC-8403を紹介しています。また、eip-8288上で耐量子（leansphincs）鍵を加える考え方と、ローカル環境でのデモ結果、未解決の点を述べています。
説明[BIP草案] 共同署名者の支出ポリシー
要約本草案は、共同署名者（条件が満たされた場合にのみ署名する第三者）が実施するポリシーを標準化する形式を提案するもので、共同署名者そのものを規定するものではありません。開放検証、ブラインド検証、エンクレーブ検証を対象とし、取引内容や外部の証明を条件として使用できます。共同署名者はDLCオラクルの証明を受け入れる必要があります。作者は、この層を標準化すべきかどうか、またJSONかTLVか、ブラインド検証を今規定できるか等の未解決の論点について意見を求めています。
説明イーサリアム上のプライベート・ステーブルコイン：USDC/USDTを裏付けとし、プライバシー機能を組み込んだオンチェーン型ステーブルコインの構想
要約イーサリアム研究フォーラムの投稿で、イーサリアムのプログラマビリティを活用し、USDC/USDTを裏付けとしてプライバシー機能を内蔵したステーブルコインの設計が提案されています。スマートコントラクトによる発行と償還、許可を必要としない参加、既存のオンチェーンプロトコルとの組み合わせ、取引データの秘匿性などが挙げられています。選択的開示（selective disclosure）など、新たな応用の可能性にも触れています。
説明BRO-AMM：保証金付き照合オラクルAMMという低リスクDeFi基盤の提案
要約著者は初期段階のプレプリントBRO-AMMを公開し、流動性提供者が裁定取引によって損失を被る問題を論じています。設計では、取引は即時に執行されるものの、価格はその後の照合によって確定させる仕組みを提案しています。取引者は事前に保証金を預け、許容範囲を超えた分は預け入れ者に返還されます。ETH/USDCの6か月分の取引データによるシミュレーションでは裁定損失の減少が示されましたが、信頼できる署名付き価格源に依存しており、実運用はまだ行われていません。
説明Cassis：汎用的なマルチレイヤー・マルチホップHTLCルーティングの新しい簡易方式
要約ビットコインの決済は Lightning、Fedimint、Cashu、Arkade など複数の「レイヤー」に分散しており、それらの間を汎用的に送金する方法が不足しています。Cassis は、あるレイヤーが HTLC を表現できればそれを一つのホップとして使えるという考えに基づき、同一の SHA-256 ハッシュでロックされたレイヤー横断の HTLC チェーンで支払いを行う方式を提案しています。Rust による実装が公開されていますが、実験段階で未完成であり、ノード間通信、ルーター告知、評判、インボイス形式、オフライン受信などは未解決です。
説明イーサリアム上の耐量子証明のための命令セット（ISA）公開に関する議論
要約イーサリアム研究フォーラムの技術ディスカッション投稿です。EIP-8288（EVM外で検証される耐量子署名と STARK 証明に取引が依存できる提案）を前提に、EVM、RISC-V、証明向けに設計された eISA という三つの候補 ISA を比較しています。また、不変のスマートコントラクトを壊さずに公開する ISA を時間とともに変更する方法にも触れています。
説明FCRとEEZを組み合わせた例：イーサリアム間決済を速く確定させる仕組み
要約この技術フォーラムの投稿は、レイヤー2からの支払いを例に、FCR（Fast Confirmation Rule）とEEZ（Ethereum Economic Zone）を組み合わせた場合の効果を説明しています。FCRはブロックを信頼できると判断するまでの待ち時間を短縮し、EEZはrollupとベースレイヤーの間のブリッジ工程を取り除きます。両方を使うと、約2スロット（約25秒）で決済できると述べられています。
説明シビル攻撃下の複数提案者プロトコルにおける検閲耐性のコスト
要約このフォーラム投稿は、複数提案者プロトコルにおける検閲のコストを扱った論文について議論しています。その論文は、異なる取引手数料メカニズムの下で取引を効果的に検閲するコストと上限を導出しています。投稿者は、シビルノード（Sybil）が存在する場合に上限がどう変わるか、また多並行提案者（MCP）プロトコルへの結論の影響を検討しています。
説明イーサリアムの PropAMM（市場メーカーが価格を更新する取引方式）の現状と将来
要約本記事はイーサリアム研究フォーラムの技術的議論で、イーサリアムと Solana 上の PropAMM（マーケットメーカーがオンチェーンで価格を直接更新する方式）を比較しています。両チェーンの取引量データを示し、マーケットメーカーが遅延競争や逆選択の問題にどう対処するかを分析しています。さらに、両チェーンのブロック時間の構造の違いにも触れています。
説明誰がコードを片付けるのか？SETCODEFROMが残す宙ぶらりんのバイトコードと将来を見据えた設計判断
要約イーサリアム研究フォーラムの技術議論記事で、どのアカウントからも参照されなくなったバイトコードの扱いを検討しています。SETCODEFROM提案と分割二分木（PBT）によって、この残存コードが無害な残り物から設計上の判断事項へと変わると論じています。各クライアントの実装比較や参照カウントの必要性にも触れています。
説明別チェーン上でのSPVライトクライアントの固定：チェックポイント信頼、難易度調整、リオーグ処理
要約Writz Protocol（BTCを担保にStellar上でUSDCを貸し出す分散型レンディングプロトコル）の比特コイン側の設計を説明する技術議論です。担保はP2WSHスクリプトに置かれ、スマートコントラクト上でオンチェーンSPVライトクライアントを動かしています。著者は、チェックポイントの信頼、確認数、タイムロックの種類、手数料の引き上げ、ヘッダー検証コスト、リオーグの上限についてレビューを求めています。コードはテストネットのみで、監査は受けていません。
説明非同期パイプライン合意アーキテクチャによる直列検証ループの解消
要約このフォーラム投稿は、ブロック生成と完全なトランザクション検証を切り離す非同期パイプライン合意アーキテクチャを提案しています。紧凑ブロックとして6バイトの圧縮トランザクションID一覧のみを伝播させてブロックn+1の生成を開始し、ブロックnの状態検証はヘッダー内の1ビット検証フィールドによってブロックn+kへ遅らせる仕組みです。作者は、基礎的なセキュリティを損なわずにこの直列ボトルネックを解消できるか、またこの方式がアカウント型のイーサリアムに適用できるかを議論のために問いかけています。
説明暗号化メンプールの説明責任の仕組み
要約本稿は、委員会方式の暗号化メンプールで復号シェアが漏えいする問題を扱います。著者らは、取引の公開前に部分的な復号能力を漏らした委員会メンバーを特定するための、追跡可能な閾値暗号の候補構成を提案しています。ただし、セットアップや追跡主体などに課題が残る初期段階の提案であると述べられています。
説明ハッシュ原像のディスクリプタ構文に関する提案
要約本スレッドは、miniscript のハッシュ断片（sha256、hash256、ripemd160、hash160）に秘密情報形式を追加し、sha256(preimage(HEX)) のように原像をディスクリプタに含められるようにする提案です。作者は TABConf の CTB チャレンジで原像を提供できなかった経験を動機として挙げています。草案の構文、安全性、Bitcoin Core での扱い、未解決の論点も示されています。
説明計算量を基準とした最小限の購買力シグナル案の提案
要約投稿者は、信頼を最小化したオンチェーンの購買力に近いシグナルを提案しています。報告者が閾値と ETH の流動性を提出し、他者は閾値を満たす nonce を見つけて挑戦できます。生き残った閾値の単位流動性あたりの計算量を時期ごとに比較し、ETH の価値と計算コストの変化を推定する仕組みです。コントラクトは約200行で、現在 keccak256 を使用しています。
説明署名検証ツール1件に潜む欠陥6件を、外部から6回のテストで発見
要約著者は、x402カタログ向けの読み取り専用MCPサーバー（nsgoods）に含まれる署名検証ツールを、事前に予測を記録したうえで6回テストし、6件の欠陥を見つけました。正規の文書を誤って無効と判定する、改ざんされた本文が通ってしまう、拒否理由が区別できない、といった内容です。ログの扱いについて問い合わせた後、運営者はログの保存内容とプライバシーページの不一致を開示し、修正したと説明しています。著者は、失敗を観測していない検査は有効だと分かっているとは言えない、という考えを示しています。
説明単独所有者のコインには、最終確定前の二重支払い競合が本質的に存在するのか？
要約著者は、2-of-2の共同管理やLightning型のペナルティ機構を使わずに、支払人が受取人への支払い直前に自分のコインの支出を先行ブロードキャストできる問題を論じています。これが単独所有者コインの本質的な性質なのか、類似の解決策を研究している人がいるのかを問うています。
説明開示：Eclair v0.14.1 で修正された DoS 脆弱性
要約Eclair v0.14.1 で、チャネル開設フローにおける二つのサービス拒否（DoS）脆弱性が修正されました。ノードを保護するため、利用者は v0.14.1 以降へのアップグレードが求められています。一つ目は open_channel のレース条件で、攻撃者がメモリを漏洩させてヒープ枯渇によるクラッシュを引き起こせます。二つ目は未資金化チャネルの洪水で、レート制限を回避してオンチェーンコストなしにノードのメモリを使い果たせます。
