Neutrino は Lightning Labs が Go で実装した軽量クライアントで、Lightning Network と組み合わせるモバイル用途も想定しています。BIP 157 と BIP 158 を使いますが、あらゆる軽量クライアントの総称でも Full Node の単独の代替でもありません。
アプリは ChainService を起動し、ピア接続、データベース、ヘッダー同期を管理させます。その上でウォレットが入出金を探します。Neutrino を使うだけでは誰が秘密鍵を持ち支払いを承認するかは決まりません。これらの機能やユーザーのバックアップは上位アプリが担います。 [Lightning Labs — Neutrino README]
クライアントはブロックとフィルターのヘッダーを同期し、必要に応じてフィルターと一致したブロックを取得します。自分のスクリプトはローカルで照合します。一致には偽陽性があるため、実際のブロックを調べて取引を見つける必要があります。フィルターだけでは金額も、そのウォレットが出力を管理する証拠も得られません。 [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
軽量クライアントはヘッダーと接続関係を確認しますが、Full Node のように全取引とコンセンサス条件を独立に検証しません。また、フィルターヘッダー列へのコミットメントは Bitcoin ブロックヘッダーにありません。ハッシュの確認だけでは、内部的に整合した偽フィルターを排除できません。 [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 は応答の比較と少なくとも一つの正直なピアによって誤ったフィルターを発見する仕組みです。同じ攻撃者の複数の機器への接続では条件を満たしません。クライアントの隔離は支払いや新しいチェーン状態を隠し得ます。接続がゼロでないだけでなく、利用可能で多様な情報源が必要です。 [BIP 157 — Client Side Block Filtering]
README の Rescan は開始・終了ブロックを任意に指定でき、開始点がなければ最後に把握したブロックから走査します。復元したウォレットの全履歴を自動的に探すわけではありません。アプリは十分早い開始点と全監視スクリプトを渡す必要があります。正しいフィルターでも探していないアドレスは見つかりません。 [Lightning Labs — Neutrino README]
文書化された recvtx と redeemingtx のイベントはブロック承認時に来るもので、取引が Mempool に入った時点ではありません。未承認の支払いを表示するウォレットには適切な追加の仕組みが必要です。配信、ピアでの受信、ブロック承認は別の出来事で、通知がないだけでは未送信の証拠になりません。 [Lightning Labs — Neutrino README]
Rescan は接続・切断されたブロックを通知し、アプリが再編成後の状態を再計算できるようにします。一致するフィルターがあっても実際のブロックが必要で、その取得不能を残高ゼロとして表示してはいけません。ピアは検索アドレス一覧を受け取らなくても、ブロック要求とネットワーク情報を見られます。 [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
README は要求したフィルターの保存と、ブロックを永続保存せず読み込む動作を説明しています。実際の動作は版と設定で確認してください。Neutrino はチェーン情報を渡すもので、現在の Lightning チャネル状態のバックアップではありません。導入前には履歴復元、ピア喪失、再編成、アプリ固有のチャネル復旧を別々に試します。 [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
理解を深めるには、この項目とあわせて次もお読みください Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. 次の項目からも参照されています Compact Block Filters, Compact Block Filters.