mirror of
https://github.com/lightningnetwork/lnd.git
synced 2024-11-19 01:43:16 +01:00
08f1c2e93a
In this commit, we add a new option for the existing confirmation notification system that optionally allows the caller to specify that a block should be included as well. The only quirk w/ the implementation here is the neutrino backend: usually we get filtered blocks, we so need to first fetch the block again so we can deliver the full block to the notifier. On the notifier end, it'll only be checking for the transactions we care about, to sending a full block doesn't affect the correctness. We also extend the `testBatchConfirmationNotification` test to assert that a block is only included if the caller specifies it. |
||
|---|---|---|
| .. | ||
| bitcoindnotify | ||
| btcdnotify | ||
| neutrinonotify | ||
| test | ||
| height_hint_cache_test.go | ||
| height_hint_cache.go | ||
| interface_dev.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