in addition to the options for losing keys mentioned by Biodom, there is always an unexpected hacking option. We can recall the story that happened a few months ago with Libbitcoin, where key generation was carried out with insufficient entropy, as a result of which the keys generated in this way were especially vulnerable to hackers. This way, you can be confident in the safety of your keys and still face the loss of your bitcoins. The probability of this is almost zero, but still not zero.
This is why addresses must be created on a computer which has no internet connectivity and printed on a printer that will never have internet access. Printer spooler buffers can be hacked.
Whats wrong with handwriting?
All possible leaking problems avoided and it should not be like a big deal writing a dozen of simple words down.
well, in this case you rely on additional wallet or ledger/trezor software, right?
<snip>
No, I create the seed with electrum on a computer that never goes online. I write it down on two pieces of paper (backup) and store it safely.* Once I'm done I shred the harddisk (the linux tool 'shred' not actual shredding) and reinstall linux + electrum from cd for the next time I have to sign a tx.
I have never seen any use in these little USB gadgets, too much trust involved for my taste.
*I also apply some crypto-fu by xoring with a simple password before writing it down, it still looks like a seed but isn't oneI don't mean to pry too much, but what happens if something happens to your wallet, so then you go to use your seed (hypothetically, maybe you had not accessed that seed for 3-5 years) and then once you try to retrieve your back up seed and put the two pieces together, one of your two pieces of paper is missing, damaged or otherwise not sufficiently readable?
What I am getting at is that I hope you are not just relying on one back up.
Another question would be if your wallet and its back up happens to be in the same house (or location) at the same time.. what if your house burns down? or gets hit by an asteroid
(alien spaceship) and completely destroyed? In this second scenario, you had both your regular and your backup destroyed at the same time... and that could also be a problem of having ONLY one back up, and I am not really opposed to having one of the back ups in the same building as the wallet (the primary), but there seems to be a need for some kind of locational diversity, even if it might be a separate building on the same property... but yeah, some folks might feel that they don't really have second buildings, and so maybe those people might get stuck with some kind of safety deposit boxes which ends up being a bit of a hassle since almost two safety deposit boxes might be needed unless there might be some ways to disguise the backups in plain sight.. which I would suggest is not an impossible task, even though it could end up in confusion for anyone who might not know the instructions for how to untangle the puzzle.
By the way, none of my questions are meant for you or anyone else to provide specifics regarding their own practices, and/or even if there might be some family members involved, there could be a kind of system in which a family member agrees that I am holding something personal in their filing cabinet or their safe or in one (or two) of their books or something in which, they might need to know not to throw away or to destroy, in the event that I am not visiting them on a fairly regular basis to be able to ensure that the location and/or the contents of the location is not messed with.
To clarifiy, I don't use any shamir secret sharing or similar tech as you seem to assume. The backup and the "original" are fully identical. Before writing it down I just xor the original 2048bit key that results in a valid seed for electrum with a password and store that value as BIP39 encoded seed words. Xor that again with the valid password and you get the original and valid electrum seed back.
Regarding the other (very valid) concerns like storing in different locations etc. that you bring up, these have been well considered and in my view sufficiently addressed but due to obvious opsec reasons I'd prefer not to go into too much detail.