Seemed okay.
The only minor log warning was about the ban list file, which changed to JSON format in v22.


By the way, one unrelated oddity are a few stray random-looking but fixed characters at the end of some log lines, in the "init message" phase.

Curiously, the UTXO set size has stabilized since about 5/2024, with a minor peak on 12/2024.
The rate of new inscriptions has slowed down, but I'm not sure that's the only reason. There's a local increase in the rate 2 months ago but it hasn't negatively affected the UTXO set size, which actually dropped a bit.

Inscriptions per month:
2024/01 6.51M
2024/02 3.62M
2024/03 4.08M
2024/04 3.67M
2024/05 0.61M
2024/06 0.93M
2024/07 1.52M
2024/08 1.46M
2024/09 1.14M
2024/10 0.68M
2024/11 1.73M
2024/12 2.51M

2025/01 2.84M
2025/02 4.19M
2025/03 3.76M
2025/04 ...



https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&from=1672524000000&to=1745009999000

Of course, finding the latest version is easy, and it's not through the forum.

Just thought that if it's indicated here, best keep it current.
It's surprising it's not automated, but if so, if not updated manually quickly, it might be best to just remove the indication.

If it won't be capable of converting it as needed, that's a surprise.

Too bad there's no all-in-one changelog.

Yes, though depends on your set prune size.

Though I'm wondering more about potential "silent" problems.
In theory, one would expect it to explicitly alert if something's not compatible, leave the data be, and exit gracefully.
Core is typically pretty elaborate in data compatibility checking, and logging / alerting.

In terms of wallet, chainstate, and block data, is it okay to update across versions years apart?

Specifically, from version 0.18.x to 28.x, which are 5-6 years apart.
With pruned block data.

It says 28.0.

The latest is 28.1, since two months ago.

Is there someplace to see per-block stats, like how many block outputs are Inscriptions, or the percentage of block data?

Did BRC-20 and Inscriptions become possible at the same time?

FWIW, these seem to be the number of Inscriptions per month:
2022/12 3
2023/01 445
2023/02 218K
2023/03 444K
2023/04 2.03M (the pace picked up more on 4/22)
2023/05 7.66M
2023/06 3.99M
2023/07 6.45M
2023/08 6.83M
2023/09 7.28M
2023/10 1.81M
2023/11 8.34M
2023/12 7.64M

BTW, these things are ridiculous.

Since 4/2023 the chainset/UTXO set size started to increase much more rapidly than all years before.
What's going on?

While the exact size varies between node instances, here's one node as reference. From a peak of a 34% increase between 2019-2020, and an average of 15% per year between 2019 and 2023, the year that ended now saw an increase of 100%, and a rate increase since the last week of April or so:


There's no corresponding increase in blockchain size:


While the rate of increase in blockchain size did change since 2/2023 (not sure why, Ordinals?), an apparent increase in average block size from maybe 1.2MB to 1.7MB, it's nowhere near the change in UTXO set size. Also the start date is misaligned.

Easier, but misleading.

Thanks.

While it quit automatically due to the abnormal condition, it's still a graceful exit as evident by having everything logged until the end.

But it was on an older version. Maybe fixed in newer ones.

After "reconsiderblock" it's fine, but not without it.


So it's sort of a bug or anti-feature in the case of non-wallet commands.

After a cursory look, it seems it may be possible to filter based on CRPCCommand.category.

In a multi-wallet file configuration, I executed "reconsiderblock".
The console said "Executing command using ... wallet", making it appear only one is affected.
I chose another wallet file and executed the same command again.

Despite of what it says, does it only affect the single selected wallet or all of them?

If just one, what are the implications?


Background:

This is on v0.18.

Core crashed during catching up due to no more free space for the UTXO db.
I fixed the space situation and restarted.
It recovered and continued syncing blocks for about a minute, then appeared to stall doing nothing.
The log revealed repeated "ERROR: AcceptBlockHeader: block ... is marked invalid" for the same block.
I restarted, the same situation continued, so I reconsiderblocked.

Had something similar happen, with repeated "ERROR: AcceptBlockHeader: block ... is marked invalid".
It was on Litecoin Core 0.18, not Bitcoin Core, but the fix was the same.

The only strange thing that had happened in proximity was a previous out of space crash for the cachestate.
But a following run did sync new blocks for a minute or two, before hitting "marked invalid", so maybe it was unrelated.

I didn't mean to imply that's abnormal.

Maybe if the whole chainstate is rewritten, there's opportunity to check for complete consistency. Not that I know that it does that.

Anyway, I'm going to leave it be. The wallet state is as I expect it to be, and it seems to work. A pre-crash wallet backup should suffice. Worst case I'd have to do a fresh IBD from scratch, which would be a pain, but doable.

It would be more reassuring if, when restarting post-crash, Core would explicitly indicate that it's aware of the previous crash and that it checked or recovered successfully. I don't know, maybe it already does that in newer versions (considering I'm on 0.18).

If that's the case it should show also the 0+ stats line. As it is, the numbers just look wrong.
A few months back, before the redesign, it looked correct.

I didn't run with any special commands, and can't run a full reindex because it's pruned mode. But if it's localized to one or two files, and Core can detect it, then I guess no harm done and the usual startup rewind-rescan can handle it.

BTW, I never understood how chainstate is stored, but it seems every run touches most to all files, based on file modification times.

It crashed with apparent C++ exceptions, though maybe with some cleanup afterwards.
LevelDB might keep the records valid, but what about Bitcoin-level consistency?

The logged error messages are (summarized, some lines were repeated):


The second crash had less lines, less repetitions, no "Releasing wallet", and one new lines:

When choosing the non-default BTC mempool on Johoe's site, the hover table strangely shows a wrong "total".
Though not a big deal. Just need to mind the "1+" line above it.

I just want to continue using it normally.

I fixed the out of space issue, restarted Core and let it continue catching up with the blockchain, and it seems to work.
The space issue affected only the chainstate, not the blocks (it runs in pruned mode).

But I do wonder if there may be some inconsistency in the chainstate or block data, despite the fact that it doesn't complain and everything seems to work fine.


By the way, I've had it crash twice due to disk space. The second time the GUI's error message complained about something else, maybe a block hash mismatch, but the log only mentioned LevelDB running out of space.

Bitcoin Core (0.18) crashed due to chainstate LevelDB hitting "not enough space".
A restart seemed to have worked without a hitch. I think not even a hint in the log file (after the restart, not the previous crash run).

Is it absolutely safe as far as data consistency is concerned, or is it better off to continue from a backup?

EOS withdrawal is close to $1. Bad, but not as bad as the rest there.

The USD value of others varies: BTC about $50, LTC $20, ...