Neutrino adalah implementasi klien ringan dalam Go dari Lightning Labs, juga dirancang untuk penggunaan seluler bersama Lightning Network. Ia memakai BIP 157 dan BIP 158; bukan sebutan semua klien ringan ataupun pengganti mandiri Full Node.
Aplikasi memulai ChainService yang mengelola koneksi peer, basis data, dan sinkronisasi header. Dompet memakainya untuk mencari transaksi masuk dan keluar. Penggunaan Neutrino saja tidak menentukan siapa memegang kunci privat atau menyetujui pembayaran; fungsi-fungsi itu serta cadangan pengguna menjadi urusan aplikasi yang mengintegrasikannya. [Lightning Labs — Neutrino README]
Klien menyinkronkan header blok dan filter, lalu mengambil filter dan blok yang cocok sesuai kebutuhan. Skripnya diuji secara lokal. Kecocokan dapat berupa positif palsu, sehingga blok sebenarnya harus diperiksa dan transaksinya ditemukan. Filter saja tidak memberikan jumlah atau bukti bahwa dompet tertentu menguasai suatu output. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters]
Klien ringan memeriksa header dan kaitannya, tetapi tidak memverifikasi setiap transaksi dan syarat konsensus secara mandiri seperti Full Node. Rantai header filter juga tidak dikomitkan dalam header blok Bitcoin. Karena itu, memeriksa hash saja tidak dapat menyingkirkan filter palsu yang konsisten secara internal. [BIP 157 — Client Side Block Filtering] [Bitcoin developer guide — Operating Modes]
BIP 157 mengandalkan perbandingan jawaban dan setidaknya satu peer jujur untuk mendeteksi filter salah. Beberapa koneksi ke mesin penyerang yang sama tidak memenuhi syarat itu. Isolasi klien dapat menyembunyikan pembayaran atau keadaan rantai terbaru; diperlukan sumber tersedia dan beragam, bukan sekadar jumlah koneksi di atas nol. [BIP 157 — Client Side Block Filtering]
README menjelaskan Rescan dengan blok awal dan akhir opsional; tanpa awal, pemindaian dimulai dari blok terakhir yang diketahui. Itu tidak otomatis mencari seluruh riwayat dompet yang dipulihkan. Aplikasi harus memberi awal yang cukup dini dan seluruh skrip pantauan; filter yang benar tidak menemukan alamat yang tidak dicari klien. [Lightning Labs — Neutrino README]
Peristiwa recvtx dan redeemingtx yang didokumentasikan datang saat konfirmasi, bukan ketika transaksi masuk Mempool. Dompet yang menampilkan pembayaran belum terkonfirmasi memerlukan mekanisme tambahan yang sesuai. Penyiaran, penerimaan peer, dan konfirmasi blok berbeda; ketiadaan notifikasi saja tidak membuktikan tidak ada pengiriman. [Lightning Labs — Neutrino README]
Rescan melaporkan blok yang tersambung dan terlepas agar aplikasi menghitung ulang keadaan setelah reorganisasi. Filter yang cocok tetap memerlukan blok sebenarnya; ketidaktersediaannya tidak boleh ditampilkan sebagai saldo nol. Peer melihat permintaan blok dan data jaringan meski tidak menerima daftar alamat yang dicari klien. [Lightning Labs — Neutrino README] [BIP 157 — Client Side Block Filtering]
README menjelaskan penyimpanan filter yang diminta dan pemuatan blok tanpa penyimpanan permanen; periksa perilaku nyata menurut versi dan konfigurasi. Neutrino memasok data rantai, bukan cadangan keadaan kanal Lightning terkini. Sebelum diterapkan, uji secara terpisah pemulihan riwayat, kehilangan peer, reorganisasi, dan prosedur pemulihan kanal aplikasi. [Lightning Labs — Neutrino README] [Bitcoin developer guide — Operating Modes]
Untuk gambaran yang lebih utuh, baca entri ini bersama Compact Block Filters, Compact Block Filters, Full Node, Lightning Network, Eclipse attack. Entri ini juga dirujuk dari Compact Block Filters, Compact Block Filters.