Commit Graph

143 Commits

Author SHA1 Message Date
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