In this commit, we remove the duplicate test case from TestStoreQueries
as we'll no longer allow storing a transaction as unconfirmed if it's
already confirmed.
In this commit, we resolve a lingering bug within the wallet where it's
possible that an output is added as unconfirmed credit after the fact
that it has already confirmed. This would lead to duplicate entries for
the same output within the wallet causing double spend transactions to
be crafted.
In this commit, we add a new test case to the wtxmgr store to ensure
that duplicate outputs don't exists within the store. It's possible for
this to happen if an output is marked as unconfirmed credit, then marked
as confirmed once it confirms, and once again marked as unconfirmed. It
can be marked as unconfirmed again due to the backend notifying the
client about this transaction. Ideally this should not happen, but the
root cause is much more involved. As a stop gap, we'll ensure that
outputs can be marked as unconfirmed credits more than once whatsoever.
As is, the test case fails, which proves that this is an issue. A later
commit will resolve this and the test case should pass.
In this commit, we remove the keep-alive logic within the handler of the
RPCClient struct as this logic already exists within the backing
rpclient.Client instance. In this case, we'd completely stop the
connection after the ping timeout (1 min), which would render the
reconnection logic within rpcclient.Client useless.
In this commit, we fix a small issue where it's possible that we read a
malformed message from the ZMQ connection to bitcoind due to it shutting
down. To fix this, we ensure that the event type is human readable
before attempting to log it.
In this commit, we add the new DerivationInfo method to the current
default implementation of the ManagedPubKeyAddress interface. In doing
this, we replace the account field with the derivationPath, as we can
obtain the account field from the derivationPath itself.
In this commit, we add a new method DerivationInfo to the
ManagedPubKeyAddress interface. This method is meant to provide callers
with the information necessary to independently derive each key returned
by the various methods provided to derive addresses.
In this commit, we alter the behavior for handling chain notifications
within the wallet. The previous code would assume that the channel would
close, but due to now using a ConcurrentQueue to handle notifications,
this assumption no longer stands. Now, we'll stop handling notifications
either once the wallet has or stopped or once the notifications channel
has been closed.
In this commit, we extend the client's filtering process to also look at
the set of currently watched transactions. The logic to watch for
transaction hashes was previously there, but it was not used to filter
against incoming transactions.
In the previous commit, we modified our BitcoindClient struct to use a
ConcurrentQueue struct to handle its notifications to the caller. Before
this, the BitcoindClient had a goroutine that would handle these
notifications in the background and detect when a OnBlockConnected
notification was received in order to update the best block. Due to this
logic being removed, we now keep track of the best block througout the
struct as a whole.
In this commit, we update bitcoind to also accept a mapping from
outpoint to address for its implementation of the recan RPC. We do this
as in the near future, when bitcoind implements BIP 158 indexing, then
we'll be able to utilize that to do rescans.
In this commit, we fix a recently introduced bug that would cause
callers that attempted to get a spend notifications for a particular
outpoint to no longer get that precise notification. In a prior commit,
in preparation for the new neutrino gcs filter format, we added a
mapping from script to outpoint that will be used by neutrino, and later
other backends as well. However, we still need to match on outpoint
slices for bitcoind today.
In this commit, we update the Rescan call in the interface to map the
outpoint to the address that the outpoint holds. We do this as BIP 158
has recently been updated to match on the prev output script rather than
the outpoint itself. Additionally, in the near future, btcd (then
bitcoind), will switch over to using the BIP 158 filters internally,
which will also match on the output scripts.
In this commit, we modify the way we store spending transaction hashes
for unconfirmed spends. Now, rather than only keeping track of one
possible unconfirmed spend, we track multiple in order to ensure we
properly handle transaction replacements, like in the case of RBF,
double spends, etc. With this in, the double spent tests recently added
should now pass.
