In this commit, we introduce the registration logic for spend
notifications to the TxNotifier. Most of this logic was taken from the
different existing ChainNotifier implementations, however, it features
some useful additions in order to make the ChainNotifier a bit more robust.
Some of these additions include the following:
1. RegisterSpend will now return a HistoricalSpendDispatch struct,
which includes the details for successfully determining if an outpoint
was spent in the past. A HistoricalSpendDispatch will only be returned
upon the first registration of an outpoint. This is done as,
previously, if multiple clients registered for the same outpoint, then
multiple historical rescans would also be dispatched, incurring a toll
on the backend itself.
2. UpdateSpendDetails will now be used to determine when a historical
rescan has completed, no matter if a spending transaction was found or
not. This is needed in order to responsibly update the spend hints for
outpoints at tip, otherwise we'd attempt to update them even though we
haven't yet determined if they have been spent or not. This will
dispatch notifications to all currently registered clients for the
same outpoint. In the event that another client registers later on,
then the spending details are cached in memory in order to prevent
further historical rescans.
In this commit, we introduce the required fields for the TxNotifier to
properly carry its duties in notifying its registered clients about the
spend of an outpoint. These are not yet used, but will be throughout the
some of the following commits.
In this commit, we add a new channel within the SpendEvent struct that
will be sent upon whenever the spending transaction of the registered
outpoint gets reorged out of the chain. This will pave the road for
successfully handling a funding transaction getting reorged out of the
chain among other things.
In this commit, we modify our height hint cache to no longer start a
database transaction if no outpoints/txids are provided to update the
height hints for.
In this commit, we modify the set of tests that start the different
backend notifiers with UnsafeStart to stop them within the tests
themselves. This prevents us from running into a panic when attempting
to run the package-level tests with a filter (using test.run).
This commit fixes an oversight in the previous
design of the watchtower blob, by introducing
a length byte for sweep addresses. The previous
format supposed that addresses would be padded
to 42 bytes, but had no indication of the
address's actual length.
To rememdy this, we introduce a single byte
indicating the actual size of the address,
such that the padding can be removed upon
decoding.
- Provides clarity to the sample `lnd.conf` to reduce friction on a first-time mainnet set up of lnd (avoiding the `loadConfig: debug-htlc mode cannot be used on bitcoin mainnet` error)
- Removes `debughtlc` from the sample `lnd.conf` since it is not something most people would use anymore
- Adds link to `sample-lnd.conf` with proper line-wrapping
This change was inspired by #1984 - the underlying call to
ListUnspent supports a (min, max) range so it makes sense that
the WalletController interface can also support this; a
default no-maximum can be expressed using a MaxInt32 value.
Removes details field from conf notifications, in favor
of using the details on the confSet. We also bound the
requested conf depth to the reorg saftey limit, as the
behavior of state tracking within the notifier is
undefined otherwise.
In this commit, we address a small bug where it's possible to deliver a
confirmation notification with stale confirmation details upon
registration. This can happen if a transaction has confirmed but was
reorged out of the chain later on, and a subsequent notification is
registered.
In this commit, we'll attempt to consume a reorg notification for a
transaction that was previously reorged out of the chain upon block
inclusion to ensure that it is not lingering due to a client not
handling it the first time.
In this commit, we mark the rescan status for a transaction as complete
if we happen to detect it has confirmed within a new block that extends
the chain. We do this as otherwise, it's possible for us to not
immediately dispatch the notification upon a subsequent registration due
to the rescan state machine.
This commit ensures that a confSet's details
are assigned in the confNotifications index
after discovering the transaction at tip. The
recent changes allow a later notification to
be dispatched on registration if an earlier one
has already discovered the confirmation details.
Before this change, it was observed that a later
registration would attempt an immediate delivery,
but fail to do so because the confset's details
were nil. This commit remedies that dispatch path,
allowing the integration tests to pass again.
