This PR proposes the first implementation of NodeService and ScannerService.
The terminology of services and methods can differ from the ones discussed in #1. I finally splited the code into two services:
NodeService which basically aims to be a full elements node syncing block headers and block compact filters.
ScannerService which is the former "UtxoService", responsible of resolving "ScanRequest".
Elements Full node (NodeService)
Re-implement the tinybit architecture for elements node.
Sync block headers
Sync compact block filters
Use FilterRepository and BlockHeaderRepository to fill headers and filters databases.
the node does not check block signatures (or any equivalent of PoW checks)
the node does not check Merkle root of blocks
the node handles the inv messages but uses BIP0130 to sync headers (low bandwidth nodes)
Scanner service (BIP158)
ScannerService fetches block headers and compact filters via FilterRepository and BlockHeaderRepository interfaces.
It uses a neutrino-like interface to "watch" blocks: user can use Watch method to send ScanRequest, then the scanner will return a SpendReport as soon as it finds the WatchItem using filters.
I reused the same algorithm of neutrino to handle requests (see the requestWorker function).
How to quick test
This PR provides a simple CLI using to test this POC full node + filter scanner, u can run the following:
go run ./cmd start
(or build the binary)
The start command lets u run a full node which will sync with your nigiri instance. It also silently run a ScannerService and sends a ScanRequest on the following address:
As soon as you faucet this address, the scanner will log a report with txid.
PS: Note that this "WatchItem" is an AddressWatchItem, we can also watch for outpoint to be spent with OutpointWatchItem or whatever implementing WatchItem interface.
About WASM
I'm not sure we need to compile the ScannerService, it should be easy to reimplement it for browser using Javascript. This good article from Trezor's blog demonstrates it.
About the NodeService, the hard part is the communication with peers. That's why node pkg never handles directly TCP streams, the peer pkg is here to abstract this. The idea could be to rewrite a browser-compatible Peer.
it closes #1
@tiero @altafan please, can u review this (consider this as a proof of concept, not a polished work I think the full node needs extra work to be a "real" full node for instance)
This PR proposes the first implementation of
NodeServiceandScannerService.The terminology of services and methods can differ from the ones discussed in #1. I finally splited the code into two services:
NodeServicewhich basically aims to be a full elements node syncing block headers and block compact filters.ScannerServicewhich is the former "UtxoService", responsible of resolving "ScanRequest".Elements Full node (NodeService)
FilterRepositoryandBlockHeaderRepositoryto fill headers and filters databases.invmessages but uses BIP0130 to sync headers (low bandwidth nodes)Scanner service (BIP158)
FilterRepositoryandBlockHeaderRepositoryinterfaces.Watchmethod to sendScanRequest, then the scanner will return aSpendReportas soon as it finds theWatchItemusing filters.requestWorkerfunction).How to quick test
This PR provides a simple CLI using to test this POC full node + filter scanner, u can run the following:
(or build the binary)
The
startcommand lets u run a full node which will sync with your nigiri instance. It also silently run aScannerServiceand sends a ScanRequest on the following address:As soon as you faucet this address, the scanner will log a report with txid.
PS: Note that this "WatchItem" is an
AddressWatchItem, we can also watch for outpoint to be spent withOutpointWatchItemor whatever implementingWatchIteminterface.About WASM
ScannerService, it should be easy to reimplement it for browser using Javascript. This good article from Trezor's blog demonstrates it.NodeService, the hard part is the communication with peers. That's whynodepkg never handles directly TCP streams, thepeerpkg is here to abstract this. The idea could be to rewrite a browser-compatiblePeer.it closes #1
@tiero @altafan please, can u review this (consider this as a proof of concept, not a polished work I think the full node needs extra work to be a "real" full node for instance)