Do you know where this roomers comes from? I mean that it is dangerous to just send a bit of the total amount when you import?
The "rumours" came from actual instances where people lost coins because they did not understand how paper wallets, imported private keys and (most importantly) "change" worked... in some wallets. The "common" way to "lose" coins was: 1. Create new wallet file 2. Import paper wallet private key to new wallet file 3. Spend partial amount... where "change" was returned to a completely new, randomly generated private key/address 4. Delete wallet file without making backup 5. Discover that your coins are no longer on your original private key/address Essentially... instead of doing this: OriginalAddress --|--> Recipient1 |--> OriginalAddress Wallets were doing this: OriginalAddress --|--> Recipient1 |--> NewChangeAddress And users were not aware of "NewChangeAddress" and were not making records/backups of "NewChangeAddress" (and it's associated private key)... Then, in the future, they'd import the old OriginalAddress again, only to discover that it no longer had any coins. NOTE: As noted by the other users, this is NOT a problem with Electrum... if you create an "imported wallet" (by importing private key(s) from a paper wallet)... it will only every have those imported private keys in it... it doesn't create new change addresses and any change generated by a transaction is sent back to the original address. |
|
|
|
Microsoft Edge and Windows Defender keep flagging the official Electrum downloads as "unsafe"  And I know other antivirus flags it due to "PyInstaller" flagging up as being suspicious activity etc.  I have used the "Report as Safe" option every time this happens, and it still keeps on happening, so I'm fairly sure my reports are being ignored As for ElectrumABC, they provide sha256 checksums (so you can check file was downloaded OK) and also an archive of the gpg signatures so you can check that it was signed correctly. If all that checks out, then I'd say it was "ok" to use... Given it's on the "official" BitcoinABC, it should be "legit"... unless the entire project is a "scam"  |
|
|
|
Where are the blocks located? On my bitcoin core it says that I have mined 6 blocks, just like you did, but I don't see them anywhere:  In the "blocks" folder... so that blk00000.dat file that is shown in your screenshot will have your block data in it. You can retrieve some block information from the console using: This will return the BLOCK_HASH... then: |
|
|
|
I have my keys back  Awesome, glad you managed to get it sorted... now I would suggest making some backups of your wallet.dat and keys to prevent the same thing happening again!  |
|
|
|
Interestingly, they only have my email addresses, despite having made a purchase... so it would seem that the buyers database is not "complete". So, that's something I guess... Kudos to Ledger for actually admitting that the original security log analysis was incorrect in its determination of how much data was leaked: At the time of the incident, in July, we engaged an external security organisation to conduct a forensic review of the logs available. This review of the logs enabled us to confirm that approximately 1 million email addresses had been stolen as well as 9,532 more detailed personal information (postal addresses, name, surname and phone number) that we were able to specifically identify.
The database publicly released yesterday shows that a larger subset of detailed information has been leaked, approximately 272,000 detailed information such as postal address, last name, first name and telephone number of our customers. These details are not available in the logs that we were able to analyse.
Still, I'm not sure why they didn't just assume the worst-case scenario that everything had been taken...  |
|
|
|
I tried it on Win 8.1 64 bit and it crashes too. But because it crashes on exit I don't bother.
So, you've found a "workaround" by using Win 8.1? It installs and runs "OK", but then crashes when you attempt to exit the application? If so, I guess that's better than nothing 1-core Celeron at 2 GHz with 3 Gb RAM (some of RAM is used by onboard video card).
OUCH!!?!  I'm honestly surprised that Windows 7 runs on that hardware... hopefully with the increase in value of BTC you could upgrade your system |
|
|
|
i have allready do the command:
python pywallet.py --dumpwallet path\to\wallet.dat
There is always the message that the btc must be closed.
If it is giving you and error that says: "ERROR:root:Couldn't open wallet.dat/main. Try quitting Bitcoin and running this again. it means that the file is quite badly corrupted and it's unable to be opened as the standard wallet file. The --recover option should rebuild and create an actual "valid" wallet.dat file in the output directory. You should then be able to use dumpwallet on the generated wallet.dat NOTE: I lead you astray with the command... it should be: python pywallet.py --dumpwallet --wallet=full\path\to\wallet.dat
Apologies!  As for the access violation when using --recover... what size is your F: drive that you're trying to recover from? It's possible that your --recov_size=8Gio parameter is wrong, so PyWallet is trying to search past the end of the disk and generating the error? |
|
|
|
|
I think it's caused by the reindex option... What it is currently doing is going through what you currently have stored on disk (this is why you see progress changing as it reindexs the blocks on disk)... once it finishes that process, it'll then start looking for new blocks after 524490 (at which point the "syncing headers" values should change).
|
|
|
|
You might also want to do a search for "default_wallet"... that is, as the name would suggest, the default wallet name that Electrum generates. Unless the user purposely changed it, the application would have generated the wallet file with that name. Note that there is no file extension associated with Electrum wallet files. Another suggestion would be to just search using "wallet" as the search term and see if that finds anything. If you're operating on the command line... you'll want to use something like this: or etc |
|
|
|
I do have access to disk and I believe also 12 words for the seed.
That's a good start... I believe it was portable version since I don't see AppData/Roaming/Electrum folder.
Is there anything installed in C:\Program Files\Electrum? If there is, it's not the portable version. I tried entering 2 words in latest Electrum 4 but that doesn't seem to work.
I assume you mean 12 words... what happens when you try and type in those 12 words? Are you getting an error? Or is it creating an empty wallet? If you're getting an error, it's possible your 12 words are incorrect. Do you remember if the 12 words came from Electrum or were originally created in a different wallet? Do I need some kind of version compatibility or something else?
No. Electrum is backwards compatible... so seed mnemonics from older versions will work in newer versions. |
|
|
|
What file format do you recommend to save a signed transaction to broadcast much later?
I suppose I should save it in a text file (.txt) or in a pdf file using just plain text with JSON or XML.
Yes, just use a text file. There is no reason to save it as a PDF, aside from being a hassle to create in the first place, you will likely run into issues when trying to extract the data back out of the PDF (They're designed and made for reading, not for transferring data). Actually, I don't have a clear idea of how does a signed transaction ready to be broadcasted and validated by the bitcoin network (and eventually entering the blockchain) does look like in plain text.
As shown, a signed transaction is just a long sequence of "hex" characters: 010000000126063a71fecd0c76fa7d31a561cbe95bf2c7e5da01ae04fed6a6e9dfbc80953e010000006a47304402201a16d89264518baca8f4959b446372c6ce91e8d1fbc0b7b48618aeb76113df33022040eb804bf7cd6519d01709066658251cef1822ff49fd07707e058a07b27b42f9012103f78766b4346bcec0f2ae92d7e132e6b321c47627f14356a704b3ce57169dcb4e000000000116260000000000001976a914cfdd1b997472bd0b668e7472d9708305f116994d88acc0270900
You can use a transaction decoder (like this or this or decoderawtransaction in Bitcoin Core) to get the details of the transaction in a JSON format like so: {
"txid": "dc6383e28e4b6c652ab326592652b0322331caf07231cabec562ab116a46ff9c",
"hash": "dc6383e28e4b6c652ab326592652b0322331caf07231cabec562ab116a46ff9c",
"version": 1,
"size": 191,
"vsize": 191,
"weight": 764,
"locktime": 600000,
"vin": [
{
"txid": "3e9580bcdfe9a6d6fe04ae01dae5c7f25be9cb61a5317dfa760ccdfe713a0626",
"vout": 1,
"scriptSig": {
"asm": "304402201a16d89264518baca8f4959b446372c6ce91e8d1fbc0b7b48618aeb76113df33022040eb804bf7cd6519d01709066658251cef1822ff49fd07707e058a07b27b42f9[ALL] 03f78766b4346bcec0f2ae92d7e132e6b321c47627f14356a704b3ce57169dcb4e",
"hex": "47304402201a16d89264518baca8f4959b446372c6ce91e8d1fbc0b7b48618aeb76113df33022040eb804bf7cd6519d01709066658251cef1822ff49fd07707e058a07b27b42f9012103f78766b4346bcec0f2ae92d7e132e6b321c47627f14356a704b3ce57169dcb4e"
},
"sequence": 0
}
],
"vout": [
{
"value": 0.00009750,
"n": 0,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 cfdd1b997472bd0b668e7472d9708305f116994d OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914cfdd1b997472bd0b668e7472d9708305f116994d88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"1Kx5kYqStfhPQntRv185pTuyafLoaYLrV7"
]
}
}
]
}
Storing as "hex" is the best option as it takes up the least amount of space and can be immediately sent using any Transaction Broadcast tool (website "push tx" tool like this or this or Bitcoin Core sendrawtransaction etc) |
|
|
|
--recover is used more to find wallet.dats that were deleted... not generally for when you actually have the wallet.dat file showing in the file listings. It basically just reads raw bytes from the device and attempts to find and recover "lost" wallet.dat files (with varying degrees of success ) If you have a wallet.dat file, you're better off trying to use the dumpwallet command: python pywallet.py --dumpwallet path\to\wallet.dat
So, if the wallet.dat is in the same location as pywallet.py, then you can simply use: python pywallet.py --dumpwallet wallet.dat
If it was in a location like F:\Bitcoin\wallets, you would use: python pywallet.py --dumpwallet F:\Bitcoin\wallets\wallet.dat
|
|
|
|
In that case, it seems that no amount of fiddling is going to get the newer versions of Electrum running on your current OS. Can you try installing and booting Linux as a LiveOS from a USB drive... and test Electrum on that. Alternatively, you'll need to find a different wallet application. Hm, I can'st say that 2-core proc with 4 Gb RAM is light hardware requirements.
What hardware are you attempting to run Windows 7 and Electrum on? |
|
|
|
I downloaded 500MB in a couple of minutes no problem yet bitcoin core is taking ages  It's a common misconception that you just need to download 350+ gigs of data to "sync" your Bitcoin Core node... and users are often left wondering why their gigabyte fibre connection is not downloading the blockchain faster. The reality is that you need to download and verify all that data... The verification/processing of all the data involves a lot of reading/writing to disk during the initial sync. And it's usually hardware like HDD and low end CPUs that bottleneck this part of the process. Hence why you're seeing such high disk usage... being a laptop, it's probably a (very) slow 5400 RPM 2.5" HDD with a small cache... if it was an SSD it would be much faster. Alternatively, cranking up the amount of RAM used for the DB cache helps, because then more of the data is stored in RAM more often instead of being read/written to disk so much. This also helps speed things up during the initial sync. Unfortunately, there is not much you can really do about it now, but wait. The good news is that it will finish... eventually |
|
|
|
My hardware is too weak to migrate to 10. (And, by the way, why to do it if my current system is working quit well, except this little one trouble.)
Generally, the adage "if it ain't broke, don't fix it" is fairly apt... however Windows 7 is "broke" Honestly, it's purely from a security standpoint... Windows 7 has a number of unpatched security vulnerabilities that will never be patched because Microsoft stopped official support for it on January 14th 2020. Keeping that machine connected to the internet... and using it for cryptocurrency tasks is asking for trouble. The sooner you can get yourself some updated hardware and update to the latest version of Windows the better. Alternatively, you'll probably find that Linux runs quite nicely on any machine that runs Windows 7 as the hardware requirements for Linux are generally a lot lower (for instance, I can run Linux quite happily in a virtual machine that only has 2 cores and like 4 Gigs of RAM). Something like Ubuntu 18.04 would be sufficient and would run Electrum fine. Anyway, do try running from the python source and see if it works... in any case, be sure to update this thread with your results, as it might assist someone else who has a similar issue and finds this thread |
|
|
|
I misspoke, 15 character password + checksum. The version of Mycelium I used gave me that instead of a master seed?
...
1) I created the wallet in Mycellium v 2.8.12. I don't remember when I added the HD wallet, but it has all my BTC and I only have backup information for the single address, in 15 character + checksum form
Ahhhh ok, you've got the "encrypted PDF Backup" which is the Legacy backup for Single Address accounts... it's a 15 character password + 1 character checksum. That, unfortunately, is completely useless to you for recovering your Mycelium HD account. The password simply allows you to unlock the encrypted PDF file. My phone is not rooted. I have looked into doing so at this point to recover my pin, but I'm afraid of corrupting the data. I don't have a 15 word master seed anywhere I still have access to the phone, and am continually trying pin #s. It takes a little big longer for each successive attempt, and currently i'm at about 3 hours of waiting to find out if my pin attempt is valid or not... 2) I hvae a samsung SM-g928V running android v 7.0 3) smartphone is not rooted, and some googling indicated that my phone (verizon s6 edge) cannot be rooted easily Rooting your phone is probably not going to help, as most rooting procedures require unlocking of bootloaders, which generally wipes the device as a security measure... Additionally, "recent" Samsung phones have been notoriously difficult to root and have issues with "Knox" etc... I'm sorry to say, but at this point, unless you can figure out the PIN, your chances of recovery are close to zero |
|
|
|
That seems like some sort of memory access error... do you have any AntiVirus/AntiMalware software running? If you do, it's possible that it's conflicting with python attempting to access certain things. Either try turning it off (including Windows Defender) and try again... and/or try running your command prompt in administrator mode. Also, what is the exact commandline that you are using? This are the results after run with pywallet version 2.3
Where did you find PyWallet version 2.3? The latest version that I'm aware of is 2.2. |
|
|
|
Take note HCP uses slightly different entropy, OP and few uses uses 1000110 for last 7 bits, but HCP uses 1101100 instead.
That's correct... the OP had just "bruteforced" a correct word... and worked backwards from there... so I ignored the 7 bits from their post, as it wasn't correctly generated... I simply generated 7 random bits and used those.
So that explains how I arrived at a different result. My SHA256 function was wrong, which means I cannot use the hashlib.sha256() function for computing checksums.
It's quite possible that your code was calculating the hash of the string, rather than the actual byte values... it's a common issue that people come across when trying to calculate hash values... I've done the same thing plenty of times using Python when I forget to work with bytes hashlib.sha256().digest() works fine: Essentially (using your example with the OP's 128 bits): import binascii
import hashlib
myhexstring = "a89ec4e8327577411a104fbecbbf6ac6"
myhash = hashlib.sha256(binascii.unhexlify(myhexstring)).digest()
print(binascii.hexlify(myhash))
Output should be: bf4b881634e88ff59c29caa582413ee050bb1ce9a72272cebe9491f28e474e03
This is different to the hash you got: SHA256(0xa89ec4e8327577411a104fbecbbf6ac6) = 0xfdd211682c17f1af399453a541827c07
Now, using my 128 bits (with the random 7 bits I added to the OPs original 121 bits of entropy): import binascii
import hashlib
myhexstring = "A89EC4E8327577411A104FBECBBF6AEC"
myhash = hashlib.sha256(binascii.unhexlify(myhexstring)).digest()
print(binascii.hexlify(myhash))
Output should be: cfbcc91db0c32831574d52049530de257354baee4ac768bae401ae330cfba4a8
|
|
|
|
|
Show Posts
