I googled for a port forewarding tutorial for luci (which i can deduct from your screenshot)

https://www.cfos.de/en-us/cfos-personal-net/port-forwarding/openwrt.htm

the machine running your node will need to have a fixed ip.

For the rest, it might be a good thing to read this:
https://bitcoin.org/en/full-node

The thing is: if you only want to use bitcoin core as a wallet, you don't actually NEED inbound connections... You made outbound connections, so you can download blocks and transactions. You only need inbound connections if you want your bitcoin core to run as a full node to support the network.

I assume you're working on a pc in your lan? In that case, it's probably upnp, firewall, port forewarding,... related.

I do see the screenshot.... 10 outbound connections, 0 inbound... looks ok to me.

Is this a wallet, or do you want to run a full node 24/7?

Did you look at the command i posted vs your command?
executable -salvagewallet --"path"
is not the same as
executable salvage --"path"

But first things first: which bitcoin core version are you using?

Which version are you running? It seems salvagewallet was removed from 0.21.0, so if you're running a version pre 0.21.0, you could try the initial command given by BitMaxz.

EDIT: i just logged on to my system, and had a look for myself (-help). Seems like the command is:
./bitcoin-wallet salvage --"wallet.dat"
At least, that how it works for me..

On windows, that would make
bitcoin-wallet.exe salvage --"c:\\path to\\wallet.dat"
(at least, i think it'll need double slashes)

So basically, if you're running >=0.21.0, you could try to switch the salvage command and the path...

I, for one, would never leave my house without wearing surgical latex gloves if i had derived my private key from my fingerprint... If i would leave even a single print, i'd be at risk of getting robbed... Not to mention the $5 wrench (or hedgeclipper) attack in this case (as mentioned in the first reply), and i'd be terrified the police would ever have my fingerprint on file, since in my country "cyber security" is a big black box for law enforcement (at least, that's my perception of them).

Where did you get your information? Cause it is wrong...
It IS possible to brute force a bitcoin core password, there are even tools for this purpose (like the one i discussed in my first post in this thread, but there are others aswell).
What IS true is that, a lot of times, the time, hardware resources and energy needed to bruteforce a password are greater than your lifetime and/or more costly than the value of the unspent outputs in the wallet with the forgotten password.

EVERYTHING depends on the strength of the password and how much you still remember about it.
If you know, for a fact, your password is exactly 10 digits long (0-9), there are only 10,000,000,000 possible combinations... With a single GPU, btcrecover can try about 6000 keys/second, that's about ~20 days.
If you have a habit of only using lower case letters and never make a password more than 5 letters long, your searchspace is 26⁵ (<12 million), which would take only little over a day.
If you know what passwords you might have been using, but you know you always used an incremental number at the end and you cannot remember wether or not your used a capital letter and you're unsure about one or two other letters that might have been replaced, the searchspace might be only a couple million, and you could potentially bruteforce this password in a couple of hours.

And btcrecover might not even be the best tool for the job....

Have you looked at the transaction on a blockexplorer (like blockchair)?
If the transaction exists + is confirmed (sufficient confirmations) => you either used the wrong address or there's a problem with the reciever
If the transaction doesn't exist => it could be an electrum problem (or a problem with your pc/network)

Wallet.dat from around ~2015. Odds are pretty big that it's a bitcoin core wallet file.
You could potentially use btcrecover to try to bruteforce your password, but everything depends on what you know about the password + how complex it is + the amount of hardware/time you're willing to spend

ok, but that doesn't really answer my question... You say you forgot your password, but my question is: your password for *which wallet*.
There are dozens of wallets, some still active, some no longer maintained, hardware wallets, online wallets, paper wallets,... if we don't know which wallet you used, we can't give specific advise on how to bruteforce your password (and even then, we cannot give any guarantee.... bruteforcing is only as good as the amount of time and hardware you're willing to spend... and a lot of times it's impossible).

The very first version of the bitcoin reference client is 13 years old, at that point there were only a handfull of users... So 14 years is impossible.
This being said: could you tell us which wallet client you are using? Sometimes it's possible to bruteforce, but everything depends on the wallet you used and how strong of a password you used.

The repayment was handled over PM and was 100% complete.
Loan successfully closed

I wanted to extend BlackHatCoiner's reply to make it a bit more "newbie-friendly".

The expiration date in electrum is basically for your internal accounting purposes. An address does not "expire", it's just electrum adding an expiration date to said address so it doesn't get re-used if it isn't expired.
As long as you keep the seed phrase, you won't lose your BTC...

Or, unless the employee made a habit out of robbing clients... One case means nothing, but if a couple dozen people claim to have been robbed by the same store in the same timeframe, it might force law enforcement to take a closer look....

For all the OP knows, maybe the shop owner already caught an employee stealing from other clients and terminated him, or reported him to the police (theft happened almost a year ago, so if there were other cases, odds are they already came foreward to either the police or the shop owner). Maybe he goes to the shop and the shop owner immediately tells him which police department is handling the case... Stealing employees are not good for a shop's reputation, so (unless it's a one-man shop, or the thief is the owner) odds are that once the owner had several complaints, he himself would have dealt with the stealing employee.
Ofcourse, these are a lot of 'ifs and buts', but still, it's worth filing a police report and going to the shop to ask them if they know anything about this (without accusing them directly, i'd personally take a lawyer with me if i was planning on making big accusations).

If the transaction moving your funds from your wallet to an unknown wallet is at the exact time your computer was sent away from upgrades (or only days after this fact), odds are very big that it was either an employee of the company upgrading your system or malware (accidentally) installed during the upgrade.

In this case, i'd probably tell you to contact them (maybe even with a lawyer present), and file a police report.

There are tons of attack vectors... Malware, seeds/passwords/wallets/keys saved unencrypted (or with weak encryption) on a vulnerable device or on the cloud, evil maid attacks, phishing,... It's not because your computer was once out of your controll, that this upgrade is automatically to blame!!! I know (first hand) that it's always the person working on a computer that gets the blame for any unrelated problem, even months after an intervention.

Cloudflare is a private company. I know they are offering tons of bells and whistles, and they keep adding to their portfolio on a regular basis. To much to keep up for me anyways.
But the features you seem to be reffering to is their feature to upload your own certs and keys, and the feature for keyless ssl?
I never used these features, but i looked them up for a discussion i had a long time ago, so i'm aware of their technicality's. If i remember correctly (i didn't re-read the whitepaper, this stuff comes from memory) the first feature gives cloudflare all the tools to generate symmetric keys themselves, the other just gives them only the symmetric keys (and you host some kind of service on your host to let them request a new symmetric key).
These service *might* look "better" to the untrained eye, but in fact they are worse: when you use them you're even hiding the fact that cloudflare acts as a MITM (but they still are!!!). When you use these services, your customers will never know cloudflare can (and will!!!) decrypt every package they exchange.

The bottom line is very, very simple and does not differ from which package you buy or which technology they implement: their proxy REQUIRES them to decrypt the traffic between (what the visitor thinks is) the visitor and the webhost.
Why? Well, you know those nice features they offer: DDos protection and their CDN? Both these things are built on the fact that they keep a big cache of DECRYPTED data from YOUR host on their datacenters. When a client requests a page, they HAVE to be able to see what the client requested (so they HAVE to decrypt the request), then they can see if they have the requested data somewhere on their servers (UNENCRYPTED). When they don't have the data in their cache, they WANT the data in their cache, so they request it from the host, DECRYPT it, and PUT it in their cache before (or after) re-encrypting it and sending it to your client.

That's why they're able to offer DDos protection: your data is on so many geo-located servers, and they're so big, an attacker just can't muster up a botnet that's so big he/she can tear down cloudflare. They'r still DDos'ing, cloudflare does not stop them, cloudflare just absorbs the requests... Maybe they block them after a while, IDK, but in the first place they just absorb them due to the fact they have your data anyways, and they have dozens of copy's of your data all around the world, so let a botnet request a couple million of copy's: they don't care.

That's why they can speed up your site: they have copy's of most of your content all over the world on fast servers: a client downloads most of your content directly from cloudflare (and not from you), from a fast server close-by.

And in the end it doesn't matter if you use cloudflare's SSL, you upload your cert+key or you run "keyless ssl" by running a local deamon to generate symmetric keys.... If you use the proxy, they have your data.... Which is bad for a mixer.

And the thing is (and i've said this before): i wouldn't even mind all that much if the mixer operators had any clue as to what they were doing and warned their clients... Like @LeGaulois already said: some people won't care if law enforcement knows who they are, they just want $5 wrench protection.
But the very least a mixer operator should do is plaster a big warning on their clearnet site about the fact that the clearnet version is cached by cloudflare and both cloudflare employees and law enforcement. At least this would demonstrate the fact the mixer operator knows enough about this techology to run a mixer.

But by acting like most mixer operators do when i point out they use cloudflare (shrugging, telling me other do the same thing), i get scared.... Very scared.... How can you trust the algorithm, the code, the workflow of a mixer operator who doesn't understand the slightest thing about why a MITM is bad for a mixer? When i see the reactions from mixer operators, i always wonder what their code would look like.... Or maybe they're running their operation from shared hosting? Or maybe.... Well horror scenario's pop to mind....

I see your point of view... And i do agree... You're in a grey area yourself, you're not really a mixer, so maybe you can get away with using cloudflare's SSL certificates... This being said: three letter agencies might still find it usefull to know who your partners are, so i wonder if it wouldn't be better to use an x3 certificate instead of cloudflare's. Offcourse, you'd lose DDos protection, your website responsiveness *might* drop (if you were using slow hosting, or a high latency dc), and you'd use a little bit more bandwith.

I actually pointed this out to you in august 2018!
https://bitcointalk.org/index.php?topic=4667343.msg44815063#msg44815063

Here's your reply:

At this moment, your platform is enabling 7 mixing services (when looking at https:  //    [banned mixer] /mix -coins.  php). 6 have a clearnet presence, 3 of them use cloudflare, and one does not use ssl at all (what?). I know there are your customers, but maybe giving them a nudge in the right direction wouldn't be to bad? Only 3 out of 7 of your clients got it right... Some kind of guidance from you side would probably be a good thing for privacy as a whole.

@LeGaulois: you make a valid point aswell... For some people, "moderate" privacy against non-law enforcement might be enough... I know i have never actually needed protection against the law, i'd still like them to keep their nose out of my business tough
The main problem, which is the same for cloudflare SSL certificates and tor: not everybody is tech savvy, not everybody will do their homework... A lot of people will just use google to find a mixer, look at the green padlock, read the promo text and mix their coins, thinking they are now anonymous... A lot of people won't look at which certificate is issues by who, they won't look up nameservers or dns records, they won't inspect the code for embedded javascript,... They certainly won't download the tor proxy and start using the tor mirror... They are average people that want privacy, they trust the mixer in question, and in the end, they usually don't get the privacy they payed for... Granted, 99% of them don't *need* said privacy, they still payed for it, they  trusted the mixer, so they should get that privacy (wether they need it or not).

But that's just my opinion

I know i'm preaching to the choir here, and i know this is your thread, but i still wanted to chip in to give some more background information since i think this is really, really important stuff...

I've actually dedicated a complete thread to this problem, i like to refer to it since it cost me a long time to write this stuff up: https://bitcointalk.org/index.php?topic=5247838.0

The problem with the soup analogy is the following.
When i eat soup, i have several "mayor" goals and a couple "minor" goals.

• I want nourishment: mayor goal
• I want a healthy snack: mayor goal
• I want something to quench my thirst: minor goal
• I want something warm: minor goal

If mixers using cloudflare had to fit into the soup metaphore, cloudflare mixers would be like calling hot water with salt "soup". When it comes to my goals:

• I want nourishment: mayor goal: FAILED
• I want a healthy snack: mayor goal; FAILED
• I want something to quench my thirst: minor goal: OK
• I want something warm: minor goal: OK

When it comes to mixing, i also have mayor and minor goals... When talking about cloudflare mixers, this is where i stand:

• I want complete anonymity against everybody (including law enforcement): mayor goal: FAILED
• I want "normal" (non hacker/non law enforcement) users not to be able to track me: minor goal: OK

The problem here is that, once a site uses cloudflare's SSL certificates, what happens is:
The mixing client creates a symmetric key between their device and CLOUDFLARE... The user THINKS he's safe because he/she sees a green padlock in the mixer's url, but he does not realise cloudflare WILL decrypt EVERY package they sent to (what they think is) the mixer. Cloudflare then looks at the requests, checks it's cache, and if the request cannot be fetched from the cache, they create a symmetric key between cloudflare and the mixer to request the missing content.

This means that, when a mixer uses cloudflare, cloudflare will know:

• The exact deposit address shown by the mixer
• The exact withdrawal address entered by the client
• The letter of guarantee (if the client downloads it)
• The client's ip
• The client's browser fingerprint
• The exact timestamp

Not only this, but cloudflare is a US company... In the US, data privacy seems to stop as soon as law enforcement comes into play... This basically means that, if you use a mixer using cloudflare, law enforcement *might* be able to obtain more data about you than if they'd had access to your wallets directly.

Now, once again: i'm not against cloudflare... Cloudflare protects even my own blog against DDos attacks, it speeds up my site due to their cache, it lets me enhance my site due to their addons, it handles my emails, it's a really easy dns record editor,.... Cloudflare is great, as long as your visitors don't have anything to hide from a US company (and US law enforcement).

It's great for non-political blogs, it's great for mom and pop shops... This being said: it's not OK to use cloudflare's cache (and their ssl certificates) for a mixer, a gunshop, a political blog, a porn site,...

Eventough i think [banned mixer] has no place between mixers in the first place due to their MITM integration of cloudflare (nor do i think any other "mixer" using cloudflare's SSL certificates should be called a mixer, maybe a "semi-obfusicator" would be a better term) , it does seem like the owner has updated his thread for the first time in a very long time:
https://bitcointalk.org/index.php?topic=4667343.msg59095552#msg59095552

btcd has been around since 2013. I stopped using it because the performance wasn't all that good (i had btcd and bitcoind both running on different machines, i switched to one node running bitcoind afterwards)... Bad performance was fine in 2014/2015 (which was around the time i used it iirc), but around ~2017(ish) the amount of broadcasted transactions rose untill the point most of the blocks were filled to the brim. The sheer size of the blockchain at that point in time, combined with full blocks made it obvious to me that i had to move away.

The reason for my move from btcd+bitcoind (two different nodes) to 1 node running bitcoind was 100% performance related, and had nothing to do with the consesus algo. AFAIK, btcd is updated frequently and is a perfectly valid (albeit, less performant) full node that can be used as a mining node. I'm not sure if anybody is doing this tough, and my experience with the project stopped many years ago, so i cannot comment on recent topics.