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 `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.
* 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
