28eb8474f4
In this commit, we modify all existing historical rescans for ChainNotifier backends to scan backwards rather than forwards. If we know that a transaction has been confirmed, or outpoint spent, the it's likely that the event has recently transpired assuming we've been offline for a short period of time. Therefore, if we scan backwards rather than forwards, then we can save potentially hundreds or thousands of block fetches if the event recently happened close to the tip of the chain. We bound this search at the genesis block, to ensure we don't underflow the uint32 used throughout the package in the main loop. |
||
|---|---|---|
| .. | ||
| bitcoindnotify | ||
| btcdnotify | ||
| neutrinonotify | ||
| height_hint_cache_test.go | ||
| height_hint_cache.go | ||
| interface_dev.go | ||
| interface_test.go | ||
| interface.go | ||
| log.go | ||
| README.md | ||
| test_utils.go | ||
| txnotifier_test.go | ||
| txnotifier.go | ||
chainntnfs
The chainntnfs package implements a set of interfaces which allow callers to receive notifications in response to specific on-chain events. The set of notifications available include:
- Notifications for each new block connected to the current best chain.
- Notifications once a
txidhas reached a specified number of confirmations. - Notifications once a target outpoint (
txid:index) has been spent.
These notifications are used within lnd in order to properly handle the
workflows for: channel funding, cooperative channel closures, forced channel
closures, channel contract breaches, sweeping time-locked outputs, and finally
pruning the channel graph.
This package is intentionally general enough to be applicable outside the
specific use cases within lnd outlined above. The current sole concrete
implementation of the ChainNotifier interface depends on btcd.
Installation and Updating
$ go get -u github.com/lightningnetwork/lnd/chainntnfs