Neutrino ist die Go-Implementierung eines leichten Clients von Lightning Labs, auch für mobile Nutzung mit Lightning Network entworfen. Sie verwendet BIP 157 und BIP 158; der Name bezeichnet weder jeden leichten Client noch einen eigenständigen Ersatz für einen Full Node.
Die Anwendung startet ChainService, das Peer-Verbindungen, Datenbank und Header-Synchronisierung verwaltet. Darauf sucht die Wallet nach Ein- und Auszahlungen. Neutrino allein bestimmt nicht, wer private Schlüssel hält oder Zahlungen freigibt; diese Aufgaben und die Backups gehören zur übergeordneten Anwendung. [Lightning Labs — Neutrino README]
Der Client synchronisiert Block- und Filterheader und lädt bei Bedarf Filter und passende Blöcke. Seine Skripte prüft er lokal. Ein Treffer kann falsch positiv sein; deshalb muss er den tatsächlichen Block untersuchen und die Transaktion finden. Der Filter allein liefert weder einen Betrag noch den Beweis, dass eine bestimmte Wallet eine Ausgabe kontrolliert. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Ein leichter Client prüft Header und ihre Verkettung, aber nicht jede Transaktion und Konsensbedingung unabhängig wie ein Full Node. Die Filterheader-Kette ist außerdem nicht in Bitcoin-Blockheadern festgeschrieben. Nur ihre Hashes zu prüfen schließt daher intern konsistente gefälschte Filter nicht aus. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 setzt auf Antwortvergleiche und mindestens einen ehrlichen Peer zum Erkennen falscher Filter. Mehrere Verbindungen zu Rechnern desselben Angreifers erfüllen diese Bedingung nicht. Ein isolierter Client kann Zahlungen oder einen neuen Kettenstand übersehen; nötig sind verfügbare, vielfältige Quellen, nicht nur irgendeine Verbindung. [BIP 157 — Client Side Block Filtering]
Das README beschreibt Rescan mit optionalem Start- und Endblock; ohne Start beginnt der Scan beim letzten bekannten Block. Das durchsucht nicht automatisch die gesamte Historie einer wiederhergestellten Wallet. Die Anwendung muss einen ausreichend frühen Anfang und alle beobachteten Skripte liefern; ein korrekter Filter findet keine Adresse, nach der der Client nicht sucht. [Lightning Labs — Neutrino README]
Die dokumentierten Ereignisse recvtx und redeemingtx kommen bei Bestätigung, nicht beim Eintritt der Transaktion in den Mempool. Eine Wallet, die unbestätigte Zahlungen zeigt, benötigt daher einen passenden zusätzlichen Mechanismus. Versand, Peer-Annahme und Blockbestätigung sind getrennte Ereignisse; eine fehlende Meldung beweist allein nicht, dass nichts gesendet wurde. [Lightning Labs — Neutrino README]
Rescan meldet verbundene und abgetrennte Blöcke, damit die Anwendung ihren Zustand nach einer Reorganisation neu berechnen kann. Ein passender Filter benötigt weiterhin den tatsächlichen Block; dessen Nichtverfügbarkeit darf nicht als Nullsaldo erscheinen. Peers sehen Blockanfragen und Netzwerkdaten, auch ohne die Liste der gesuchten Adressen zu erhalten. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
Das README beschreibt das Speichern angeforderter Filter und das Laden von Blöcken ohne dauerhafte Speicherung; prüfe das tatsächliche Verhalten anhand von Version und Konfiguration. Neutrino liefert Kettendaten, kein Backup des aktuellen Lightning-Kanalzustands. Teste vor Einsatz getrennt Historienwiederherstellung, Peer-Ausfall, Reorganisation und die Kanalwiederherstellung der Anwendung. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse-Angriff. Auf diesen Eintrag verweisen außerdem Compact Block Filters, Compact Block Filters.