In this commit we document an unexpected behavior found when connecting
a bitcoind node to a btcd node. We mitigate this in our test by
reconnecting the nodes when the connection is broken. We also limit the
connection made from `bitcoind` to be v1 only.
We need to check `dispatched` before sending conf details, otherwise the
channel `ntfn.Event.Confirmed` will be blocking, which is the leftover
from #9275.
Find and replace all nolint instances refering to the `lll` linter and
replace with `ll` which is the name of our custom version of the `lll`
linter which can be used to ignore log lines during linting.
The next commit will do the configuration of the custom linter and
disable the default one.
This commit adds a new state to the `ConfNtfn` struct to start tracking
the number of confs left to be notified to avoid sending duplicate
notifications.
This commit fixes a bug where the confirmation details may be missed.
When the same tx is subscribed via `RegisterConfirmationsNtfn`, we will
put them into the same set and notify the whole set. However, this logic
is missing when performing the rescan - once the confirmation detail is
found, we only notify the current subscriber. Later we will skip
notifying other subscribers in `UpdateConfDetails` due to the
`confSet.details != nil` check. We now fix it by immediately notify all
the subscribers when the confirmation detail is found during the rescan.
This commit changes the order of notifications when a relevant tx is
found in a block and now we will always notify the tx subscribers before
notifying the block, which has implications in the upcoming blockbeat.
When a block notification is subscribed via `RegisterBlockEpochNtfn` and
a confirm or spend is subscribed via `RegisterConfirmationsNtfn` or
`RegisterSpendNtfn`, we would always notify the block first before the
tx, causing the subsystem to think there's no relevant txns found in
this block, while the notifications are sent later. We now fix it by
always sending the txns notifications first, so the subsystem can
receive the txns, process them, then attempt to advance its state based
on the block received.
With this PR we might call the stop method even when the start
method of a subsystem did not successfully finish therefore we
need to make sure we guard the stop methods for potential panics
if some variables are not initialized in the contructors of the
subsystems.
This commit adds `TxPublisher` which implements `Bumper` interface. This
is part one of the implementation that focuses on implementing the
`Broadcast` method which guarantees a tx can be published with
RBF-compliant. It does so by leveraging the `testmempoolaccept` API,
keep increasing the fee rate until an RBF-compliant tx is made and
broadcasts it.
This tx will then be monitored by the `TxPublisher` and in the following
commit, the monitoring process will be added.
sweeper
This commit implements a new method, `LookupInputMempoolSpend` to do
lookups in the mempool. This method is useful in the case when we only
want to know whether an input is already been spent in the mempool by
the time we call.
This commit changes how a new input sweep request is handled - now we
will query the mempool and see if it's already been spent. If so, we'll
update its state as we may need to RBF this input.
Because we pass in the same config into multiple notifiers, we sometimes
get a data race in the unit tests. By creating a copy of the config we
avoid that.
With the chainntnfs.NewMiner now being optimized for not creating
nodes with colliding ports, we use it in all unit tests that spin up
temporary miners.
This commit fixes a number of issues with our temporary bitcoind nodes
that we spin up for unit tests:
- We didn't remove the node's temporary data dir after tests finished.
- We used random ports which lead to unwanted port collisions.
- We used ipc:// unix sockets for ZMQ which currently isn't supported
in bitcoind v26.0 due to a regression. Since we can reliably create
new non-colliding ports now, we should use TCP for ZMQ anyway.
Fix the following uint test flake,
```
--- FAIL: TestHistoricalConfDetailsTxIndex (0.00s)
--- FAIL: TestHistoricalConfDetailsTxIndex/rpc_polling_enabled (1.16s)
bitcoind_test.go:174: should have found the transaction within the mempool, but did not: TxNotFoundIndex
FAIL
```
Noticed this while updating to latest master in another project:
If there are two notifications for the same output being registered and
the first one does _NOT_ request the block to be included, then the
second one also will not receive the block, even if it explicitly
requests it.
This is caused by the block being removed from the original confirmation
set instead of a copy (as it is done in NotifyHeight and
UpdateConfDetails).
