Why did you asked again?
You've posted the same question in September: Bitcoin wallet: Sept 23.

You can start by telling us your intention or goal,
that way, we can have an idea and be accurate with our suggestions.

For now, that "wallet.dat" file doesn't contain any Bitcoins in it;
as others told you in your previous thread, it contains the private keys to control (your) unspent outputs in the blockchain.
So you wont be able to see your balance just by opening the wallet file or loading it to another program that doesn't have any sort of connection to Bitcoin blockchain (ex. nodes).

Was your example based from your experience?
Because usually, that only happens when the remaining amount from one input isn't enough for the fee.
But the example wont fall to that category, for a 0.08 UTXO & 0.06 to send, the change is quite too high for the tx fee.

If it's something like 0.005 UTXO and 0.00495 to send, the wallet might include one more input to the transaction.

Crap, that was my initial idea (last supper in birthday setup)
Gotta move to plan B.

BTW, there's a typo in your post: "liking", I think you meant "licking"  

I agree on the latter.
The first one sounds more like the "current total supply"; but if we're talking about "in circulation", it must be the actively traded coins.

Although, exchanges and custodial payment processors are taking part in this "circulation", there's no on-chain transactions involved with trades done though them.
Take that in consideration.

---

For your problem: try to run a full node and use getchaintxstats command.

Try to set it after closing local-blockchain-parser and all of its background process(es).

Of course it will, there will be no dat file directory.
If just the "r", I have no other idea aside from you've given the wrong path.

I haven't used that parser but you need to know that most of them are incapable of parsing blk.dat files with SegWit data in it.
Somewhere around blk00971.dat+.

I know one that allows the clients to clam 100sat @max 20times a day.
But the user must deposit at least once first, otherwise, it's only available when the user has 0 balance.
The name's isn't something like "free" or "faucet" (not gonna say the name).

But I agree, there's a difference.
^ That's a "casino with faucet" because here's the catch: There's an ambiguous rule "do not abuse the faucet" that sounds like "do not claim too often" (affiliate program doesn't count to that abuse since faucet claims won't even count).
On the other hand freebitco.in still functions as a faucet if you ignore the other tabs, newly created accounts can go straight to free roll.

You might have written an extra "r" to your Bitcoin blocks directory during the initial setup of the parser.
There shouldn't be any "r" folder there unless you've created one and moved your blocks dir.
According to the "readme", you can change it by editing the "wlff-blockchain.json" file from local-blockchain-parser's installation directory.

BPIP's database must have updated, you've visited the site 12hrs after my post.

There's no one discussing "that" (it's for reference and a possibility that his account was reset), only you brought up the topic
And as a supposed to be "last post": I suggested him to post or move this to meta and ask the mods about what exactly happened to his account.

You should (both) know that there's a checksum with bitcoin addresses.
If there's a typo, the chance that the address will be invalid is too high that you wont be able to proceed to sign/send.

Plus it's designed to be manually written and typed with ease (Base58).

Where did he mentioned it's standard
What pooya meant by "no" was already written in his reply: he said "invalid", what his "no" means isn't standard.
But later, it's countered by the link in my post.

P.S. Yes, most non-standard TXs wont be relayed but invalid TXs can't be mined.

That wont do, most users don't know how to convert private key to WIF, some don't want to use converters or tools to convert it to WIF.
Lastly, almost all (Bitcoin) clients do not support non-WIF private keys.

1. It's shorter and the identical characters are omitted, so it's still "cool".
2. Why don't you just add an option/default option to convert prv key to WIF for coins like BTC? The conversion isn't that complicated.

Well, it's originally posted in Bitcoin Technical Discussion so I assumed that this is client or service-related topic.

There's no other "belchem" user aside from that newbie account either.
But in BPIP (https://bpip.org/profile.aspx?p=Belchem), it said below that you had 52 posts but not deleted by mods.

Better move this in Meta and ask the mods what happened.

I'm not confident with networking settings in bitcoin.conf but try to use these settings.

Connect to this node exclusively (use instead of addnode):
Maybe it's disconnecting because the old version is misbehaving, try any of these:

Also, make sure that bitcoind isn't running in the background while editing your config file.

I'm having trouble understanding this "belchem acompt", could it be "blockchain account"?

You've also mentioned "Lv1" so it must be an exchange/custodial wallet.
If so, they (the exchange/wallet) are the only one who can help you; you must contact their support.

If you're having trouble with English, you can post in your local language board: Local

Aside from the post above, you can also click the author's profile and check "last active" date.
Just by looking, you'll know if the pool operator is still active.

Most of the threads may be inactive, but not the topic starter.

What is this? To "hide" the funded multisig address from them? If so, it won't work.
If they plan collude, they can still make a transaction by re-creating the multisig address & redeem script using their wallet's public keys.
It's possible online (coinb.in), through Bitcoin Core, etc.

This is the best solution to OP's "security issue":

Figures, the timing and scenario look identical.
How about small mining pools? All you need is to get it included in a block, even an average 1-block per month pool will do.

There are tons of threads in reddit about it and there's one with a reply from Pieter Wuille:
Created SegWit Address with Uncompressed
(don't want to click?) It said that it's not against the consensus rues but the transaction was indeed non-standard that's why nodes are rejecting it.
So it's possible to spend if a miner will include it to a block.

A single miner doesn't have enough hashrate to solo mine BTC, almost all of them are connected to a pool.
Just PM/Reply to some of the Bitcoin mining pools operators here in the forum: Mining->Pools.
They don't usually wander in this part of the forum.

Also the "decryption table" below,
you're accidentally giving away clues that those characters pointing to invalid characters shouldn't be used.
(read my post above)

You get what I mean?

IDK what you're making but it's so wrong in so many levels.

First, it's missing 14 characters (not 13)  
Next, looks like the private key is in compressed WIF format which should be in base58 encoding,
means that there shouldn't be any zero, capital "o", lower-case "L" and capital "i" in the list; but there's an "O" and a "0" in the table.

Lastly, why all caps? Is your 1C2SvZUDaSr6zzTTZr7vNeCo5jbz1bwiGe address' WIF private key all-caps?