Why are you using -loadblock=boostrap.dat?
Have you downloaded a bootstrap file containing the full blockchain? Asked this because you've mentioned that you "started from scratch".
If you didn't intended to use -loadblock, I'd suggest you to just let the node sync normally by skipping that command line option.

Also, try to set the default start-up block verification first and just change them to your preference later once it's stable.
Specifically: checkblocks="24" which is set a bit high from the default (6) and checklevel="0" which skips all verification of checkblocks.

If you can afford to discard the 20GB of already downloaded blocks and since -reindex didn't work, you can try to start with fresh datadir.
(backup your current datadir before doing so)

This must have happened because your coins from 2010 are locked in P2PK (pay-to-public-key) script which doesn't have an address.
So, by importing only the address, you'll only be able to see those new coins in P2PKH (with the address start with '1').
If you want to scan your coins from 2010 properly, import its public key.

You can use Bitcoin Core in offline and online machines to create a cold-storage set-up for safety reasons:
[Offline Machine]

• Open Bitcoin Core, create a New wallet with "File->Create Wallet..."
• Tick the options "Make Blank Wallet", "Descriptor Wallet", (enable encryption if you want) and create the wallet
• Open the console, make sure the wallet's name is selected in the console's "Wallet:" drop-down menu
• Type the command: getdescriptorinfo "pk(YOUR_WIF_PRIVATE_KEY)" and take note of the "checksum" which looks like this "#2ny75tj9".
  Replace "YOUR_WIF_PRIVATE_KEY" with your private key, since it's offline, doing so should be relatively safe.
• Type the command: importdescriptors "[{\"desc\": \"pk(YOUR_WIF_PRIVATE_KEY)#CHECKSUM\",\"timestamp\": 0\"}]"
• After that, the offline machine should now able to sign transactions that you'll create in the online machine.
• Now, to get the public key that you need to set-up the watching-only wallet in your online machine, type: listdescriptors
• Take note of the "pk" descriptor in the result, it should the the same as the one you've imported but has PubKey instead of PrvKey.
  
  

[Online Machine]

• Open Bitcoin Core, create a New wallet with "File->Create Wallet..."
• Tick the options "Disable Private Keys", "Make Blank Wallet", "Descriptor Wallet", (enable encryption if you want) and create the wallet
• Open the console, make sure the wallet's name is selected in the console's "Wallet:" drop-down menu
• Type the command: importdescriptors "[{\"desc\": \"pk(YOUR_PUBLIC_KEY)#CHECKSUM\",\"timestamp\": 0\"}]"
  It's the pk descriptor from "listdescriptors" command in the steps above.
• After it finished rescanning, the funds should now displayed excluding the 6 early dust transactions.

[To Create Transactions]

• Create an Unsigned transaction in the send tab of the watching-only wallet, save it in your flash drive or other methods of offline file transfer.
  Note: you might need to provide a "Custom change address" if you're not sending the entire amount since you don't have one. (or just "Use available balance")
• Import it to the offline machine via "File->Load PSBT from file...", Sign it, export the signed raw transaction just like what you did above.
• Import the Signed raw transaction to Watching only copy and click broadcast to send it.
  
  

For the blockexplorer result:
Most blockexplorers tend to correlate transactions with P2PK outputs to its P2PKH counterparts by deriving an address from that public key.
But it's not the proper way to show them, P2PK outputs should be searched in a blockexplorer by its TXID.

Without any information about the password, even an expert with good hardware for bruteforcing wallets wont be able to break into it.
That's unless the password is short or consists of few simple dictionary words.

Since you're already considering giving it away with the phone, at least let "experts" try to break into it.
I'd recommend you this service which won't charge a fee right away (only until the wallet is cracked): https://www.walletrecoveryservices.com/
Take note that Dave wont accept the job unless you're certain that it has funds and at least know few parts of the password.

You can copy that file for your personal backup and then list it on ebay as you intended. (surprise for the buyer?)
But it's recommended to wipe the device first since you might remember a part of the password that you've used (not yours?).

Based from the contents, there's a low chance that it's an encrypted Electrum backup. (if you've renamed the file)
You can directly open a copy of it with desktop Electrum but you need the password to open the wallet.

You can download Electrum here: https://electrum.org/#download
It's recommended to verify it before proceeding: https://bitcoinelectrum.com/how-to-verify-your-electrum-download/

Actually, we have already mined more than 90% of the maximum supply.
What's being mined today are just a fraction of the average 21m bitcoins that would be mined.
If that's an issue, we should be experiencing that issue right now.

What it means is, the supply isn't all about the newly mined bitcoins but also about the already circulating supply.
Not that that all those 19million bitcoins are just on hodl or lost, most are still part of the circulating supply.

I have my doubts as well.
For example, the Transaction IDs provided seem to be "normal" transactions with change addresses which still have unspent significant amount of coins.
Not the typical "hack" transaction where everything is consolidated in one transaction.

Of course, it can also be the hacker trying to make those look like normal send.

I took the liberty to edit this Quote with links:

Anyways, let's just put a big note here that's it's not about Ledger device that got hacked.

Providing the supplied commands may help.

---

For now:
Importing another MultiSig descriptor containing order_01's private key, "vendor_pubkey" and "buyer_pubkey"
should enable you to sign a the partially signed bitcoin transaction but you still wont be able to create a psbt using it.
You'll also have to create a "watching-only" descriptor wallet containing the same descriptor but with pub keys to be able to create a psbt (without signatures).

(I'd recommend to create new blank descriptor wallets for each since the first descriptor will break some wallet commands)

Another option is to import an HD multisig descriptor based from order_01's master private key, vendor's extended public key and buyer's extended public key.
The extended public keys should be converted to xpub and you'll have to specify the correct derivation paths for it to derive the correct MultiSig addresses.
Here's the example commands to setup HD MultiSig in Bitcoin Core: http://bitcointalk.org/index.php?topic=5427745.msg61426872#msg61426872
The guide uses extended private and public key pairs, the derivation path will be different if the master private key is used instead.

Reference for descriptors: https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md

So you're Bob in this scenario, then the answer is the second part of my original reply.
In Electrum, it's in the transaction details' list of inputs.

If Mary is also using Electrum, she wouldn't have to guess since her receiving addresses should have green highlight,
the non-highlighted address(es) should be Bob's unless he's used some sort of coin control, CoinJoin or custodial wallets, etc.

In Bob's Electrum, he'll also see highlighted addresses (green: receiving / yellow: change) that'll differentiate his receiving and change addresses from the unrelated ones.

You must have a copy of the seed phrase of "default_wallet1" somewhere since it cannot be created without verifying that you've created a backup during wallet creation.
Since it's been a while, you might have just forgotten about it so try to look for it.

BTW, your wallet files aren't backup-up anywhere but your computer since Electrum doesn't have a central server for that.
So, I'd suggest you to stop using that PC at the moment in order to have a good chance of recovering the deleted wallet file through file recovery tools.
Using it further will corrupt the possibly still-recoverable files from the previous installation.

How did you managed to compute that private key from puzzle 65's private key exactly?
I mean, please provide the exact same steps so we can reproduce it for testing.

Because by simply doubling its "binary", it didn't resulted with the mentioned "Denis" private key.

Do you mean the address where you've sent bitcoins to?
If so, Go to 'History' tab, double-click on the transaction (not on the 'description' row or it'll edit it) and the "Outputs" without yellow highlight are the address(es) where you've sent bitcoins.
Or the address used as inputs?
If so, those are the "Inputs" of the outbound transaction.

If you mean "Receiving Addresses", you can enable the tab in "Show->View Addresses" and an 'Addresses' tab will show up containing a list of your 'receiving' and 'change' addresses.

Retry this but with the same version of Bitcoin Core that you've used with that data directory.
If you forgot which version was it, go to the datadir and open your "debug.log" file and look for lines with "Bitcoin Core version vN.N.N" with the appropriate timestamp.

Maybe not a major issue since it's quite common in other non-custodial wallets as well but usually can easily be fixed by a "rescan".
Blockchain wallet however, may also be non-custodial as they claim but their whole system still relies on their server,
so if there's an issue with the wallet's state in their server due to syncing issue, only them can fix it.

The solution at the moment is to follow what their support is asking,
but make sure that you're talking to the correct customer support since there are a lot of fake supports out there.

I'd also recommend you to provide them the transaction id of the inbound transaction.

Yes, it's in the wallet file protected only by your password, if there's no password set, it's in plain text that can even be read by a text editor.
Even if you changed that password or set a password in one copy of the wallet file, the other copies wont be affected by that password change.

That's because the wallet file, password or seed phrase aren't saved in a server but the local machine where the wallet is saved.

This year's "April Fools" event wasn't as crazy as the previous IMO.

For reference, here's the admin's reply to the "capcha update" thread: Re: New CAPTCHA now required before posting
Here's the list of previous April Fools threads: [Compilation] All pranks that was made by theymos in every April Fools Day come.

The proper way to do this is to unload the wallet first in "File->Close wallet" menu while the target wallet is selected or unloadwallet command.
You can now proceed to rename the wallet in the 'wallets' folder, then load it again in Bitcoin Core.

If you have pruned your blockchain, doing this may trigger another full IBD as indicated in the pop-up message.

You can use a 'watching-only' 'blank' 'descriptor' Bitcoin Core wallet to do this.
You'll just have to import all of those mnemonic seed's derived extended public keys as descriptors.

To do that, follow this guide learn how to create descriptors from the extended public keys and import each descriptor to Bitcoin Core.
Link: http://bitcointalk.org/index.php?topic=5399337.msg60178631#msg60178631

The guide is specific to import Electrum master public key(s) (account extended public key) to Bitcoin Core.
If you can't find a way to export each mnemonic seed's extended public key, import them to an offline Electrum (link) first to get each's master public key, one at a time.
Or use iancoleman's BIP39 tool (link), select the correct derivation path and get the "Account Extended Public Key" to be compatible with the guide.

The good thing with this is, you can import as much descriptors your hardware can handle compared to online APIs or SPV wallets with a quite low limit.
The limitation is obviously, it's Bitcoin-only and will require a lot of internet bandwidth and storage space. (pruning isn't recommended for your use-case)

I was going to suggest to clear the App's cache and saw that there's someone already suggested it to the web version,
but based from your reply, you didn't in the App?

To do that, go to your Phone's setting, look for "Apps", "Manage Apps" or similar name (where your installed apps are listed).
Find and click "Blockchain" app and tap to open "Storage", tap "Clear Cache" to clear its cached data, force closing it may be needed or at least restart the phone.
Be sure not to click "Clear Storage" or it will reset to its newly installed state.

The "3 days behind" message doesn't mean that it'll take 3 days to sync, it's just 3 days worth of blocks which usually sync within an hour in my machine.
I suspect that there's something wrong with your node.

Close everything, restart the PC (to make sure everything isn't running in the background) and then start Bitcoin Core to see if it'll continue from where it left.
Take note that Bitcoin Core's GUI might freeze while it's syncing but it's still active in the background,
closing it forcefully might corrupt your "txindex", "chain_index" or "blockchain".
If it's not frozen, you can close it safely.

After it fully sync, the close it and open Armory, let it manage Bitcoin Core (it'll launch bitcoind in the background).
If there's an issue, check you debug.log file for errors in Bitcoin Core's data directory to see why it's not progressing.

Yeah, blockexplorers don't actually have 100% identical data, they mostly rely on their own copy of each coins' blockchains.

As for still showing invalid transaction, it's their unique "feature" to keep those data that aren't in their mempool or blockchain.
It's actually useful in cases like this.

So the transaction wasn't replaced by another with a different output and just had a replaced parent (rbf to bump the fee) or dropped from mempools..
Glad to see that it went well.

I was talking about the timeframe when the said transaction was gone missing.
Even with the ordinals bloating the blockchain, there are still a lot of time when the mempools do not reach the default maximum size, like right now or yesterday.