|
Updated the chart as there's been a few nice changes in the meantime... (Multibit encryption, portable Electrum download, etc)
|
|
|
|
|
2 3 trades in progress. 0% fee period ending tomorrow 6pm GMT!
|
|
|
|
|
To restore, you need to delete or rename the existing electrum.dat file.
|
|
|
|
|
Small amounts only (between 1 and 5 btc).
0% fees for the next 48 hours! PM me for a quote.
|
|
|
|
|
Edit: I confirm the issue with lifeguard's balance has been resolved.
Thanks for the quick and helpful response!
|
|
|
|
|
My buddy (lifeguard) says his balance has been majorly messed up since the crash. He was sitting with a big stack at a 25-50 9max table when it happened. Please could you check?
|
|
|
|
|
Also, if you are copy-pasting the seed, make sure you there are no leading or trailing spaces. And only one space between each word.
|
|
|
|
Speaking of that e-mail, I also found an old binary of bitcoin 1.3.0 which is from Jan 9 2009, I tried strings to see if I could extract some leftover data from his build environment, but the only thing that came up was MinGW 3.4.5. Really, the only way to find his true identity, is if someone who has had replies via his e-mail to view the raw headers and his IP should be there, unless he used Tor. He did use Tor. IMHO the only people who might be able to help crack this nut are GMX admins (German company I believe - no time to check this now). |
|
|
|
Its an absolute terrible idea to trust your digital currencies to OS bundles from random internet strangers...
I agree  Its not a good idea to back up your Bitcoins using a software that was deviced for the sole purpose of backing up Bitcoins. Why not? Because you are much more likely to get a Bitcoin stealer malware on your system if you use software with Bitcoins in mind, than just reverting to some standard all-purpose software that was deviced probably long before Bitcoin was an issue. I appreciate the effort nevertheless and hope that this can turn into an ongoing and well maintained project if complexity is reduced and all source code of the package thoroughly checked for malicious code by third parties so even I would feel comfortable to use it. Till then its a rocky road, so best of luck! This. I'm getting more and more paranoid installing ANY closed-source software released after 2010! |
|
|
|
|
Just a guess... Any non-standard characters in your password?
Try to restore again, using another password for testing.
|
|
|
|
|
I'm closing this project due to other priorities. Thanks everyone. It was fun!
|
|
|
|
|
Could it be that you tried Electrum a few months ago and set a password back then, before deciding to use another wallet?
|
|
|
|
I think the big difference between the "bitcoin elites" and the existing financial system elites is the "bitcoin elites" are working really hard to distribute our power.
We're getting there, but it will take time. I really hope in a year or two there will be at least three or four different bitcoin implementations all producing blocks, validating transactions, etc. And in ten years there will be a dozen or more.
That is a natural progression; I was around when NCSA Mosaic was the one web browser and the NCSA server was the only web server, and there have been a couple cycles of certain browsers / web servers becoming dominant and then fading. I expect to see a similar evolution for Bitcoin infrastructure software.
do you mean alt chains? no, he means like BitcoinJ and maybe Armory. Nope, bitcoinj is a light node and armory is an addon to bitcoin-qt. I believe Gavin is talking about 3rd-party full node implementations, of which the only one that is actively maintained at this time (but has very little userbase) is Ufasoft Coin. |
|
|
|
Strange... Are you running any HIPS or whitelisting software, by any chance? Or perhaps it's just a corrupted download? The executable should be 6.3MB. You can also double-check if the SHA1 hash is correct.
Not doing anything of the sort. Executable is indeed 6.3MB. You're welcome to take a look with Remote Assistance. Sorry, i won't be able to help right now due to time constraints... Hopefully someone else can help you out, or you can try the builds from electrum.org. |
|
|
|
|
Strange... Are you running any HIPS or whitelisting software, by any chance? Or perhaps it's just a corrupted download? The executable should be 6.3MB. You can also double-check if the SHA1 hash is correct.
|
|
|
|
You're absolutely correct.
I was simply using a 64 bit password hash to illustrate that a 128 bit brute force isn't exactly a walk in the park. You would have to *really* want to get in there, and have lots of time to do it.
Just to add my 2 cents: if by "lots of time" you mean "10 times the age of Earth" you would still be underestimating how long it takes on average. |
|
|
|
I'm getting an error when running the executable. It says:
"Windows cannot access the specified device, path or file. You may not have the appropriate permissions to access the item."
How do I fix this?
This is unusual and could be related to the new build process... Could you confirm if you're running it from C drive or somewhere else? Also, are there any spaces in the path you're running it from? |
|
|
|
I'll rephrase this: you actually can't take an arbitrary privkey that wasn't derived from a seed, and come up with a seed that can be used to derive it. Since that's impossible...
I was actually asking about this  Sorry to challenge you, as you definitely understand these things much better than I do, but are you sure it's impossible/close to impossible? Then, why the warnings in electrum about not to disclose/redeem any private key part of a deterministic wallet as this "compromises the entire wallet"? |
|
|
|
|
Really? Well perhaps I wasn't clear enough, but I wasn't suggesting generating a vanity address using an electrum plugin (vanitygen is just perfect for that, of course), but using such an address to build a seed around it. Is that process also resource-intensive? I'm not familiar enough with the inner workings of determistic wallets to answer that...
|
|
|
|
|
I just had a little idea, and I think it could be implemented without too much work (perhaps as a script, or plugin) by someone more skilled than myself...
Consider this:
Many people like having a vanity address, but using it within electrum means having to import it, which is not cool as it somewhat defeats the purpose of a deterministic wallet. So how about writing a function that takes the vanity privkey as input and derives a regular electrum seed which has this vanity key as the first 'receive' key of the deterministic sequence?
Seems to me this would combine the benefits of both vanity and deterministic addresses and wouldn't compromise the security/randomness of the seed in a significant way at all. But I could be wrong. Thoughts?
|
|
|
|
|
Show Posts
