Electrum stores wallet files in a folder called "wallets" that should be in the same location as the "blockchain_headers", "config" and "recent_servers" files and the "certs" folder as shown in your screenshot here:  If your recovery software does not show the "wallets" folder, then you're likely out of luck  Does your recovery software only allow searching for file names etc? Or does it show a full list of all recoverable files/folders on the drive?  |
|
|
|
Who can help please?
The only person who can help, is the person who has the private keys for address: 1L5wSMgerhHg8GZGcsNmAx5EXMRXSKR3HeAt the present time, this address holds funds from 4 receive transactions dating back as far as 2018... It has never sent funds out. Do you know who controls this address? If you do, you'll need to contact them and ask (very nicely) for the funds to be returned. If you don't know who controls that address, then unfortunately your coins will be "stuck" It also appears that this address may be an example address used in the "Bitcoin for Dummies" book  It *might* be possible to contact the author of the book and see if they still have records of the private key used to create that address. |
|
|
|
I'm with o_e_l_e_o on this one... Creating your own methods of obfuscation generally leads to a post in about 1 or 2 years (or later) saying "I 'encrypted' my 24 words but I can't remember how... help?" However, this statement by the OP gives me hope that the OP has at least thought about this and has a "failsafe", by making sure they have an offsite backup of the original, unencrypted seed: I’ll still have one copy of the real ones somewhere else that I consider somehow safer.
|
|
|
|
As I understand the "bc1" abbreviation is about segwit compatabiltiy. My question is if both the public addresses are compatible with segwit, or if u have to use the "bc1" address to be? And Is there any reason for concern about functionality of the wallets in this case, i.e. funds sent to either one of the public addresses will show up in both bitcoin core and Electrum wallet?
There are actually three address types available in this situation... "Legacy" - These addresses start with a "1" "P2SH-P2WPKH" - These addresses start with a "3" "P2WPKH" - These addresses start with "bc1" One private key can be "converted" to all 3 types... for instance, if we take the private key: L2sf8SUpytobSSxSteJ7ixKt8pHXjm9FzavktpsN4Vy1t5M4Cos5
And import it into Electrum use the three different script types:  We get a wallet that has 3 different addresses... all generated from the same private key:     Bitcoin Core will automatically create all three addresses when you import a single private key... you don't need to specify the script type.  The "3"-type (P2SH-P2WPKH aka "Nested SegWit") and "bc1"-type addresses (P2WPKH aka "bech32" aka "Native SegWit") are "SegWit Compatible"... the only difference being that the "3"-type ones are compatible with older clients/services that don't recognise the "bc1" address format. This is becoming less and less of a problem as time goes on and wallet apps and online platforms upgrade to support bech32 addresses. And Is there any reason for concern about functionality of the wallets in this case, i.e. funds sent to either one of the public addresses will show up in both bitcoin core and Electrum wallet?
Electrum and Bitcoin Core simply display what the blockchain records contain... so any changes to any of the addresses will be reflected in both the clients (and any other clients where the private keys have been imported). Also note that even though all of these addresses are generated from the same private key, they are treated as completely separate addresses by the bitcoin network. So, funds sent to the different addresses are effectively segregated from each other. So, if you setup the wallets as I have shown above, and then sent 1 BTC to bc1q77avy7yp04j4sql8u7jq4qwyhrn2dushe6q0dd it will show in Electrum and Bitcoin Core, but the addresses 1PasdfsTw1Mmm9E6bqcCz6dfAmsfMN4Q7f and 36T6zbUdRtR5bEEioUexWGKJRPxgwjkpAL will still show as "empty"... |
|
|
|
You can decode the aforementioned transaction's " RAW Transaction" to totally rule out that it's a dropped or an invalid transaction by checking the inputs that it used. You can get the raw txn by going to the 'transactions' tab by right-clicking the txn and selecting " copy raw transaction". To decode it, go to the console ( Window->Console) and type decoderawtransaction <space> your copied raw transaction, eg.: decoderawtransaction 0100000001e8bbee2adf46abe81d720b78ea355237bbb652955b1bf99d400d3e7e5e386d12......long string... Then check the inputs' TXID under " vin", you can use a blockexplorer to see if they are valid or already spent. Or you could just use the sendrawtransaction along with the raw transaction hex and see what error code is returned  If it says "missing inputs" then either they've already been spent, or the wallet.dat might actually be for an altcoin and not Bitcoin. As per my other post, open the wallet.dat with a text editor, search for "name" fields and see what addresses you find... if they don't start with a "1", "3" or "bc1", then it's most likely an altcoin wallet.dat |
|
|
|
Thx for reply - The wallet.dat shows up in bitcoin core and lists the transaction, is it possible to still be an altcoin? Transaction details shows the value of transfer as BTC. I will look into altcoin.
Yes, it is possible that the wallet.dat will still open in Bitcoin Core, even if it is an altcoin wallet.dat. They generally share the same file format. The "value of transfer" is simply a number in the wallet file and does not store the actual "unit"... so the "Core" wallet applications (ie. all the cloned altcoin wallets) will show that "value" in whatever currency the wallet has been set for. To check, you can try and open a copy of the wallet.dat in a text editor and do a search for "name"... you should hopefully see some entries that look like cryptocurrency "Addresses"... if they do not start with "1", "3" or "bc1", then you're likely dealing with an altcoin wallet... like this example from a DOGE wallet.dat:  You can see all the "name" records start with a "D" |
|
|
|
|
Seems like a good result all around. You've managed to secure your coins and the service is going to update their UI to hopefully prevent a similar situation from occurring for other users in the future.
|
|
|
|
|
I'm not sure if that xpub is shown anywhere other than on the screen when you originally setup the account... You could try and contact GreenAddress and ask them, as technically, it is "their" xpub...
The 2-of-3 multsig accounts are constructed from:
- Your main account seed
- Your subaccount seed
- GreenAddresses' XPUB
Theoretically, they should have a record of that xpub, as they're the ones who hold the xprv (master private key) and/or seed that the XPUB is generated from.
|
|
|
|
I was able to locate the address on Ian Coleman by using my YPUB in the BIP32 Root Key and then going to BIP 141 and changing the Script Semantics to P2WPKH and the address is there
In addition to the depth field as per the decoded key in pooya's post... When you put the YPUB in as the BIP32 Root Key, what is the "BIP32 derivation path" showing under the "BIP141" when you can see your address? |
|
|
|
Unfortunately, getting it running on that old hardware is not going to be a simple "point and click" type task... Granted there are still Linux distros out there catering to "old hardware", but they usually involve an amount of customisation to run on CPUs missing certain "modern" features and instruction sets (PAE, SSE3 etc). Without knowing the exact specs of what you're running... ie. the exact CPU/mobo model and the amount of RAM we're working with, it's difficult to make a specific recommendation on which linux distro you should try (and how to configure it). Alternatively, the "easy but more expensive" option is to simply buy updated hardware  |
|
|
|
You could try using netstat... Have a look through the list for the port number you're interested in... You may need to run it using sudo to see all the system processes etc. Or maybe one of the methods here: https://www.tecmint.com/find-out-which-process-listening-on-a-particular-port/The thing is that if you let Armory spawn ArmoryDB (ie. you just start with armory command), then it should spawn ArmoryDB with a "random" port number... and it won't use 9001. hcp@hcp-VirtualBox:~$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:52811 0.0.0.0:* LISTEN 4965/ArmoryDB
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 536/systemd-resolve
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 4720/cupsd
tcp 0 0 127.0.0.1:8223 0.0.0.0:* LISTEN 4852/python2
tcp6 0 0 ::1:631 :::* LISTEN 4720/cupsd
hcp@hcp-VirtualBox:~$
on next run: hcp@hcp-VirtualBox:~$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:62284 0.0.0.0:* LISTEN 5234/ArmoryDB
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 536/systemd-resolve
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 4720/cupsd
tcp 0 0 127.0.0.1:8223 0.0.0.0:* LISTEN 5121/python2
tcp6 0 0 ::1:631 :::* LISTEN 4720/cupsd
hcp@hcp-VirtualBox:~$
You can see the port changed from 52811 to 62284... however, if I spawn ArmoryDB manually using ArmoryDB from the terminal, it always tries for 9001 unless I use the --fcgi-port command: hcp@hcp-VirtualBox:~$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 536/systemd-resolve
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 4720/cupsd
tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 5314/ArmoryDB
tcp6 0 0 ::1:631 :::* LISTEN 4720/cupsd
hcp@hcp-VirtualBox:~$
and with ArmoryDB --fcgi-port=52828:
hcp@hcp-VirtualBox:~$ sudo netstat -ltnp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 536/systemd-resolve
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 4720/cupsd
tcp 0 0 127.0.0.1:52828 0.0.0.0:* LISTEN 5326/ArmoryDB
tcp6 0 0 ::1:631 :::* LISTEN 4720/cupsd
hcp@hcp-VirtualBox:~$
|
|
|
|
Again, you need to read (and understand) this, especially the "How much does it cost?" section: https://api.trustedcoin.com/#/electrum-help2FA wallets charge a "service" fee that is in addition to "normal" transaction fees! The 2FA service is provide by TrustedCoin and they charge you a fee to use it. If you don't want to pay this extra fee, then "restore" the wallet from your seed mnemonic and when prompted select "Disable 2FA": 1. Select "New\Restore" from the menu:  2. Give the wallet a unique name like "disabled_2fa" (to avoid any confusion in the future):  3. Select "Wallet with two factor authentication":  4. Read the "disclaimer" and click next 5. Select "I already have a seed":  6. Select "disable":  7. Add a password (Optional, but recommended)
This will create a copy of your wallet that contains 2 of the 3 master private keys. This will enable you to spend your coins "normally" without needing a 2FA code and it won't be using the TrustedCoin service. If you intend on continuing to use Electrum in the future, I would highly recommend that you create a "standard" wallet (no 2fa, no multisig etc) and then move all your coins to the new "standard" wallet. It will make things much simpler and prevent any future problems from using a "disabled 2FA" wallet. |
|
|
|
I've been "exploring cryptos" for 4 years - is there an "intro" section somewhere where we can share our crypto journeys...?
Perhaps you could put your "intro" post over in the "Beginners & Help" section... In any case, reading all the "pinned" posts in that board is a good idea... particularly the one titled " Newbies - read before posting" LOTS of good tips there. |
|
|
|
So I created an armorydb.conf in /home/stg/.armory/ --dbdir="/media/BITCORE/armory"
--satoshi-datadir="/media/BITCORE/Blockchain"
That armorydb.conf looks wrong... I believe it should just be: dbdir="/media/BITCORE/armory"
satoshi-datadir="/media/BITCORE/Blockchain"
You don't include the --'s in the .conf files. If you do, the options get ignored. It seems the comment in the pathing docs is slightly incorrect: You do not need to prepend args in the config file with double dashes (–), but their use is legal
I'm fairly sure that the double dashes causes issues in the .conf files... best not to use them. that seems to return the correct pathing no?
Yep, that seems to be picking up the correct pathing when you run it from the commandline with the "/media/BITCORE/..." paths. |
|
|
|
I was able to recreate what I did and it was the YPUB not an XPUB (Just like the sample posted), and it was all bech32 addresses that were produced for wallet addresses that the funds would be sent to. This is indeed quite confusing.... XPUB = Legacy ("1" type) Addresses YPUB = Nested SegWit ("3" type) Addresses ZPUB = Native SegWit ("bc1" type) bech32 Addresses Quite how you got bech32 addresses from a YPUB master public key is a mystery... it would point to some sort of issue within the code/library generating the addresses, as it is technically doing "non-standard" things I must be screwing up the derivation path. I'm putting in m/84'/0'/X' (X representing the account # on my Trezor) but nothing.
Note that "X" should not be the same as the account # in the Trezor wallet... the derivation path is 0-indexed... so "Account #1" on the Trezor is actually m/84'/0'/ 0'... "Account #2" would be m/84'/0'/ 1' etc. |
|
|
|
2: I forgot to mention previously, bitcoin core had not detected the already present directory in the external ssd, hence me choosing a new place to place the new directory. But after doing the steps above as you mentioned, now it has recognized the directory in the ssd and we are back in business!! Now I am only 3 days behind.
Was the external SSD disconnected at some point after you had synced to 27th Dec? If it was unplugged, then plugged back into a different USB port, or after other devices/drives were connected, it might have been due to Windows assigning it a new drive letter. This is one of the hazards of trying to use "external" devices for "(semi)permanently" connected data storage At least you now know how to rectify the issue, should it happen again. |
|
|
|
The problem are,
1. We don't know when OP access bitcoin.org
2. Bitcoin.org sometimes change list of recommended wallet due to various reason
1. "Recently"... as that is when the OP broke their phone and tried to download a wallet from bitcoin.org to their laptop. I would assume they did this sometime with a day or two of posting their message. 2. That is true, but that list hasn't changed in the last 7 days, as far as I'm aware. |
|
|
|
I get the feeling that attempting to recover these 2-of-3 "sub-accounts" is going to be extremely difficult without access to the 2FA email... I've just tried creating a new "GreenAddress" wallet... it gave me an initial mnemonic (used to login??!?). However, when I create a "2-of-3 subaccount"... it displays this:  With an additional mnemonic specific to that subaccount, and an xpub. Looking at the recovery process for "2-of-3 accounts: https://blog.greenaddress.it/2of3recovery/The options are: 1. A (most likely non-functioning) custom Electrum plugin or 2. Their "garecovery" tool: https://github.com/greenaddress/garecovery, which requires Ubuntu and a full Bitcoin Core node You also need to have: 1. Your "main" Green Address recovery mnemonic 2. The "subaccount" recovery mnemonic 3. The "subaccount" xpub (as per the screenshot above) @Reddix25, do you have all 3 of those things? |
|
|
|
I've lost my wallet.dat file and forgotten my password, but I do have my public address.
Your public address is useless. You absolutely require the wallet.dat and the password (or the private key for the address). Is there a feasible way for me to recreate a private key that matches my public address?
No, it is not possible to recreate a private key from a public address. If it was possible, bitcoin would be fundamentally broken and worthless. Anyone could steal any coins from any address. Are there any viable solutions? Thanks!
Depending on how you "lost" the wallet.dat, it might be possible to recover... was it a harddrive failure or something similar? In any case, without that wallet.dat file, your chances of recovery are practically zero. |
|
|
|
|
Show Posts
