bitcoind v25.0 updated the `sendrawtransaction` RPC to have an optional
argument `maxburnamount` with a default value of 0. This means our
existing test that uses burning output cannot be published, hence, we
remove the usage of it in our tests and replace it with a normal tx.
We should not fail to start the node if a republish attempt failed for a
channel's closing tx. Instead, we log an error to continue the startup
and let other channels continue their operations.
Previously, `PublishTransaction` in `btcwallet` will first mark the tx
label in db first before broadcasting it to the network. Even though the
broadcast may fail with the error already in mempool or already
confirmed, this tx label updating is still performed. To maintain the
old behavior, we now catch the errors from `TestMempoolAccept`, and make
sure to call the `PublishTransaction` to mark the tx label even there
are errors from mempool acceptance check.
This commit adds a mempool acceptance check before broadcasting a given
transaction. To maintain the current behavior from
`BtcWallet.PublishTransaction`, the two errors, `ErrInMempool` and
`ErrAlreadyConfirmed` returned from `TestMempoolAccept` are ignored.
This builds on the concurrent queue to create a generic way to allow
goroutines to pub/sub information. An example includes being notified
each time a state machine is able to carry out a new state transition.
We do things this way to keep behavior consistent across REST, gRPC
and CLI consistent. This was done to not alter the way we handle
Recv calls from the streams.
This commit fixes a heap escape found in `GetBlock`. This happens
because the `msgBlock` is a pointer returned from `getBlockImpl`, and
the whole `getBlockImpl` escapes to the heap because it's referenced in
two places,
- in the `Cache`, it's used as a reference type to create the new block.
- this pointer is also returned and now needs to stay on the heap.
The fix is simple, we now make a copy of the block and use the copy
instead, freeing `getBlockImpl` from the heap.
The error was never used as the init couldn't return an error, so we do
away with that. We also modify the main event loop dispatch to more
closely match other areas of the codebase.
In this commit, we make all calls to disconnect after a ping/pong
violation is detected in the `PingManager` async. We do this to avoid
circular waiting that may occur if the disconnect call back ends up
waiting on the peer goroutine to be torn down. If this happens, then the
peer goroutine will be blocked on the ping manager fully tearing down,
which is blocked on the peer disconnect succeeding.
This is a similar class of issue we've delt with recently as pertains to
the peer and the server: sync all back execution must not lead to
a circular waiting loop.
Fixes#8379
