It's possible for bitcoind instances to only have connections to pruned
nodes after its initial block download, which are incompatible with the
PrunedBlockDispatcher. This would result in GetBlock requests for pruned
blocks to never resolve. Since bitcoind also exposes a GetNodeAddresses
RPC, which returns random reachable addresses from its address manager,
we can leverage it to obtain a new candidate set of peers that we
otherwise wouldn't obtain through GetPeers.
As reported by https://github.com/lightningnetwork/lnd/issues/5196, the
new atomic integer isn't properly aligned which can caus panics on
32-bit operating systems.. Tof fix this issue, we move the 64-bit
integer to lay after the two 32-bit integers at the top of the struct.
`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.
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.
