/ home / newsletters /
Bitcoin Optech Newsletter #413
今週のニュースレターでは、プルーニングノードが初期ブロックダウンロードに貢献できるようにするために 噴水符号を使用する研究を掲載しています。また、新しいリリースとリリース候補の発表や、 人気のBitcoin基盤ソフトウェアの注目すべき更新など恒例のセクションも記載しています。
ニュース
-
● IBDへの噴水符号の利用: Lucas Limaは、プルーニングノードがストレージ要件を大幅に増やすことなく 初期ブロックダウンロード(IBD)に貢献できるようにするための、噴水符号を使用した最新の研究について Delving Bitcoinに投稿しました。
Limaは専用のブログ記事で、この手法の仕組みについて説明しています。 チェーン全体をエポック(
k個のブロックで構成される固定長のチャンク)に分割し、 これらのエポックを噴水符号でエンコードし、ドロップレット(Droplet)と呼ばれるこれらのエンコード結果をブロックヘッダーとともに、 チェーンを再構築する必要があるノードに送信します。バケットノードと呼ばれる受信側のノードは、 特定のエポックに属する十分な数のドロップレットを収集してデコードすることで、元のk個のブロックを再構築します。 その後、ブロックヘッダーを使用して受信データが有効であることを検証し、悪意のあるノードによる再構築されたチェーンの改ざんを防止します。議論の中ではいくつかの重要な懸念点も指摘されました。特に開発者からは、 チェーンの再構築を成功させるために多数の接続ピアが必要になること、 IBDが遅くなること、ノードのフィンガープリンティングのリスクおよびDoS攻撃対象領域が増加する可能性が挙げられました。
リリースとリリース候補
人気のBitcoinインフラストラクチャプロジェクトの新しいリリースとリリース候補。 新しいリリースにアップグレードしたり、リリース候補のテストを支援することを検討してください。
-
● Bitcoin Core 31.1は、主要なフルノード実装のメンテナンスリリースです。 トランザクションの発信元のプライバシーを損なう可能性のある
-privatebroadcastのIPアドレスの漏洩を修正し(ニュースレター #409 参照)、 chainstateデータベースのコンパクション、ウォレットのマイグレーション、インプットサイズの推定、 MuSig2の鍵集約およびv2 P2Pトランスポートの再接続時のプロキシ処理に関する修正が含まれています。 詳細はリリースノートをご覧ください。 -
● LND v0.20.2-betaは、この人気のLNノード実装のメンテナンスリリースです。 DNSフォールバックのパニックとオンチェーンのフォワードインターセプターの決済バグを修正し、 先週取り上げた最終ホップのHTLCのCLTV期限の検証を追加しています(ニュースレター #412 参照)。
注目すべきコードとドキュメントの更新
最近のBitcoin Core、Core Lightning、Eclair、LDK、 LND、libsecp256k1、Hardware Wallet Interface (HWI)、Rust Bitcoin、BTCPay Server、BDK、Bitcoin Improvement Proposals(BIP)、Lightning BOLTs、Lightning BLIPs、 Bitcoin InquisitionおよびBINANAsの注目すべき変更点。
-
● Bitcoin Core #32489は、現在ロードされているウォレットの監視専用版を新しいウォレットファイルにエクスポートする
exportwatchonlywalletRPCを追加します。エクスポートされたウォレットは、restorewalletRPCを使用して別のノードでロードできます(ニュースレター #366参照)。 エクスポートされたウォレットには、元のウォレットの公開ディスクリプター、トランザクション、 ラベル、その他のメタデータが含まれますが、秘密鍵は含まれません。これまでは、 ユーザーは公開ディスクリプターをインポートしてこのようなウォレットを手動で構築する必要がありました。 -
● Bitcoin Core #32606は、コンパクトブロックリレー機能を更新し、
sendcmpctでサポートをネゴシエートしていないピアからのコンパクトブロックメッセージ、sendcmpct(1)による高帯域幅アナウンス用にノードが選択していないピアからのコンパクトブロックメッセージおよび ローカルノードが-blocksonlyモードで動作している場合のコンパクトブロックメッセージを無視するようにします。 コンパクトブロックは受信者のmempool内のトランザクションを使用して再構築されるため、 それらを処理すると、受信者がどのトランザクションを持っていないか、あるいはすでに持っているかが明らかになる可能性があります。 これはblocks-onlyノードにとって特に望ましくありません。というのも、 そのようなノードのmempool内のトランザクションはローカルで発信されたものである可能性が高いためです。 -
● Bitcoin Core #34020は、Mining IPCインターフェースに
getTransactionsByTxID()およびgetTransactionsByWitnessID()メソッドを追加します(ニュースレター #310および#323 参照)。 各メソッドはtxidまたはwtxidのリストを受け取り、ノードのmempoolから対応するシリアライズされたトランザクションを返します。 ノードが知らないトランザクションについては空の要素を返します。これはStratum v2のカスタムジョブ宣言で有用です。 プールは、マイナーが提案したブロックテンプレートのうち、まだ自身が持っていないトランザクションのみをリクエストしたい場合があるためです。 -
● Core Lightning #9104および#9292は、
option_simple_close協調閉鎖プロトコルの実験的サポートを追加します(ニュースレター #342参照)。 従来の協調閉鎖では、ピア同士が単一のクローズトランザクションと手数料について合意する必要があり、 合意できない場合、チャネルの閉鎖が行き詰まる可能性がありました。「simple close」は、 各ピアが自分の選んだ手数料を自分自身のアウトプットから差し引いた有効なクローズトランザクションを提案できるようにすることで、 この問題を回避します。両方のバージョンに署名してブロードキャストでき、競合するトランザクションのうち先に承認された方がチャネルを閉鎖します。 CLNはこのフローを新しいsimpleclosedサブデーモンに実装しており、ピアのバージョンの方が高い手数料を支払う場合には、 自分のバージョンのブロードキャストを遅らせます。#9292は、 閉鎖を開始する側の経済合理性のないアウトプットを許容されるゼロ値のOP_RETURNに置き換えた 署名済みsimple-closeトランザクションをCLNが拒否し、強制閉鎖を引き起こしていたエッジケースを修正します。 -
● Eclair #3323は、CLTV期限が2016ブロック(約2週間)より先の未来にある着信HTLCを失敗させるようにします。 これは、送信HTLCに対するEclairの既存の最大有効期限ポリシーを拡張するもので、 資金が長期間ロックされるリスクを軽減し、チャネルジャミングを困難にします。 Eclairは、問題のあるHTLCを一時的にチャネルコミットメントに受け入れてから失敗させます。 これは、即座に拒否するとチャネルが強制閉鎖されてしまうためです。
-
● LND #10832は、
InvoiceRequestメッセージのサポートを追加することで、 LNDによるBOLT12 オファーの実装を進めます(ニュースレター #410 参照)。 新しいコードはTLVのエンコード、デコードおよび構造の検証を追加し、署名の検証と対応するオファーとの照合は後続のPRに委ねています。