Good news, looks like the behavior of debug logs back then was to append new sessions, not overwrite them. given this, looks like Hal started up his bitcoin client three times, synced a bit in the first, and failed to do so in the 2nd and third attempts. cool.

#define printf OutputDebugStringF

Then OutputDebugStringF() opens the log like this:

FILE* fileout = fopen("debug.log", "a");

That "a" mode is append mode, not overwrite mode. The function writes with vfprintf() and closes the file each time. So, under the same binary, same working directory, and same debug.log, a second startup should add to the bottom of the existing log, not erase the first run.

There is one subtle thing: on startup the client prints a large block of blank lines and then:

Bitcoin CMyApp::OnInit()

So a second startup could visually look like a “fresh” section of log because it begins with lots of blank space. But the older log content should still be above it unless the file was manually deleted/truncated, the program was launched from a different working directory, or Hal was using a different/debug build setup.

The nearby comment about “deleting log.*” is probably not about debug.log. It appears in the startup code as a database-protection note, and the DB code separately configures Berkeley DB logs under a database directory and uses dbenv.log_archive(... DB_ARCH_REMOVE) during shutdown cleanup.

So my conclusion:

The “second startup wiped the first debug.log” theory is not supported by this codebase.

Yeah I know, I am talking very fast + accent about cryptography, networking, consensus and other low level technical things, its normal to not get all of it.

Thing is if i would slow down and bring more context, the video would be 30m.

The video was meant to be like a commercial for the research paper.
Here everything is explained clearly and you can take your time.

https://1stbitcoinminer.com/

FWIW, if you would show this video to me 1 year ago, I would also not be able to follow.