Commit Graph

338 Commits

Author SHA1 Message Date
Conner Fromknecht
45a2c9aca8
chainntnfs/height_hint_cache_test: add tests for disabled cache 2018-08-26 15:32:09 -07:00
Conner Fromknecht
7df9ae0266
chainntnfs/height_hint_cache: add disable flag to hint cache 2018-08-26 15:32:06 -07:00
Conner Fromknecht
20ba489b4a
chainntnfs/interface: fix TxConfStatus godocs for linter 2018-08-24 11:29:09 -07:00
Johan T. Halseth
f82fd5fe86
chainntnfs/bitcoind: fallback to scan manually only in case of err != nil 2018-08-24 14:46:20 +02:00
Johan T. Halseth
01d8953737
chainntnfs/btcd: fallback to scan manually only in case of err != nil 2018-08-24 14:46:20 +02:00
Johan T. Halseth
31dc387e0f
chainntnfs/btcd+bitcoind tests: use common TxConfStatus 2018-08-24 14:46:20 +02:00
Johan T. Halseth
79b2ee7da5
chainntnfs/btcd+bitcoind: use common TxConfStatus 2018-08-24 14:46:20 +02:00
Johan T. Halseth
b552984fcd
chainntnfs: define common TxConfStatus type 2018-08-24 14:46:20 +02:00
Johan T. Halseth
89c33731fe
chainntnfs/bitcoind: remove unnecessary check for tx==nil 2018-08-24 14:46:20 +02:00
Johan T. Halseth
4a60887974
chainntnfs/btcd: remove unnecessary check for tx==nil 2018-08-24 14:46:19 +02:00
Johan T. Halseth
a91466e9fa
chainntnfs/bitcoind tests: check found mempool case 2018-08-24 13:51:54 +02:00
Johan T. Halseth
cb3ec07685
chainntnfs/test_util: set 10ms trickleInterval for miner 2018-08-24 13:50:47 +02:00
Conner Fromknecht
ecc91305ac
chainntnfs/btcdnotify: initialize with height hint cache 2018-08-24 04:05:46 -07:00
Conner Fromknecht
16a321f6c5
chainntnfs/bitcoind: initialize with height hint cache 2018-08-24 04:05:18 -07:00
Olaoluwa Osuntokun
9b6b78a932
chainntnfs/neutrinonotify: update to latest API changes 2018-08-24 03:36:25 -07:00
Wilmer Paulino
191c4f3e28
multi: enable txindex on miner harness 2018-08-24 03:36:25 -07:00
Wilmer Paulino
cb688de7ad
chainntnfs: guard test chain notifier under debug flag 2018-08-24 03:36:25 -07:00
Wilmer Paulino
7895f01e2e
chainntnfs: ensure proper fallback to scanning tx manually
In this commit, we address a bug where it's possible that we still
attempt to manually scan for a transaction to determine whether it's
been included in the chain even after successfully checking the txindex
and not finding it there. Now, we'll short-circuit this process by
exiting early if the txindex lookup was successful but the transaction
in question was not found. Otherwise, we'll fall back to the manual
scan.
2018-08-24 03:36:24 -07:00
Wilmer Paulino
f88f6f68d4
chainntnfs: extract helper test vars and functions
In this commit, we extract some of the helper test variables and
functions into their own file and guard them under a build flag. This is
needed as some unit tests will be introduced in a future commit where
most of the same functions within the interface tests are reused. In
order to prevent these variables and functions from being exportable, we
guard them by the "debug" build tag.
2018-08-24 03:36:24 -07:00
Wilmer Paulino
2f644d9b62
chainntnfs/neutrinonotify: disable disconnected block ntfns while
rescanning

In this commit, we modify the rescan options Neutrino uses when
performing a rescan for historical chain events to disable disconnected
block notifications. This is needed as the Neutrino backend will mutate
its internal state while rewinding, which causes disconnected block
notifications to be sent. Since the notifier acts upon these
notifications, they would cause it to also rewind unnecessarily.
2018-08-21 13:02:17 -04:00
Wilmer Paulino
94beabf34b
chainntnfs: cache spend hints within the different chain notifiers
In this commit, we extend the different ChainNotifier implementations to
cache height hints for our spend events. Each outpoint we've requested a
spend notification for will have its initial height hint cached. We then
increment this height hint at every new block for unspent outpoints.
This allows us to retrieve the *exact* height at which the outpoint has
been spent. By doing this, we optimize the different ChainNotifier
implementations since they will no longer have to rescan forward (and
possibly fetch blocks in the neutrino/pruned node case) from the initial
height hint.
2018-08-21 12:55:53 -04:00
Wilmer Paulino
7e872566c4
chainntnfs: query the hint cache before registering a conf ntfn
In this commit, we alter the different chain notifiers to query their
height hint cache before registering a confimation notification. We do
this as it's possible that the cache has a higher height hint, which
can potentially reduce the amount of blocked fetched when attempting
historical dispatches.
2018-08-21 12:55:52 -04:00
Wilmer Paulino
30fd219b1c
chainntnfs: add height hint caches to chain notifiers 2018-08-21 12:55:51 -04:00
Wilmer Paulino
6be642a033
chainntnfs: cache confirm hints within TxConfNotifier
In this commit, we extend our TxConfNotifier to cache height hints for
our confirmation events. Each transaction we've requested a confirmation
notification for will have its initial height hint cached. We increment
this height hint at every new block for unconfirmed transactions. This
allows us to retrieve the *exact* height at which the transaction has
been included in a block. By doing this, we optimize the different
ChainNotifier implementations since they will no longer have to scan
forward (and possibly fetch blocks in the neutrino/pruned node case)
from the initial height hint looking for the confirmation.
2018-08-21 12:55:50 -04:00
Wilmer Paulino
b78cd533f2
chainntnfs: add height hint cache interfaces and channeldb implementation
In this commit, we introduce two new interfaces: SpendHintCache and
ConfirmHintCache for a height hint cache. The SpendHintCache is
responsible for maintaining the earliest height at which an outpoint
could have been spent within the chain, while the ConfirmHintCache is
responsible for maintaining the earliest height at which a transaction
confirms within the chain. We also add an implementation of these
interfaces with a single struct HeightHintCache, backed by a channeldb
instance, which will cary the duties of the interfaces above.
2018-08-21 12:55:49 -04:00
Valentine Wallace
fb7deac898
chaintnfs/interface_test: test notifiers handling missed blocks
Tests for the case where a chain backend skips a series of blocks, such that the notifier's best block is out of date. Also tests the case where a notifier's best block has been reorged out of the chain.
2018-08-11 22:45:25 -07:00
Valentine Wallace
dea22eb874
chainntnfs/interface_test: add test for client catchup on block ntfns
This tests the case where a client registers for block notifications with an outdated best block, to ensure that the client is properly caught up on the blocks that it has missed.
2018-08-11 22:45:17 -07:00
Valentine Wallace
f6ba64056a
chainntnfs/interface_test: utilize TestChainNotifier interface in tests
Switches all ChainNotifier parameters to be TestChainNotifiers. This allows access to the extra testing methods provided by the TestChainNotifier interface.
2018-08-11 22:45:17 -07:00
Valentine Wallace
b3a5b3b576
chainntnfs: add ChainNotifier test interface for test methods
TestChainNotifier wraps the ChainNotifier interface to allow adding additional testing methods with access to private fields in the notifiers. These testing methods are only compiled when the build tag "debug" is set. UnsafeStart allows starting a notifier with a specified best block.

UnsafeStart is useful for the purpose of testing cases where a notifier's best block is out of date when it receives a new block.
2018-08-11 22:45:03 -07:00
Valentine Wallace
79cbea1c9c
chainntnfs: enable notifiers to catch up on missed blocks
This resolves the situation where a notifier's chain backend skips a series of blocks, causing the notifier to need to dispatch historical block notifications to clients.

Additionally, if the current notifier's best block has been reorged out, this logic enables the notifier to rewind to the common ancestor between the current chain and the outdated best block and dispatches notifications from the ancestor.
2018-08-10 01:08:58 -07:00
Valentine Wallace
3df5b26699
chainntnfs: notify clients after block connect has succeeded
This prevents the situation where we notify clients about a newly connected block, and then the block connection itself fails. We also want to set our best block in between connecting the block and notifying clients, in case a client makes queries about the new block they have received.
2018-08-10 01:08:58 -07:00
Valentine Wallace
cbf1799c40
chainntnfs: rewind chain on missed disconnected blocks
If the chain backend misses telling the notifier about a series of disconnected blocks, the notifier is now able to disconnect the tip to its new best block.
2018-08-10 01:08:57 -07:00
Valentine Wallace
a5e1cf9c97
chainntnfs: dispatch historical block ntfns to clients
If a client passes in their best known block when registering for block notifications, check to see if it's behind our best block. If so, dispatch the missed block notifications to the client.

This is necessary because clients that persist their best known block can miss new blocks while registering for notifications.
2018-08-10 01:08:57 -07:00
Valentine Wallace
02ee5650c8
chainntnfs/neutrino: add neutrino ChainConn implementation 2018-08-10 01:08:57 -07:00
Valentine Wallace
f4005175d8
chainntnfs/interface: add ChainConn interface
This allows notifiers to pass their chain backend into interface functions to retrieve information from the chain.
2018-08-10 01:08:57 -07:00
Valentine Wallace
d4cf271526
chainntnfs: track best block in btcd and bitcoind 2018-08-10 01:08:57 -07:00
Valentine Wallace
1ffc3bb82e
multi: update to latest RegisterBlockEpochNtfn interface 2018-08-10 01:08:57 -07:00
Valentine Wallace
71a81f59a9
chainntnfs: allow clients to pass in best block
Clients can optionally pass their best block known into RegisterBlockEpochNtfn. This enables the notifiers to catch up clients on blocks they may have missed.
2018-08-10 01:08:54 -07:00
Wilmer Paulino
936fcc1f16
multi: update to latest BitcoindClient interface
In this commit, we introduce a nice optimization with regards to lnd's
interaction with a bitcoind backend. Within lnd, we currently have three
different subsystems responsible for watching the chain: chainntnfs,
lnwallet, and routing/chainview. Each of these subsystems has an active
RPC and ZMQ connection to the underlying bitcoind node. This would incur
a toll on the underlying bitcoind node and would cause us to miss ZMQ
events, which are crucial to lnd. We remedy this issue by sharing the
same connection to a bitcoind node between the different clients within
lnd.
2018-08-08 20:26:30 -07:00
Conner Fromknecht
1ded697e8d
multi: sort import paths with gofmt 2018-08-02 18:20:49 -07:00
Olaoluwa Osuntokun
b1a775b29e
chainntnfs/neutrinonotify: update async conf dispatch to use scripts 2018-07-31 21:29:04 -07:00
Olaoluwa Osuntokun
1a5b1d9792
chainntnfs: update interface tests to pass the prev script into RegisterSpendNtfn 2018-07-31 21:28:53 -07:00
Olaoluwa Osuntokun
f87b1a94c5
chainntnfs/neutrinonotify: update neutrino backend to use new API
In this commit, we update the neutrino backend for the ChainNotifier to
use the new API which requires that callers pass the outpoint along with
the pkScript to be notified of any spends.
2018-07-31 21:28:53 -07:00
Olaoluwa Osuntokun
6781b17056
chainntnfs: update bitcoind and btcd backends to match new spend ntfn API 2018-07-31 21:28:53 -07:00
Olaoluwa Osuntokun
7a0b7d2742
chainntnfs: update RegisterSpendNtfn to take the prev output script
In this commit, we update the RegisterSpendNtfn method to also take the
prev output script of the item that we're attempting to watch for. This
change is required due to the recent modifications in the neutrino
protocol (BIP 158 + 157). With the new protocol, we'll match on the
script, but then dispatch notifications based on the precise outpoint
that matches.
2018-07-31 21:28:52 -07:00
Olaoluwa Osuntokun
21847dc691
chainntnfs/neutrinonotify: update conf notifications to use pkScript
In this commit, we update the implementation of conf notifications for
neutrino to use the output script rather than the txid when matching
blocks for relevant items. The change itself is rather minor as we just
pass in the script, yet match based on the txid as normal when we go to
dispatch notifications.
2018-07-31 21:28:49 -07:00
Olaoluwa Osuntokun
e93149e576
chainntnfs/btcdnotify: update RegisterConfirmationsNtfn to take pkScript 2018-07-31 21:28:49 -07:00
Olaoluwa Osuntokun
f45e41afc1
chainntnfs/bitcoindnotify: update RegisterConfirmationsNtfn to take pkScript 2018-07-31 21:28:48 -07:00
Olaoluwa Osuntokun
6387c9e085 chainntnfs: update interface to use pkScript for conf notifications 2018-07-31 21:14:41 -07:00
Olaoluwa Osuntokun
0f98030186 chainntnfs: update RegisterConfirmationsNtfn to also pass in pkScript of output
In this commit, we prep for an upcoming final change to BIP 158. The
change results in the txid no longer being included in the regular
filter. As a result, neutrino will now need to match based on the output
script of the transaction that we wish to receive confirmation
notifications for.
2018-07-31 21:13:43 -07:00
Wilmer Paulino
8f5f3bcab2 chainntnfs/interface_test: remove code found within helper functions 2018-07-31 18:23:25 -07:00
Wilmer Paulino
65b6257e1e chainntnfs/bitcoindnotify: make historical spend rescans async 2018-07-31 18:23:25 -07:00
Wilmer Paulino
12816a910d chainntnfs: make historical confirmation rescans async 2018-07-31 18:23:25 -07:00
Wilmer Paulino
867d8524bf chainntnfs/txconfnotifier: make confirmation notifcation registration async
In this commit, we modify our TxConfNotifier struct to allow handling
notification registrations asynchronously. The Register method has been
refactored into two: Register and UpdateConfDetails. In the case that a
transaction we registered for notifications on has already confirmed,
we'll need to determine its confirmation details on our own. Once done,
this can be provided within UpdateConfDetails.

This change will pave down the road for our different chain notifiers to
handle potentially long rescans asynchronously to prevent blocking the
caller.
2018-07-31 18:23:25 -07:00
Wilmer Paulino
c43506dee9 chainntnfs: add unique ID field to track conf ntfns within notifier 2018-07-31 18:23:25 -07:00
Wilmer Paulino
ad904ebe8c chainntnfs/txconfnotifier: use concrete ErrTxConfNotifierExiting error 2018-07-31 18:23:25 -07:00
Johan T. Halseth
181014c363
chainntnfs/bitcoindnotify: remove all mempool spend clients 2018-07-22 23:09:09 +02:00
Johan T. Halseth
3808105dcd
chainntnfs/btcdnotify: remove all mempool spend clients 2018-07-22 23:09:08 +02:00
Johan T. Halseth
02f7f29b97
chainntnfs/interface_test: remove mempool spend tests 2018-07-22 23:09:08 +02:00
Johan T. Halseth
44d7b84df0
chainntnfs: remove mempool option from RegisterSpendNtfn 2018-07-22 23:09:08 +02:00
Olaoluwa Osuntokun
274687471a
chainntnfs/btcdnotify: switch to async rescan call for historical spend ntfns
In this commit, we modify the way to handle historical spend dispatches
to ensure that we don't block the client for very old rescans. Rather
than blocking and waiting for the rescan to finish (which may take
minutes in the worst case), we'll now instead launch a goroutine to
handle the async response of the rescan.
2018-07-18 01:31:49 -07:00
Johan T. Halseth
07618ca0c6
chainntnfs/interface_test: increase wait time for mempool spends
This commit increases the time we wait for a spend client to notify a
mempool spend from 50ms to 10s. This is done to catch the case where
bitcoind would use up to 7 seconds before notifying about a mempool
spend, which wasn't caught by the test.
2018-07-16 15:08:59 +02:00
Johan T. Halseth
4e47e4e7f1
chainntnfs/bitcoindnotify: filter out mempool spends from relevant txs
This commit fix a bug within the bitcoind notifier logic, which would
ignore the passed mempool argument, and notify spentness whether the
spending transaction was confirmed or not. The logic used to fix this is
similar to what is already done for the btcd backend.
2018-07-16 12:27:05 +02:00
Olaoluwa Osuntokun
80ff2c8d9f
lnwallet+chainntnfs: update neutrino API usage due to recent changes 2018-07-13 17:15:12 -07:00
Olaoluwa Osuntokun
6f60f139f4 multi: switch over import paths from roasbeef/* to btcsuite/* 2018-07-13 17:05:39 -07:00
valentinewallace
8fcd6b56cb chainntnfs: expand test for mempool spend notifications
Make sure new clients get notified about txs that are already in the mempool.

Fixes #1074.
2018-05-01 19:09:56 -07:00
Olaoluwa Osuntokun
005510b54f
chainntnfs/bitcoindnotify: fix possible panic with lack of txindex
In this commit, we fix a recently introduced bug which can result in a
panic when bitcoind nodes without a txindex active are started. The
issue was that we would still defence the transaction's blockhash, which
would be nil if we detected that the backend didn't have the txindex
active.
2018-04-17 20:08:58 -07:00
practicalswift
663c396235 multi: fix a-vs-an typos 2018-04-17 19:02:04 -07:00
Wilmer Paulino
13fb866574
chainntnfs: remove txindex requirement when registering notfications
Before this commit, we relied on the need of full nodes to enable the
transaction index. This allowed us to fetch historical details about
transactions in order to register and dispatch confirmation and spend
notifications.

This commit allows us to drop that requirement by providing a fallback
method to use when the transaction index is not enabled. This fallback
method relies on manually scanning blocks for the transactions
requested, starting from the earliest height the transactions could have
been included in, to the current height in the chain.
2018-04-17 14:59:51 -04:00
Johan T. Halseth
53ec1c6fd2
chainntnfs test: Test historical dispatch for mempool and non-mempool clients
This commit extends the test to exercise a scanario that wasn't properly
covered, by registering for a confirmed spend notification for a
historical spend. We also extend the test to make sure it handles buried
spends properly.
2018-04-16 20:09:17 +02:00
Johan T. Halseth
5d6dd90d18
chainntnfs/btcdnotify: correctly notify on confirmed rescan spends
This commit fixes a recently introduced bug in the btcdnotifier, where
we would skip all spend clients waiting for a confirmed spend in
txUpdates. The regular case where a spend is included in a new block was
correctly handled in onBlockConnected, but the txUpdates queue is also
used for confirmed spends during rescans, which we would miss. This
commit fixes that by checking if the tx update is confirmed or
unconfirmed, and acts accordingly.
2018-04-16 20:09:08 +02:00
Olaoluwa Osuntokun
86ad6d318e
Merge pull request #889 from wpaulino/chainnotifier-updates
chainntnfs: add incremental update notifications within ChainNotifier
2018-04-12 19:21:26 -07:00
Alex
89e2ba41c9 chainntnfs/bitcoindnotify: rescan blocks manually instead of rewinding 2018-04-06 20:35:27 -06:00
Wilmer Paulino
19a2bd9c7d
chainntnfs: send incremental update notifications for tx confirmations
In this commit, we introduce the ability for the different ChainNotifier
implements to send incremental updates to the subscribers of transaction
confirmations. These incremental updates represent how many
confirmations are left for the transaction to be confirmed. They are
sent to the subscriber at every new height of the chain.
2018-04-06 00:30:25 -04:00
Wilmer Paulino
09f8a72897
chainntnfs: modify watched transactions by height to use a set
In this commit, we avoid storing extra copies of a transaction when
multiple clients register to be notified for the same transaction. We do
this by using a set, which only stores unique elements.
2018-04-06 00:30:23 -04:00
Wilmer Paulino
486694a84e
chainntnfs: add Updates channel field to ConfirmationEvent
In this commit, we add a new Updates channel to our ConfirmationEvent
struct. This channel will be used to deliver updates to a subscriber of
a confirmation notification. Updates will be delivered at every
incremental height of the chain with the number of confirmations
remaining for the transaction to be considered confirmed by the
subscriber.
2018-04-06 00:30:19 -04:00
Johan T. Halseth
6b6a616b1e
chainntfnfs test: add testSpendNotificationMempoolSpends for btcd backend
The test is only run for the btcd backend for now, as notifying on
mempool spends doesn't work for neutrino and bitcoind.
2018-04-03 11:24:08 +02:00
Johan T. Halseth
a36683e5e0
chainntfnfs test: check spend notification only on confirmation
This commit changes the chainntnfs tests to adhere to the new
RegisterSpendNtfn signature. It also makes sure that for the test
testSpendNotification, we are only getting notified when a spend is
mined, as previously btcd would notify on mempool inclusion, while
neutrino and bitcoind would notify only on confirmation, and the test
wouldn't catch this.
2018-04-03 11:24:07 +02:00
Johan T. Halseth
9e7e023194
chainntnfs/bitcoind: add bool to RegisterSpendNtfn 2018-04-03 11:24:07 +02:00
Johan T. Halseth
5283b6d210
chainntnfs/neutrino: add bool to RegisterSpendNtfn 2018-04-03 11:24:07 +02:00
Johan T. Halseth
cc17bc1636
chainntnfs/btcd: add logic for mempool argument to RegisterSpendNtfn
This commit adds a boolean to RegisterSpendNtfn, giving the caller the
option to only register for notifications on confirmed spends. This is
implemented for the btcd backend using logic similar to what is in used
for Neutrino, paving the way for later unifying them.
2018-04-03 11:24:07 +02:00
Johan T. Halseth
fa29adf9a3
chainntnfs interface: add mempool argument to RegisterSpendNtfn 2018-04-03 11:24:07 +02:00
Olaoluwa Osuntokun
47a1d3f9e5
Merge pull request #955 from halseth/neutrinonotify-epoch-queue
[small] neutrinonotify: use epochqueue to notify block epochs
2018-04-02 16:23:14 -07:00
Johan T. Halseth
13be19c9ec
chainntnfs/bitcoind: move NotifySpent to after recording the outpoint
This commit moves the call to the bitcoind backend to start watching an
outpoint for spentness to after we have recorded the outpoint in our
list of clients. This is done to avoid a race that we saw using the btcd
backend, and it is probable that it can also happen using bitcoind.
2018-03-28 10:22:41 +02:00
Johan T. Halseth
b08fc05390
chainntnfs/btcd: move NotifySpent to after recording the outpoint
This commit moves the call to the btcd backend to start watching an
outpoint for spentness to after we have recorded the outpoint in our
list of clients. This is done to avoid a race that could occur if btcd
quicly sent a spend notification before we had been able to record it in
our map, essentially losing it.
2018-03-28 10:21:08 +02:00
Johan T. Halseth
891fb20622
neutrinonotify: use epochqueue to notify block epochs 2018-03-28 08:13:10 +02:00
Olaoluwa Osuntokun
a9dc4f80f2
chainntnfs/neutrinonotify: log height hint for spend notifications 2018-03-01 16:49:28 -08:00
Olaoluwa Osuntokun
2a61ccec96
chainntnfs: fix new golang 1.10 vet/test warning 2018-02-19 18:06:35 -08:00
Olaoluwa Osuntokun
9c18c3d9a4
chainntnfs: ensure all block epoch notifications are sent *in order*
In this commit, we fix a lingering bug related to the way that we
deliver block epoch notifications to end users. Before this commit, we
would launch a new goroutine for *each block*. This was done in order
to ensure that the notification dispatch wouldn’t block the main
goroutine that was dispatching the notifications. This method archived
the goal, but had a nasty side effect that the goroutines could be
re-ordered during scheduling, meaning that in the case of fast
successive blocks, then notifications would be delivered out of order.
Receiving out of order notifications is either disallowed, or can cause
sub-systems that rely on these notifications to get into weird states.

In order to fix this issue, we’ll no longer launch a new goroutine to
deliver each notification to an awaiting client. Instead, each client
will now gain a concurrent in-order queue for notification delivery.
Due to the internal design of chainntnfs.ConcurrentQueue, the caller
should never block, yet the receivers will receive notifications in
order. This change solves the re-ordering issue and also minimizes the
number of goroutines that we’ll create in order to deliver block epoch
notifications.
2018-02-09 16:13:28 -08:00
practicalswift
a93736d21e multi: comprehensive typo fixes across all packages 2018-02-06 19:11:11 -08:00
Olaoluwa Osuntokun
ddf4715e3c
chainntnfs/neutrinonotify: fix regression for historical spend dispatches
In this commit, we fix an issue that was recently introduced to the way
we handle historical dispatches for the neutrino notifier. In a recent
change, we no return an error if we’re unable to actually find the
transaction that spends an outpoint. If this is the case, then the
outpoint is actually unspent, and we should proceed as normal.
2018-02-02 17:59:16 -08:00
Olaoluwa Osuntokun
bf6001074c
chainntnfs: fix spend notification registration race condition
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.
2018-01-28 14:48:56 -08:00
Alex
db55569bac chainntfns: stop neutrino service before closing DB in interface_test.go 2018-01-15 13:59:34 -08:00
Alex
187f59556a multi: add bitcoind drivers and tests 2018-01-15 13:59:34 -08:00
Matt Drollette
adf0d98194 multi: fix several typos in godoc comments 2017-12-17 18:40:05 -08:00
Jim Posen
bc7c834362 chainntnfs: Fix stylistic issues. 2017-12-14 19:16:15 -08:00
Jim Posen
280e264e8c chainntnfs: Implement quit signal in TxConfNotifier. 2017-12-14 19:16:15 -08:00
Jim Posen
2639b58e4b chainntnfs: Send negative confirmation notifications. 2017-12-14 19:16:15 -08:00
Jim Posen
c5320f2731 chainntnfs: Test that neutrino rescan plays nice with txConfNotifier. 2017-12-14 19:16:15 -08:00
Jim Posen
abf3685d2d chainntnfs/neutrino: Refactor NeutrinoNotifier to use TxConfNotifier. 2017-12-14 19:16:15 -08:00
Jim Posen
4405dac4d0 chainntnfs/btcd: Refactor BtcdNotifier to use TxConfNotifier. 2017-12-14 19:16:15 -08:00
Jim Posen
122cf3b960 chainntnfs: Unit tests for TxConfNotifier.
Also fix overflow issue with reorg handling.
2017-12-14 19:16:15 -08:00
Jim Posen
d2a9dcf855 chainntnfs: TxConfNotifier struct to implement shared notifer logic.
All implementations of the ChainNotifier interface support registering
notifications on transaction confirmations. This struct is intended to
be used internally by ChainNotifier implementations to handle much of
this logic.
2017-12-14 19:16:15 -08:00
Jim Posen
fa513a76ad chainntnfs/neutrino: Handle block connects and disconnects in order. 2017-12-14 19:16:15 -08:00
Jim Posen
0cac7e80d4 chainntnfs/btcd: Handle block disconnects with chainUpdate.
This does not implement full handling of block disconnections, but
ensures that all chain updates are processed in order.
2017-12-14 19:16:15 -08:00
Jim Posen
28c6a988ca chainntnfs: Test that chain notifiers handle chain reorgs correctly.
Tests are failing for both btcd and neutrino notifiers.
2017-12-14 19:16:15 -08:00
Olaoluwa Osuntokun
839ce0689e
chainntnfs/btcdnotify: add additional logic when dispatching ntfns 2017-12-07 19:09:53 -08:00
Olaoluwa Osuntokun
36c299c1d8
chainntnfs/neutrinonotify: fix early historical confirmation dispatch
In this commit, we fix an existing bug within the logic of the neutrino
notifier. Rather than properly dispatching only once a transaction had
reached the expected number of confirmations, the historical dispatch
logic would trigger as soon as the transaction reached a single
confirmation.

This was due to the fact that we were using the scanHeight variable
which would be set to zero to calculate the number of confirmations.
The value would end up being the current height, which is generally
always greater than the number of expected confirmations. To remedy
this, we’ll now properly use the block height the transaction was
originally confirmed in to know when to dispatch.

This also applies a fix that was discovered in
93981a85c0b47622a3a5e7089b8bca9b80b834c5.
2017-12-07 19:08:48 -08:00
Olaoluwa Osuntokun
d329502e8d
chainntnfs: expand historical dispatch test case to detect early dispatches
In this commit, we extend the existing historical dispatch test case to
detect any instances of early dispatches. This catches a class of bug
within a ChainNotifier when the notifier will *always* dispatch early
no matter the number of confirmations. Currently, this test fails for
the neutrino notifier.
2017-12-07 19:05:40 -08:00
Jim Posen
0297042a8d chainntnfs: Use the new ConcurrentQueue in btcd notifier. 2017-11-16 15:15:22 -08:00
Jim Posen
c9ad9b2269 chainntnfs: Use the new ConcurrentQueue in neutrino notifier. 2017-11-16 15:15:22 -08:00
Jim Posen
726c8b2301 chainntnfs: Implement unbounded concurrent-safe FIFO queue.
This can be used in at least one place in the notifiers to improve
efficiency and reduce complexity.
2017-11-16 15:15:22 -08:00
Sam Lewis
1f95b660b9 chainntfns: Fix off by 1 block height error
In the historical dispatch of btcdnotify, the dispatcher checks if a
transaction has been included in a block. If this check happens before
the notifier has processed the update, it's possible that the
currentHeight of the notifier and the currentHeight of the chain might
be out of sync which causes an off by one error when calculating a
target height for the transaction confirmation. This change uses the
height of the block the transaction was found in, rather than the
currentHeight that's known by the notifier to eliminate this.
2017-11-13 22:36:25 -08:00
Sam Lewis
93981a85c0 chainntnfs: Fix btcdnotify dispatch race condition
This race condition can occur if a transaction is included in a block
right when a notification is being added to the notifier for it AND when
the confirmation requires > 1 confirmations. In this case, the
confirmation gets added to the confirmation heap twice.
2017-11-13 22:36:25 -08:00
Sam Lewis
b3509d491a chainntnfs: Add chainntfs lazy consumer test
This test adds a test for a consumer that registers for a transaction
confirmation but takes some time to check if that confirmation has
occured.

The test reveals a race condition that can cause btcdnotify to add a
confirmation entry to its internal heap twice. If the notification
consumer is not prompt in reading from the confirmation channel, this
can cause the notifier to block indefinitely.
2017-11-13 22:36:25 -08:00
Alex
50d88e7769 chainntfns/neutrinonotify: update driver to comply with BIP 2017-11-02 20:04:07 -07:00
Jim Posen
e9c16845dc chainntnfs: Remove some unnecessary channels in interface_test. 2017-10-19 20:00:16 -07:00
Jim Posen
be7cb08f41 chainntnfs: Rename file with typo in filename. 2017-10-19 20:00:16 -07:00
Olaoluwa Osuntokun
e5f3ee0fb6
chainntnfs+routing/chainview: reduce neutrino.WaitForMoreCFHeaders value
This commit reduces the neutrino.WaitForMoreCFHeaders parameter when
instantiating a neutrino instance as a lower value will allow the tests
to complete more quickly.
2017-09-13 16:46:11 +02:00
Olaoluwa Osuntokun
5044cd6468
chainntnfs/btcdnotify: recognize JSON-RPC error in RegisterSpendNtfn
This commit fixes a prior bug in the logic for registering a new spend
notification. Previously, if the transaction wasn’t found in the
mempool or already confirmed within the chain, then
GetRawTransactionVerbose would return an error which would cause the
function itself to exit with an error.

This issue would then cause the server to be unable to start up as the
breach arbiter would be unable to register for spend notifications for
all the channels that it needed to be watching.

We fix this error simply by recognizing the particular JSON-RPC error
that will be returned in this scenario and treating it as a benign
error.
2017-09-12 17:11:47 +02:00
Olaoluwa Osuntokun
ed7eae819a
chainntnfs/btcdnotify: don't error if tx not found for historical conf dispatch
This commit fixes a prior mishandled error when attempting historical
confirmation dispatches. In the prior version of this code fragment, if
the transaction under the spotlight wasn’t found within the mempool, or
already in the chain, then an error would be returned by
b.chainConn.GetRawTransactionVerbose, which would case the function to
exit with an error. This behavior was incorrect, as during transaction
re-broadcasts, it was possible for transaction not yet to be a member
of either set.

We fix this issue by ensuring that we treat the JSON error code as a
benign error and continue with the notification registration.
2017-09-12 17:06:58 +02:00
Philip Hayes
f0aa186a56 channeldb+utxonursery+lnwire: use lnwire's OutPoint,TxOut serialization 2017-08-25 17:56:50 -07:00
Olaoluwa Osuntokun
9f0efddc20
multi: switch from btcrpcclient to rpcclient 2017-08-24 18:54:24 -07:00
Olaoluwa Osuntokun
671f15383b
chainntnfs: fix a typo 2017-08-10 21:15:38 -07:00
Conner Fromknecht
d1e797451d chainntnfs/btcd+neutrino: close spendChan after send 2017-08-03 17:32:44 -07:00
Olaoluwa Osuntokun
399d9c974f
chainntnfs: ensure ntfn cancellation loop will exit
This commit fixes a slight bug introduced. We now ensure that the
cancel loop always exists if the ChainNotifier has been signaled for a
quit.
2017-08-01 17:14:11 -07:00
Conner Fromknecht
9f85eadde1 chainntnfs/btcd+neutrino: sync epoch cancel 2017-07-31 21:44:23 -07:00
Conner Fromknecht
a9b1af4c73 chainntnfs/btcd+neurtino: unify + sync ntfn cancels 2017-07-31 21:44:23 -07:00
Olaoluwa Osuntokun
c47047c0b8
chainntnfs: extend interface test to ensure initial conf height is correct 2017-07-11 17:38:43 -07:00
Olaoluwa Osuntokun
c5f4049394
chainntnfs: convert ChainNotifier interface tests to use sub-tests 2017-07-04 15:54:45 -07:00
Andrey Samokhvalov
8fa2b95c12 lnd: remove seelog logger
The btclog package has been changed to defining its own logging
interface (rather than seelog's) and provides a default implementation
for callers to use.

There are two primary advantages to the new logger implementation.

First, all log messages are created before the call returns.  Compared
to seelog, this prevents data races when mutable variables are logged.

Second, the new logger does not implement any kind of artifical rate
limiting (what seelog refers to as "adaptive logging").  Log messages
are outputted as soon as possible and the application will appear to
perform much better when watching standard output.

Because log rotation is not a feature of the btclog logging
implementation, it is handled by the main package by importing a file
rotation package that provides an io.Reader interface for creating
output to a rotating file output.  The rotator has been configured
with the same defaults that btcd previously used in the seelog config
(10MB file limits with maximum of 3 rolls) but now compresses newly
created roll files.  Due to the high compressibility of log text, the
compressed files typically reduce to around 15-30% of the original
10MB file.
2017-06-25 14:19:56 +01:00
Olaoluwa Osuntokun
54cb8a05cd
chainntnfs: fix vet error, don't pass lock by value 2017-06-07 17:07:33 -07:00
Olaoluwa Osuntokun
baf769eaf0
chainntnfs/neutrinonotify: fix deadlock when notifying blocks, wait for epoch coroutines to exit 2017-06-07 17:05:22 -07:00
Olaoluwa Osuntokun
625d57aea6
chainntnfs/btcdnotify: ensure block epoch coroutines exit before closing ntfn channel 2017-06-07 17:04:32 -07:00
Olaoluwa Osuntokun
ab2af76b44
chainntnfs: add proper logging for the two last interface-level tests 2017-06-07 17:03:01 -07:00
Olaoluwa Osuntokun
7d30634757
routing/chainview: fix race condition in neutrino implementation 2017-06-06 12:01:24 -07:00
Olaoluwa Osuntokun
9fd70958f4
multi: fix linter errors 2017-06-05 19:45:01 -07:00
Olaoluwa Osuntokun
cbf7cd48f5
multi: update to latest neutrino API changes 2017-06-05 19:41:07 -07:00
Olaoluwa Osuntokun
392a8180dd
chaintnfs/neutrinonotify: add additional logging 2017-06-05 19:08:30 -07:00
Olaoluwa Osuntokun
0050108391
chainntnfs/btcdnotify: fix off-by one error when setting spending height 2017-06-05 19:07:48 -07:00
Olaoluwa Osuntokun
065f646ef8
chainntnfs: add the neutrino implementation to the set of interface tests
This commit adds a new case and proper initialization for the
NeutrinoNotifier implementation, such that it can be tested in-line
with the other implementations for proper behavior conformity.

Due to a delay when btcd sends invs for new blocks, the timeouts for
several of the tests has been extended in order to give enough time for
propagation of the new block.
2017-06-05 19:07:04 -07:00
Olaoluwa Osuntokun
8f81133d6c
chainntnfs/neutrinonotify: add ChainNotifier implementation for neutrino
This commit adds an initial rough implementation father ChainNotifier
interface for neutrino, our new light client implementation. This
implementation largely borrows from the existing BtcdNotifier
implementation. As a result, a follow up commit will perform two
refactoring in order to further consolidate code.
2017-06-05 19:04:56 -07:00
Olaoluwa Osuntokun
49e27c77dd
chainntnfs/btcdnotify: modify logging level from error to warn 2017-05-16 18:46:55 -07:00
Olaoluwa Osuntokun
1b83c6ae16
chainntnfs: update confirm ntfn tests to verify TxIndex+BlockHeight
This commit updates two interface-level tests for confirmation
notifications to check the txIndex and blockHeight advertised to serve
as regression tests for the recent bug fix related to properly setting
these two fields.
2017-05-15 18:20:46 -07:00
Olaoluwa Osuntokun
dfd9f6d1ca
chainntnfs/btcdnotify: fix historical confirmation dispatch bugs
This commit fixes to distinct bugs in the way we previously dipatched
notifications for transactions which needed a historical dispatch.

Previously we would compare transactions when scanning the block using
the `tx.Hash` field. This was incorrect has the `Hash` field is
actually the wtxid, not the txid which should be the item being
compared. We fix this within the second bug fix by actually using the
txid to find the proper transaction.

The second fix has to due with a slight race condition which led to an
off-by-one error when dispatching the historical confirmation. If while
we were dispatching the confirmation, a new block was found, then we
could calculate the wrong block height (off by one) as we were using
the ‘currentHeight’ instead the height of the block which included the
transaction.
2017-05-15 17:47:07 -07:00
Olaoluwa Osuntokun
1b4862d815
lnwallet: use new ChainNotifier API, typo fixes 2017-05-11 15:21:05 -07:00
Olaoluwa Osuntokun
2f0639f1af
chainntnfs: add heightHint to RegisterSpendNtfn+ RegisterConfirmationsNtfn
This commit modifies two of the main methods in the ChainNotifier
interface to be more light client friendly. In order to do so, we now
tack on an extra parameter to the methods: heightHint. This value
represents the earliest known height that the chain should be scanned
when attempting to do a dispatch from historical data.

All tests have also been updated to use these new parameters properly
when excising the expected behavior of each interface implementation.
2017-05-11 15:20:38 -07:00
Olaoluwa Osuntokun
45bbeb8f84
chainntnfs/btcdnotify: properly include SpendingHeight in SpendDetails
This commit modifies the btcdnotify implementation of the ChainNotifier
interface to properly include the height in which the watched output
was spent in the SpendDetail sent as a notification.

The set of tests have also been updated to assert that the proper
spending height is included in received notification.
2017-05-11 15:20:36 -07:00
Olaoluwa Osuntokun
4b15310c08
chainntfns/btcdnotify: eliminate block epoch race condition, use diff cancel channel
This commit fixes a race condition that was uncovered by the race
condition detector surrounding cancelling active block epoch
notifications. Previously we would close the main notification channel
for each client, at tine this would cause a read/write race condition
if an active grouting was attempting to dispatch a notification. We now
fix this use by using a distinct channel for signaling cancellation to
the active grouting, and another to signal cancellation to any
notification observers.
2017-05-05 15:53:20 -07:00
Olaoluwa Osuntokun
a9b8da7c3f
chainntfns/btcdnotify: log error when unable to query for transaction 2017-05-04 17:38:52 -07:00
Olaoluwa Osuntokun
c575107607
chaintnfs/btcdnotify: make cancellation of block epoch synchronous
This commit is meant to fix an occasional flake in the interrogation
tests cause by the async nature of the cancellation of block epoch
notifications. This commit modifies the cancellation to now be fully
synchronous which should eliminate this flake.
2017-04-26 21:17:35 -07:00
Olaoluwa Osuntokun
419c2ac206
chainntnfs/btcdnotify: fix race condition for block epoch clients
This commit fixes a race condition that was introduced while fixing a
lingering bug in the logic to notify block epoch clients. The race
condition would happen as by removing the default case in the select
statement, it was now possible for the client’s block epoch client to
be closed while the routine was attempting a send on it.

We now eliminate this race condition possibility by adding a wait group
to all goroutines launched to dispatch a block epoch notification. With
this modification, the Stop() goroutine will now wait for all other
goroutine to exit before closing the block epoch channels of all
currently registered clients.
2017-04-04 14:20:16 +02:00
Olaoluwa Osuntokun
608b9d96d1
chainntnfs/btcdnotify: fix dropped block epoch notification bug
This commit a bug introduced in the chain notifier while we were
limiting the usage of mutexes within the package. In a prior commit a
default case was introduced in the select statement in order to avoid
the possibility of the main goroutine blocking when dispatching block
epoch notification.

In order to avoid this potentially disastrous bug, we now instead
launch a new goroutine for each client to ensure that all notifications
are reliably dispatched.
2017-04-01 20:13:58 +02:00
Olaoluwa Osuntokun
6b3a258e86
multi: fix formatting issues in packge README's 2017-03-27 16:25:25 -07:00
Andrey Samokhvalov
ee2379775c lnd: fix golint warning which requires to add additional comments 2017-03-13 16:30:23 -07:00
Andrey Samokhvalov
fd97a4bd19 lnd: partially fix golint warnings 2017-03-13 16:30:23 -07:00
Andrey Samokhvalov
143a6e01bb lnd: fix unconvert warnings 2017-03-13 16:30:23 -07:00
Andrey Samokhvalov
f2843dd4c9 lnd: fix gofmt warnings 2017-03-13 16:30:23 -07:00
Olaoluwa Osuntokun
6c81dfad61
chainntfns/btcdnotifier: fix race condition in notifyBlockEpochs
This commit fixes a race condition in the notifyBlockEpochs detected by
the race condition detector. Previously the notifyBlockEpochs function
could cause a race condition when a new caller was either cancelling an
existing notification intent or creating a new one.

We fix this issue by making the call to notifyBlockEpochs synchronous
rather than asynchronous. An alternative would be to add a mutex
guarding the map state. The channel itself is buffered with a good
margin, so there shouldn’t be a huge impact.
2017-02-22 14:51:48 -08:00
Olaoluwa Osuntokun
73cc28d5fb
chainntnfs/btcdnotify: implement spend+epoch ntfn cancellations
This commit minifies the BtcdNotifier concrete implementation of the
ChainNotifier interface to allow callers to optionally cancel an
outstanding block epoch or spend notificaiton intent.

To do this efficiently, we now give each notification intent a unique
ID based on if it’s an epoch intent or a spend intent. We then use this
ID to reference back to the original un-dispatched notification intent
when the caller wishes to cancel the intent.
2017-02-21 01:42:53 -08:00
Olaoluwa Osuntokun
a3319bb21a
chainntnfs: add the ability to cancel spend+epoch notifications
When iterating with the ChainNotifier, it currently isn’t possible to
cancel a non-dispatched yet active notificaiton intent. As a result,
this can be rather wasteful in many parts of lnd which my repeatedly
create a new spend notification depending on if/when a peer is
connected or not.

In order to fix this, we add a new `Cancel func()` field to both the
`BlockEpochEvent` and `SpendEvent` structs. This new closure attribute
allows the caller to cancel the yet-to-be-dispathed event, allowing the
ChainNotifier to free up resources.
2017-02-21 01:42:50 -08:00
Olaoluwa Osuntokun
384fe61e73
multi: fix go vet warnings throughout code base 2017-02-16 19:33:19 +08:00
Trevin Hofmann
40c7bac3aa multi: fix a variety of typos throughout the repo 2017-01-17 17:02:56 -08:00
Trevin Hofmann
a13ac90d46 multi: add link to LICENSE in README license badges (#100) 2017-01-12 16:31:08 -08:00
Christopher Jämthagen
cc4617ca23 chainntnfs: break out of loop once txIndex is found 2017-01-11 15:51:19 -08:00
Christopher Jämthagen
95888613d0 multi: minor fixes for README's 2017-01-11 15:50:22 -08:00
Olaoluwa Osuntokun
4ccdad0d66
multi: add README's for all sub-packages 2017-01-10 15:02:37 -08:00
bryanvu
35cf21733d chainntnfs: exit notifyBlockEpochs upon shutdown
On restarts, notifyBlockEpochs would intermittently attempt to send new
block epoch notifications to clients that had already been shut down,
causing a “send on closed channel” error. This change exits
notifyBlockEpochs upon shutdown so as to prevent this.
2017-01-07 19:39:01 -08:00
Olaoluwa Osuntokun
5affed38fc
multi: update btcsuite API's to latest upstream changes
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.

The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
2017-01-05 13:56:34 -08:00
bryanvu
aa04f82a15 utxonursery: added persistence to transaction output states
Moved transaction states from in-memory maps to persistent BoltDB
buckets. This allows channel force closes to operate reliably if the
daemon is shut down and restarted at any point during the forced
channel closure process.
2017-01-03 16:23:07 -08:00
bryanvu
90ed23e6aa chainntnfs: fixed off-by-one in attemptHistoricalDispatch 2017-01-03 16:23:07 -08:00
bryanvu
def39799c5 chainntnfs: handling for potential deadlocks during system shutdown
If the lnd daemon is shut down while multiple subsystems are attempting
to register for notifications, the blocking of those chain notifier
registrations may cause the daemon shutdown to deadlock. The additions
in this commit allow the registration functions to return errors rather
than potentially deadlock when the chain notifier is shut down.
2017-01-03 16:23:07 -08:00
Olaoluwa Osuntokun
f8711659e6
chainntnfs/btcdnotify: populate full conf details for historical dispatch
This commit modifies the historical dispatch workflow slightly to also
obtain the full block in which the transaction was confirmed we we can
fully populate the full TxConfirmations struct which was recently added
as part of the confirmation subscription API.

With this change, confirmation triggers that a reached while the demon
is down, will now be deliver exactly as if the trigger was reached
while the daemon was up.
2016-12-27 16:44:08 -08:00
Olaoluwa Osuntokun
a09db60a1f
chainntnfs/btcdnotify: update BtcdNotifer to recent ChainNotifier API change
This commit updates the BtcdNotifier implementation of the
ChainNotifier by including the details of a transaction’s confirmation
within the ConfirmationEvent struct sent once a registered txid has
reached a sufficient number of confirmation.
2016-12-27 16:43:58 -08:00
Olaoluwa Osuntokun
00b0c273da
chainntnfs: ConfirmationEvent now returns details of tx confirmation
This commit modifies the ChainNotifier interface, specifically the
ConfirmationEvent struct to now return additional details concerning
the exact location in the chain that the transaction was confirmed at.

This information will be very useful within the new routing package, as
within the network, channels are identified via their channel-ID which
is a compact encoding of: blockHeight | txIndex | outputIndex
2016-12-27 16:43:56 -08:00
Olaoluwa Osuntokun
f29b496b76
chainntfns/btcdnotify: close channels for all epoch clients on shutdown
This commit modifies the Stop method of the default ChainNotifier
client, the BtcdNotifier. We now close the notificaiton channel for all
the currently active block epoch clients in order to give clients a
signal that the entire daemon and possibly the ChainNotifier is
shutting down. This gives clients an extra signal to more thoroughly
implement a graceful shutdown across the daemon.
2016-12-15 13:53:46 -08:00
Olaoluwa Osuntokun
ccf71100fd
chainntfns/btcdnotify: update to newest btcrpcclient interface 2016-12-12 15:57:03 -08:00
Olaoluwa Osuntokun
1e3635b5aa
chainntnfs: properly account for partial historical confirmation dispatch
This commit modifies the recently added logic to the ChainNotifier to:
  1. Fix the off-by-one confirmation error that was missed due a flaky
test
  2. Ensure that partial historical confirmations are properly handled.

The partial hostile confirmation case arises when a transaction already
a non-zero number of confirmations when the notification is registered,
but less than what would trigger the confirmation notification. To fix
this, transaction which have a partial number of confirmation are now
properly inserted into the confHeap, skipping first first phase for
notifications.
2016-12-08 16:16:29 -08:00
bryanvu
909c3f8df9 chainntfs: add checks for previously confirmed transactions and spends
Without these checks, “zombie” notification requests that would never
be dispatched could be registered. This would occur if notification
requests were made for events (transaction confirmation and output
spent) that had already been recorded on the blockchain.
2016-12-08 12:28:15 -08:00
Olaoluwa Osuntokun
7b016fef0a
chainntfns: extend testSpendNotification to test for multi-client dispatch 2016-11-27 19:18:24 -08:00
Olaoluwa Osuntokun
d1f12627d2
chainntfns/btcdnotify: add support for multi-dispatch spend notifications
This commit adds support for dispatching the same spend notification to
multiple clients. This is now required by the ChainNotiifer interface
documentation and will be needed within the daemon in order to support
some upcoming refactors.
2016-11-27 19:17:34 -08:00
Olaoluwa Osuntokun
0bd5c6790d
chainntfns: specify that implementations must support multiple clients
This commit updates the documentation for the ChainNotifier interface
to specify that all implementation MUST be able to support dispatching
the same notification to multiple clients.
2016-11-27 19:16:06 -08:00
Olaoluwa Osuntokun
913504581d
chainntfns: eliminate dead lock possibility when dispatching notifications
This commit fixes a possible dead lock when dispatching notifications
caused by the circular communication between the notificationDisptcher
thread and the main notification thread within the btcrpcclient.

Rather than potentially blocking for eternity on a blocking send,
notifications are now instantly handled by appending the notification
on an unbounded queue then launching a goroutine to signal the
dispatcher thread that a new item is available within the queue.
2016-09-22 19:12:22 -07:00
Olaoluwa Osuntokun
112ad616f6
chainntnfs: remove unnecessary print statement in tests 2016-09-13 15:33:32 -07:00
Olaoluwa Osuntokun
39044cb2fa
chainntnfs: fix recursive loop, add additional logging 2016-09-12 19:07:48 -07:00
Olaoluwa Osuntokun
0873c4da76
chainntnfs: add multi-client txid support for confirmation notifications
This commit adds multi-client support for confirmation notification of
the same transaction. Within the daemon there might be scenarios where
multiple goroutines are waiting for the same transaction to be
confirmed in order to properly fulfill their tasks. Previously if
multiple clients were registered for the same txid confirmation
notification, then only the client who registered last would receive
the notification.
2016-09-12 19:07:16 -07:00
Olaoluwa Osuntokun
e72c52288d
chainntfns: implement RegisterBlockEpochNtfn for BtcdNotifier, add tests 2016-09-12 19:07:08 -07:00
Olaoluwa Osuntokun
4d1a1d2799
chainntnfs: add cross interface implementation tests
This commit refactors the existing chainntnfns package in order to
allow more easily allow integration into the main system, by allowing
one to gain access to a set of end-to-end tests for a particular
ChainNotifier implementation.

In order to achieve this, the existing set of tests for the only
concrete implementation (`BtcdNoitifer`) have been refactored to test
against all “registered” notifier interfaces registered. This is
achieved by creating the concept of a “driver” for each concrete
`ChainNotifer` implementation. Once a the package of a particular
driver is imported, solely for the side effects, the init() method
automatically registers the driver.

Additionally, the documentation in various areas of the package have
been cleaned up a bit.
2016-09-01 19:13:10 -07:00