Thanks.

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

Did BRC-20 and "general" Inscriptions both become possible from day one, once the feature was introduced?

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 a size increase of 100%, and a big 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?), due to 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.

Interesting that the reported out of space condition there is also on writing to the chainset.
And also there reconsiderblock is reported as being good enough.

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. Yet it always happens when out of space, so evidently the cleanup isn't good.

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

After "reconsiderblock" it's fine as far as I can tell, 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 decide whether to show that "current wallet" console message 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 being out of space for the UTXO db. I fixed it and restarted.
It recovered and continued syncing blocks for about a minute, then stalled doing nothing.
The log revealed repeated "ERROR: AcceptBlockHeader: block ... is marked invalid" for the same block.
I restarted, the same situation continued, so I executed "reconsiderblock".
It seemed to resume okay.

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

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.

The chainstate directory here is separate from where the log is.

I will update eventually, maybe when v22 is out. It's just that so far there weren't any improvements that are obviously useful to me, and I'm usually going for "leave it be if it's not broken".

Cool, didn't know about the minimum parameter.
Though, even with that enabled the total is wrong.

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

Maybe if the whole chainstate is rewritten there's opportunity (not that I know that it does that) to check for complete consistency, or at least no data corruption.

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.

How do you know, by the way? Did check the source code?

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 practically all chainstate 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, and one new line:

Although it did follow the above with some thread exit messages, there was no "Releasing wallet" message, but maybe I copied the log file before it fully flushed.

FWIW, later, after it finished syncing the blockchain, I tried a restart and it did not complain about anything.

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 instead the "1+" line above it.

I just want to continue using it normally. The backup, if needed, includes the chainstate and block data.

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".
Freeing up some space and restarting 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 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 (and BCH!) about $50, ETH $45, LTC $20, XMR $14, ...

That fee comparison site missed the fact that HitBTC also handles XRP, but their XRP withdrawal fees are bad as well: 12.8 XRP = $18.

It's not EOS that I dislike, but the direct exchange-to-exchange transfer.

Can anyone suggest a strategy to exit HitBTC through less common coins, and maybe this way avoid their extremely high withdraw fees?

I'm not comfortable doing exchange-to-exchange transfers, but I don't see another way. I'm thinking maybe EOS, where their fee is 0.1 = about $1.

Many exchanges are bad, but HitBTC is another level of bad. Litecoin withdrawal fee of 0.0530'0000!
That's currently $20. It appears to be the worst of all exchanges.

It's about x2,000 the official fee (official minimum tx fee is 0.0001'0000 per KB, and txes might be 1/4 KB on average), and x20,000 the rate needed in practice (Litecoin's network is never choked, 0.0000'1000 per KB works fine).

Some QLC drives are even worse. Corsair MP400 has 200 TB TBW for the 1TB model. I'm not aware of small QLC drives currently, but that might change.

I symlinked only the chainstate directory to the SSD, then watched the drive's SMART stats.
(Maybe there's also a configuration switch to specify the chainstate directory separately from the whole data dir?)

That 2.4GB/day I'm seeing is "client writes" from the PC. I haven't checked yet SSD write amplification. And would be interesting to compare to a non-pruned node.

Assuming 2.4GB/day, that's approaching 1TB/year without block and index data, and ignoring WA. If you're not testing multiple full IBDs maybe it's acceptable, but it's not great, especially if you use the SSD for more than just Bitcoin Core. And it isn't inherently "needed", it's just a side effect of the write caching problem.

Some 120GB SSDs, like the Crucial BX500 or Kingston A400, have only 40 TBW. Twice that much in the 240GB models. A nice mid-ranger like the MX500 500GB has 150 TBW.

4GB is more or less its current storage size, but Core does a whole lot of small fragmented writes there while running. At least in pruned mode.