Skip to content

Mining bugfix: Properly initialize `g_best_block` at startup


This MR fixes the bug in issue #189 (closed). The global variable g_best_block was not properly initialized at app startup. It would get initialized later after a new block arrives from the network, however.

This is a bug affecting Core, BCHN and ABC. BU does not have this bug.

More background, from issue #189 (closed): It was observed that when using the longpoll version of getblocktemplate, and if the node was freshly started, that the node would return results right away. The longpoll spec says that if the client provided a longpoll id, the node should wait until a new block has arrived, or until 60 seconds have elapsed and there are new transactions. This was not happening here.

The reason? g_best_block was uninitialized!

This MR ensures that g_best_block is initialized and is not 0000...000 at app start, if we have a chain tip. Thus the invariant is guaranteed and no bugs on first run.

Test Plan

  • ninja check check-functional
  • Also if @ago is around -- please try this branch and ensure it fixes the observed bug.
Edited by Calin Culianu

Merge request reports