`bitcoind` notifies transactions once they're accepted into the mempool
and once they're confirmed in a block. Previously, reading a message
from ZMQ would allocate a buffer with the size of the message. This can
cause nodes to perform a large number of allocations within a small
amount periodically (3000 300B allocations every 10 mins on average),
which can cause a lot of GC pressure on lower resourced nodes. To remedy
this, we introduce two static buffers, one for blocks and another for
transactions, that will be reused for every message read. Each is
constrained by its maximum expected size.
Since it's now possible for gozmq.Conn to block when calling Receive,
BitcoindConn hangs upon being stopped because its goroutines are waiting
for a message to be delivered. To address this, we modify it to close
its ZMQ connections driving the goroutines once it's been stopped. This
allows the goroutines to unblock by detecting the EOF error and exiting.
One could argue that the behavior before this commit was incorrect, as
the ChainClient interface expects a call to NotifyBlocks before
notifying blocks at tip, so we decide to fix this.
Since we now wait for the chain backend to be considered "current"
before proceeding to sync the wallet with it, any blocks that were
processed while waiting would result in being notified and scanned
twice, once by processing it at tip, and another while rescanning the
wallet, which is not desirable.
Since defer will copy the function with the parameters evaluated at its
invocation, the RescanFinished notification would be dispatched with the
incorrect block. To fix this, we'll just send the notification at the
end ourselves manually.
In this commit, we address a bug within the wallet when running with
Neutrino where it wouldn't be able to mark it as synced with the chain
due to not receiving a RescanFinished notification if it was a block
behind the chain. This happened because of the order in which the
notifications are delivered within the underlying Neutrino ChainService,
FilteredBlockConnected gets dispatched before BlockConnected. This
doesn't always work however because there is an implicit dependency
between them in which BlockConnected must occur first.
To address it, rather than switching the order in which the
notifications are dispatched, we just check if we can dispatch the final
RescanFinished notification after dispatching BlockConnected.
Co-Authored-By: Roei Erez <roeierez@gmail.com>
In this commit, we extend the BitcoindClient to properly detect the
spend of an arbitrary script on-chain. This is possible by looking at a
transaction's input and re-deriving the PkScript, from its signature
script/witness, of the output it's attempting to spend. Upon detecting
the spend, a chain.RelevantTx will be dispatched.
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 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.
