36c299c1d8
In this commit, we fix an existing bug within the logic of the neutrino notifier. Rather than properly dispatching only once a transaction had reached the expected number of confirmations, the historical dispatch logic would trigger as soon as the transaction reached a single confirmation. This was due to the fact that we were using the scanHeight variable which would be set to zero to calculate the number of confirmations. The value would end up being the current height, which is generally always greater than the number of expected confirmations. To remedy this, we’ll now properly use the block height the transaction was originally confirmed in to know when to dispatch. This also applies a fix that was discovered in 93981a85c0b47622a3a5e7089b8bca9b80b834c5. |
||
|---|---|---|
| .. | ||
| btcdnotify | ||
| neutrinonotify | ||
| interface_test.go | ||
| interface.go | ||
| log.go | ||
| queue_test.go | ||
| queue.go | ||
| README.md | ||
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