Neutrino to lekki klient Lightning Labs napisany w Go, projektowany także do mobilnego użycia z Lightning Network. Korzysta z BIP 157 i BIP 158; nie jest nazwą każdego lekkiego klienta ani samodzielnym zamiennikiem Full Node.
Aplikacja uruchamia ChainService zarządzający połączeniami z węzłami, bazą danych i synchronizacją nagłówków. Portfel wykorzystuje go do szukania wpływów i wydatków. Samo Neutrino nie określa, kto posiada klucze prywatne lub zatwierdza płatności; te zadania i kopie użytkownika należą do aplikacji nadrzędnej. [Lightning Labs — Neutrino README]
Klient synchronizuje nagłówki bloków i filtrów, pobierając filtry i pasujące bloki według potrzeb. Swoje skrypty sprawdza lokalnie. Dopasowanie może być fałszywie dodatnie, trzeba więc zbadać prawdziwy blok i znaleźć transakcję. Sam filtr nie podaje kwoty ani dowodu, że konkretny portfel kontroluje wyjście. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Lekki klient sprawdza nagłówki i ich powiązania, ale nie weryfikuje samodzielnie każdej transakcji i warunku konsensusu jak Full Node. Ponadto łańcuch nagłówków filtrów nie jest zapisany jako zobowiązanie w nagłówkach Bitcoin. Samo sprawdzenie ich hashy nie wyklucza zatem wewnętrznie spójnych, oszukańczych filtrów. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 opiera wykrywanie błędnych filtrów na porównywaniu odpowiedzi i co najmniej jednym uczciwym węźle. Kilka połączeń z maszynami tego samego napastnika nie spełnia tego warunku. Izolacja może ukryć przed klientem płatności lub nowy stan łańcucha; potrzebne są dostępne, różnorodne źródła, nie tylko jakiekolwiek połączenie. [BIP 157 — Client Side Block Filtering]
README opisuje Rescan z opcjonalnym blokiem początkowym i końcowym; bez początku skan rusza od ostatniego znanego bloku. Nie przeszukuje to automatycznie całej historii odtworzonego portfela. Aplikacja musi dostarczyć dostatecznie wczesny początek i pełen zestaw obserwowanych skryptów; poprawny filtr nie znajdzie adresu, którego klient nie szuka. [Lightning Labs — Neutrino README]
Udokumentowane zdarzenia recvtx i redeemingtx przychodzą przy potwierdzeniu, nie już przy wejściu transakcji do Mempool. Portfel pokazujący niepotwierdzone płatności potrzebuje więc odpowiedniego dodatkowego mechanizmu. Rozgłoszenie, przyjęcie przez węzeł i potwierdzenie w bloku są różnymi zdarzeniami; brak wiadomości sam nie dowodzi, że niczego nie wysłano. [Lightning Labs — Neutrino README]
Rescan zgłasza dołączone i odłączone bloki, aby aplikacja przeliczyła stan po reorganizacji. Pasujący filtr nadal wymaga rzeczywistego bloku; jego niedostępności nie wolno przedstawiać jako zerowego salda. Węzeł widzi żądania bloków i dane sieciowe, nawet bez listy poszukiwanych adresów klienta. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
README opisuje zapisywanie zamówionych filtrów i ładowanie bloków bez trwałego przechowywania; rzeczywiste działanie sprawdź dla konkretnej wersji i konfiguracji. Neutrino dostarcza dane łańcucha, nie kopię bieżącego stanu kanałów Lightning. Przed wdrożeniem osobno sprawdź odtworzenie historii, utratę węzłów, reorganizację i procedurę odzyskiwania kanałów aplikacji. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. Do tego hasła prowadzą również odsyłacze z Compact Block Filters, Compact Block Filters.