That is the same as saying "do you confirm that the blockchain is valid as it should have been?". Software does that, not humans. Software written by humans, and humans make mistakes. There have been critical bugs in bitcoin, such as the time we printed 92 billion out of thin air, despite the code being review by multiple competent individuals. A fork was needed to fix that particular bug. You will be unable to fork the network to recover your coins should they be stolen from you via a reused k value. You do choose which wallet software you install, and it's plain dumb to use bad software if you know it's bad. Obviously, but my point is that often you don't know software is flawed/bugged/vulnerable/whatever until after the incident in question. Assuming that ever piece of software you are using is completely immune to bugs or vulnerabilities is a recipe for disaster.
|
|
|
If a software reuses k values (which is trivial to verify it does) then you shouldn't be using that software at all. And for every single transaction you make, do you confirm that the k value was generated using RFC 6979 as it should have been? You confirm that there isn't some unknown bug or vulnerabilities in your wallet which has result in a reused k value or a piece of malware being able to feed a k value to your wallet? I very much doubt it, and even if you personally do, it's safe to say that 99.9999% of bitcoin users don't. It is not realistic to say "Just don't use such a wallet", just as it is not realistic to say "Just don't get malware" or "Just don't be hacked". Once such a bug or vulnerability has been discovered, then absolutely move to new software. But it is impossible to know that you shouldn't be using such software before the first time the vulnerability is exploited. Not reusing addresses protects you against such eventualities.
|
|
|
thank you. this is the perfect choice for me. Here is the problem with the implementation. I generate BIP39 Why exactly are you trying to use a BIP39 seed phrase as an Electrum seed phrase? You are adding unnecessary confusion. Electrum checks that any seed phrases it generates aren't accidentally also valid BIP39 seed phrases, and discards them if they are. need to do normalized = prepare_seed(seed_phrase) The normalization function (prepare_seed) removes all but one space between words. what space to leave is not written anywhere ( The normalize function is defined here: https://github.com/spesmilo/electrum/blob/6650e6bbae12a79e12667857ee039f1b1f30c7e3/electrum/mnemonic.py#L79
|
|
|
That's the only downside. There is no other disadvantage in re-using an address, only small advantages. Not entirely true. Address reuse more easily allows you to be censored, although I suppose you could argue this is simply an extension of poor privacy. More importantly, though, there have been plenty of cases in the past of buggy or vulnerable wallet software reusing k values and leading to coins being stolen. Although all good wallet software will protect against this, it is unwise to consider it an impossible scenario. There is also the scenario of if you only ever use a single address, then you have a single point of failure for your entire bitcoin holdings. Better to spread it around a bit.
|
|
|
I've checked out btcrecover but it's way out of my league There is a pretty straightforward installation guide here: https://btcrecover.readthedocs.io/en/latest/INSTALL/. Setting up the tokensfile itself will be the trickiest part, but we can help you to do that. I would suggest you give it a try. Once set up you will be able to check thousands of passwords a second, far more efficient than anything you are trying manually. Or as bnbstorm says, you can extract the bare minimum information from your wallet.dat file using the instructions here ( https://btcrecover.readthedocs.io/en/latest/Extract_Scripts/), and then share that extracted file with someone else who can attempt to crack the password for you without any risk to your coins. I can give it a shot for you if you want.
|
|
|
Hahaha what an absolute scam. "We gambled all your money away to make profit for ourselves. Now give us more money so we can gamble it too and try to make back what we lost. We will pay you back with a complete centralized worthless shitcoin that we can print out of thin air!"
Handing a single satoshi back to Celsius' centralized scam platform is just plain stupid. Doing it in return for a centralized bankruptcy shitcoin is absolute lunacy. If anyone falls for this, then I'm sorry, but you are a moron.
There are also potential legal issues here, in that by buying said shitcoin you could be classed as having accepted some kind of settlement deal from Celsius and therefore giving up your rights to taking legal action for your original coins that they scammed from you.
|
|
|
Why is that an issue? As ETFbitcoin and Pmalek say, it's a privacy concern. Perhaps I don't want someone to be able to link every address in that wallet together under common ownership, or know the total amount of bitcoin in the wallet, or be able to watch all my future transactions, etc. But, as I mentioned above, in order to even create the multi-sig wallet in the first place and generate addresses to send coins to, all your xpubs must be on the same device at some point. There is no other way around it. And so printing them out from that device presents very little additional risk to your privacy then the risks you have already exposed yourself to (and hopefully mitigated) by setting up the wallet in the first place. If you do it all on a live OS on a permanently airgapped computer and printed the xpubs using a dumb printer (i.e. one without internal memory or wireless hardware), then the risk of leaking your xpubs in such a manner is almost zero.
|
|
|
Any thoughts? How is it independently verifiable by the buyer? How can the buyer (and indeed, all future buyers) verify that neither the original creator or any previous owners have been able to access the private key? Not much different from a hardware wallet; just simplified the functionality to a minimum, but it would use very similar hardware. This is probably the most straightforward option. If you can have a device which will sign transactions passed to it but will never reveal the private key, then whoever owns it can send any coins they like to it, knowing that all previous owners don't have the private key and couldn't have pre-signed transactions to steal their outputs which didn't exist at the time. The biggest issues the same as above, though. Can it be independently verified?
|
|
|
That makes lot of sense. I was overthinking the situation and considering the risk of some malicious app or file being on my online device, as I use it more often and it is considered less secure than the airgapped one. It is a legitimate concern, that some malware could copy itself to your USB drive along with the new version of your software (or indeed an unsigned transaction), and then from their copy itself to your airgapped computer. Of course you can use QR codes to move transactions to avoid this, but you can't use QR codes to move an entire piece of software, such as a new wallet version. So for this I tend to download the new wallet software on a live OS before transferring it to a USB drive, so I know there is no malware lurking in my daily OS waiting to activate itself. ... and up-to-day/in-synchronization with one another. This is the benefit of using seed phrases and HD wallets. Once you have backed up your seed phrase, then your back ups are permanently up to date and in sync with your main wallet. As soon as you recover that seed phrase, you can regenerate all the private keys and addresses you have ever used.
|
|
|
I'm going to let it finish syncing and see what I've got. I have several hard wallets in my cart at amazon. If the coins are still there I'll have a hard wallet in my hands in less than 24hrs.
You don't have to wait for it to sync to check your balance. Since from your first post in this thread you seem to know your address, you can just take that address over to a block explorer such as https://blockchair.com/ (or http://blkchairbknpn73cfjhevhla7rkp4ed5gg2knctvv7it4lioy22defid.onion via Tor if you want to protect your privacy) and look it up. I would use this block explorer specifically for this, just in case what you have stored as your address is actually storing P2PK outputs rather than P2PKH outputs. Blockchair will show both types of outputs, while some block explorer will simply miss out the P2PK ones.
|
|
|
I'm open to trying the Python script approach. Regarding the modification you mentioned, are you simply referring to replacing the USER_PUB and USER_SEED values in the script? Assuming the case, then I feel reasonably confident with the first approach. In any case, I'll try the first approach and let you know whether I'm able to successfully restore the wallet using Electrum afterwards. Not quite. The code that Andrew Chow has given there is in direct response to the user wanting to derive the individual private keys at index 14. You probably don't want individual keys like this and instead just want the master private keys which will let you recreate the entire vault alongside your already known master public keys. So yes, change USER_SEED and USER_PUB to your own values. You can then run the code as is, but it will output an extended private key at index 14 and a WIF key that you don't want. Make sure you use the keys it will give you entitled "Master Private Key corresponding to seed" and "Master Public Key corresponding to seed". Alternatively, just miss out the bottom two lines (print "Extended Private... and print "WIF format...). Not really from what they say in the readme Ahh well spotted. Still a risk if you simply turn off your internet on your main OS for a short period though. OP should use a live OS instead, as you say.
|
|
|
But there are many hurdles in a homeopathic treatment, the doctor forbids me to eat vegetables,meat and various sour foods. Sounds like you had a sensitivity to a certain food, and by stopping eating that food, your symptoms improved. Again, homeopathy is a scam. It is not simply a case of "We don't know if it works". It even goes beyond "We know that it doesn't work" and gets all the way to "There is no possible way it could even work". Water has a memory!? Insane.
|
|
|
The private keys are within the wallet file. You can extract them from it by using the dumpprivkey command. I would only do this if absolutely necessary though, since extracting and handling raw private keys puts them at a higher risk of being stolen.
If your client is syncing, then just let it finish syncing for the time being. After that you can decide where to send your coins to. Somewhere more secure than a hot wallet would be a good choice.
|
|
|
4th word released is "monkey".
Note that this is a 12 word seed phrase plus a passphrase. It's not entirely clear if the passphrase is going to be released as well, or what format it will take. It might be a word from the BIP39 word list as well to add additional difficulty, as then you have 13 possible words for a 12 word phrase.
Still, there is no point even trying until at least 8 words have been released, and even then it will be incredibly difficult, especially if there is no more clarity on what the passphrase is.
|
|
|
The alert key compromised message refers to this update which disabled the alert system: https://bitcoin.org/en/release/v0.14.0#final-alert. You don't need to do anything about it, except update your wallet software. In terms of accessing the coins, the first thing I would do would be to make a couple of back ups of your wallet.dat file, if you haven't already. Depending on the version of your client, you might find that it won't sync. You can download the latest version (24.0.1) from https://bitcoincore.org/, verify it, and install it, and then let that sync instead. Alternatively, if you want to avoid waiting for it to sync, you could dump your private keys from your wallet.dat file and import them in to a light wallet.
|
|
|
how can i lock my seed in the script? If you find more words of your seed phrase then I'm happy to help you create a tokens file which will brute force the remaining words. Three unknown words is fairly easy to brute force on home hardware (provided you know the position of the other nine). Four unknown words is very difficult, and would require renting hardware at a cost in order to do this, so the value in the wallet needs to be worth it. With 5 or more unknown words there is no point in even trying.
|
|
|
I like the split key idea It doesn't allow the collectible to sold on without introducing trust, though. That would be prevented because when it's bricked, it won't output its address, either. Doesn't stop someone from copying the address from their previous transaction. Is it a problem if you can only tell by plugging it in? I'm not sure. I wouldn't buy any pre-funded products regardless, so I'm probably not the best person to ask. If you are buying something in person then it is trivial to plug it in to check. If you are buying something online then hopefully your money would be kept in an escrow until you receive the item and plug it in to check.
|
|
|
but I am not sure how to properly check for updates and maintain the latest version of the software. If your airgapped wallet is already set up securely and working fine, then there is a lower requirement to keep up to date with new versions. It is essentially functioning simply as a signing device, and as long as you double check everything you are signing and have signed, then the risk of a vulnerability being exploited is almost zero. I don't care about any new features, Lightning support, etc., on my airgapped wallet. I keep an eye on the change log of each new version, and only if there is some critical bug fix will I upgrade my airgapped software. It's as simple as downloading and verifying the software on your online computer, and then securely transferring it to your airgapped computer. Understood. I am aware not to store sensitive data like seedphrases electronically, but your first reply seemed to suggest you do that sometimes. I should have been more clear - I was referring to non-bitcoin related sensitive electronic data, such as PGP keys, or copies of important documents, that kind of thing. One more question: whether to modify 3-2-1 backup rule (for bitcoin private keys)? I think it is a reasonable minimum to use. For any wallet you create, write down the seed phrase twice, and store one of those copies off site. 3 copies of your data (the wallet itself plus the two paper back ups), 2 different mediums (electronic wallet and paper), 1 offsite. If you are worried about storing your raw seed phrase offsite, then use a system where compromise of the seed phrase on its own does not lead to compromise of your coins, such as multi-sig or passphrases (again all backed up separately).
|
|
|
Before you go about destroying it as the above comments have suggested, you should try to write over any data on the device if you can. Factory reset it a few times. Restore it with a new dummy seed phrase and passphrase multiple times. Then you can take it apart and smash/grind/blend/shred it up as small as possible, scoop up the dust and debris you have left and chuck it all in to your next campfire. Good luck getting the data back out of that.
Or even better, don't use a hardware wallet at all if your only goal is to generate a seed phrase and then destroy it. There are better approaches using airgapped computers and amnesic OSs as outlined above.
|
|
|
|