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
When the link is flushing in the incoming direction, it means
adds are invalid. The best chance we have at dealing with this
is to drop the connection. This should roll back the channel
state to the last CommitSig. If the remote has already sent a
CommitSig we haven't received yet, channel state will be
re-synchronized with a ChannelReestablish message upon
reconnection and the protocol state that caused us to flush
the link will be rolled back. In the event that there was some
non-deterministic behavior in the remote that caused them to
violate the protocol, we have a decent shot at correcting it
this way, since reconnecting will put us in the cleanest
possible state to try again.
