bf6001074c
In this commit, we fix a race condition related to the way we attempt to query to see if an outpoint has already been spent by the time it’s registered within the ChainNotifier. If the transaction creating the outpoint hasn’t made it into the mempool by the time we execute the GetTxOut call, then we’ll attempt to query for the transaction itself. In this case, if we query for the transaction, then the block hash field will be empty as it hasn’t yet made it into a block. Under the previous logic, we’d then attempt to force a rescan. This is an issue as the forced rescan will fail since it’ll try to fetch the block hash of all zeroes. In this commit, we fix this issue by only entering this “fallback to rescan” logic iff, the transaction has actually been mined. |
||
|---|---|---|
| .. | ||
| bitcoindnotify | ||
| btcdnotify | ||
| neutrinonotify | ||
| interface_test.go | ||
| interface.go | ||
| log.go | ||
| queue_test.go | ||
| queue.go | ||
| README.md | ||
| txconfnotifier_test.go | ||
| txconfnotifier.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