This commit adds a new method to the ChainNotifier interface which
subscribes the caller to a continuous stream of notifications generated
by new blocks added to the tip of the Bitcoin main chain.
Concurrently, this method is intended to be used in order to obtain the
necessary block height information to properly handle the timeout
period on any pending HTLCs. A continuos stream, rather than a one-off
notification is chosen in order to discourage a goroutine-per-HTLC
model which would be rather wasteful.
This commit updates the documentation for the chainntfs interface to
specify that notifications for spends registered with
`RegisterSpendNtfn` should be triggered *only* once a transaction
spending the target outpoint is *seen* within the network.
This strictness is required in order to allow an ‘honest’ counter-party
to properly sweep funds within channels with short delays.
* The tests as written will be general to all future implementations of
ChainNotifier allowing future implementers to easily ensure their
implementation meets the expected behavior.
* The tests will be moved to the outer directory once a registration
mechanism for notifier implementations is in place.
* Turns out the NotificationServer on btcwallet doesn’t sever full
blocks, nor notify for arbitrary transactions. Instead, we now create a
new client specifically for BtcdNotifier.
* Final implementation is simpler, less dependent on newer btcwallet
features in flux. Additionally, this decouples the chain notifications
from the wallet. Enabling reliance on btcd for notifications, in
conjunction with an independent wallet that satisfies the to-be-drafted
Wallet interface.
* Rather than rely on the legacy notification interface which may be
deprecated in the near future, we’ll now switch to using the
NotificationSever.
* Negative confirmation notifications due to re-orgs are still
unimplemented however.
* Re-orgs are still unhanded.
* RegisterSpendNtfn should perhaps also register directly with the rpc
client instead of pushing the responsibility to the caller.
* The `NotificationTrigger` struct has been dropped. Instead we know
simply employ a non-blocking send over a chan struct. This moves the
responsibility of triggering callbacks a level above to the registering
client.
* Confirmation notifications also now have a counter part in order to
notify a caller of the scenario wherein a funding transaction drops out
of the chain due to a re-org. A “neagtiveConf” value will be sent to
the client over a channel in this case. This will allow a caller to
re-register for another confirmation notification. Note that due to
this scenario, callers should also register for notifications
concerning spends of the counterparty’s inputs to the funding
transaction. If a second spend (other than the funding) is detected,
the channel should be closed immediately.
* Notifications concerning spends now also include the spending
transaction, hash, and the input on the spending transaction at which
the outpoint is spent.
* Currently depends on the wallet, but that will change in the near
future due to new additions to btcwallet currently under review.
* Re-orgs aren’t intelligently handled yet. To be done along with tests
in a later commit.
* So far very simple, only notifications for tx confirmations, and
outpoint spends.
* Our two cases are: waiting for the funding transaction to reach a
depth of N confirmations, and open channels being notified of the
counterpart trying to cheat them by broadcasting an invalidated
commitment tx.
* Goal is to backend agnostic source to chain notifications
* Open channels will communicate with this source to register intent
for critical notifications
* Pending notifications will need to be committed to disk.
* Will also need a journal to ensure no notification is missed
* Later goals include extending this to communicate with 3rd party
outsource services
