Every p2pkh bitcoin address has a key pair behind it i.e. a private key which remains secret and a public key.
There are two ways in which you can generate these keys. There is the old fashioned approach where the wallet is Just a Bunch of Keys (JBOK) and the newer approach where the wallet is a deterministic wallet.
In JBOK wallets the private keys are totally random and unconnected to each other. You need to backup all the private keys in this type of wallet. Furthermore, because address reuse is a bad thing new addresses are created by the wallet software all the time so you need to periodically create fresh backups of your wallet. If you fail to do this you might find that your coins were sent to some change address whose private key you don't have.
In the case of deterministic wallets also known as hierarchical deterministic wallets (HD wallets) all address specific private keys are derived from a seed. You backup the seed once and that's enough to restore your entire wallet. The downside is that if the seed is exposed you lose all your bitcoins and what's more the person who has your seed can wait for an optimal time to steal from you because all future addresses' private keys are also derived from your seed.
In recent years there has been a shift towards HD wallets. What is the reason for this shift? The reason is that the vast majority of people who lose bitcoins lose them because of their own mistakes and not because they got hacked. They lose them because they forgot their password or didn't backup their wallet file. HD wallets make backups easier and so they prevent such losses.
Regarding that bitcoin hard drive guy he didn't make a backup of his wallet. Back then the wallet would have been a JBOK type one. We don't know whether he didn't make any backups at all or whether he had outdated backups. If it's the former then not even HD wallets would have protected him because you still need to backup the seed by writing down the mnemonic or making a copy of the wallet file.
Hi Nate. Thanks for the clarification :) The thing is, even if you lost your private key (the "wallet" file) if you remember it, does it not enough? Probably the guy did not remember the private key, and that was the problem, right? Just based on my first statements, as soon as you enter your private key, due to its related with your public key, you can use your wallet, even if you "loose" it. – 3Chicken – 2018-10-14T15:58:58.957
Sure, if you can remember the private key, or a mnemonic phrase for a seed that generates the private keys of an HD wallet, that's another form of "backup". The article is from 2013, when HD wallets were not yet in common use, so the keys probably weren't generated from a seed. Thus the keys were just random 256-bit strings, maybe several of them if the coins were distributed across multiple addresses. People can't very well memorize that, so he was depending on having the keys stored on his hard drive. – Nate Eldredge – 2018-10-14T16:03:30.917
Hi Nate. I think thst I just realised the problem of my logic :_) I was thinking the private key as the password that you specify to use your private key, but I guess that that private key is a file (or string or similar) , so it does not mater whether you remember the password associate to the private key, if there is no key, there is no party right? Anyway, what happen with the web wallets? Do they have your private key? Is that not dangerous (whether they guess or store the associated password in a unsecured way)? – 3Chicken – 2018-10-14T16:06:57.333
@DanielFernandez: That's right. With wallets like Bitcoin Core (which is probably what this guy was using), the private keys are stored in a file (e.g. wallet.dat) which may optionally be encrypted with a passphrase. So you necessarily need the file, and if there's a passphrase, you need it also. – Nate Eldredge – 2018-10-14T16:09:35.740
@DanielFernandez: Web wallets work in a variety of different ways. One possibility is that they actually store your private key, and you trust them not to steal the coins. Another is that they only store an encrypted copy; when you want to spend coins, you fetch the encrypted key from them, decrypt it locally with your passphrase, and use it to sign a transaction. In this case the wallet provider never knows the key itself, but if you should forget your passphrase there is nothing they can do to help; they can't "reset" it. – Nate Eldredge – 2018-10-14T16:11:26.500
Thanks a lot guys :) Probably the option that I like the most is have an encrypted copy of my private key in the wallets servers and use it locally with my paraphrase, looks like gather the best part of both options: whether I loose my private key file they have a copy but they can't use it due to its encrypted. Which ones offer this services? Anyway, should not be this practice something standard? – 3Chicken – 2018-10-14T16:20:09.680
I don't know which providers currently work this way. You should probably ask it as a new question. – Nate Eldredge – 2018-10-14T16:35:17.190
@DanielFernandez: Even so, this option is still a little tricky, since you have to decrypt the key and sign the transaction locally. You could install software to do this, but that partially defeats the purpose of a web wallet. Another way it's done is to have some client-side Javascript that handles the process within your browser - but then you have to trust the site that the Javascript really does what it says. They could replace it with code that decrypts your key and then sends it to them, and it'd be hard for you to notice. – Nate Eldredge – 2018-10-14T16:40:35.547
1@DanielFernandez: Also, they have ample opportunity to try to guess or brute-force your passphrase, so you had better choose a really good passphrase - long and ideally random. But such passphrases are hard to remember, so you'd want to keep a copy of it somewhere... you see the problem? – Nate Eldredge – 2018-10-14T16:43:04.113
Just opened a new thread to clear this up (not mixing too many things only in one): https://bitcoin.stackexchange.com/questions/80083/do-wallets-save-a-backup-of-my-seed
– 3Chicken – 2018-10-14T16:49:25.740