Commit Graph

9 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
7bff2e07a8
chainntfs: add new RegisterBlockHeightNtfn method
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.
2016-06-21 13:12:35 -07:00
Olaoluwa Osuntokun
1879c00c55
chainntfs: further specify behavior of RegisterSpendNtfn
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.
2016-06-21 13:12:31 -07:00
Olaoluwa Osuntokun
fcff17c336
multi: change all imports to roasbeef's forks
This commit will allow the general public to build lnd without jumping
through hoops setting up their local git branches nicely with all of
our forks.
2016-05-15 17:22:37 +03:00
Olaoluwa Osuntokun
3186b3038c chainntfns: document the ChainNotifier interface 2016-02-26 17:38:31 -08:00
Olaoluwa Osuntokun
19e1b64f2c chainntfs: use an int32 for NegativeConf 2016-02-26 17:38:31 -08:00
Olaoluwa Osuntokun
b913bda472 chainntfs: expand ChainNotifier interface
* 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.
2016-02-26 17:38:30 -08:00
Olaoluwa Osuntokun
8154b96d67 chainntfs: flesh out initial draft of interface
* 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.
2016-01-14 23:56:11 -08:00
Olaoluwa Osuntokun
e2c4ccbe28 chaintfns: skeleton of first notifier 2015-12-16 22:55:22 -06:00
Olaoluwa Osuntokun
b2522ef75a Create skeleton for chain notifications
* 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
2015-12-16 14:38:21 -06:00