This would tend to indicate otherwise:


Armory is "missing" about 220,000 blocks... the current block height is: 684592

I would guess that your transaction was in a "recent" block (ie. > Block 465293). Until Armory can see that block that your transaction was confirmed in, then you will not see that transaction in Armory.


Armory is not fully synced... so either your Bitcoin Core is not fully synced, or something has gone wrong when Armory has attempted to read the block data from the Bitcoin Core data directory.

Check in Bitcoin Core (Window -> Information) and see what the "current block height" value is... if that isn't somewhere near 684592, then your Bitcoin Core is not properly synced... and you'll need to fix that. Have you checked how much free space you have on your PC? Bitcoin Core requires some 350-400gigs of storage space at the moment.

If the "current block height" in Bitcoin Core is 684592 or greater, then the issue is likely with Armory. However, to diagnose that, you will need to post your armorylog.txt and dbLog.txt files to pastebin, then post the pastebin URLs here

Definitely much much higher than I would personally consider as "acceptable"... Email is a terrible unreliable method of storing or sending any sort of private data.

If you're just trying to stop yourself spending coins, you'd be better off using OP_CLTV (CheckLockTimeVerify), which prevents spending individual UTXOs until a certain time... and then securing your private keys in an appropriate manner.

But, as bob123 asked, what exactly are you attempting to do... and what are your specific requirements?

Generally speaking, almost anything is hackable given enough time, money and resources... I don't see why "Digital Currency Wallets" would be any different.

The issue is that, again generally speaking, most "Digital Currency Wallets" provide mechanisms to make the required amounts of time, money and resources so vast that it is simply not temporally of economically feasible to do so.

And then users use passwords like "password" or "abc123" or <dogs-name>+<date of birth> etc.

Yes, you can try using hashcat: https://hashcat.net/hashcat/

You can extract the "hash" that hashcat uses to test password guesses by using the JohnTheRipper script "Bitcoin2John.py": https://github.com/openwall/john/blob/bleeding-jumbo/run/bitcoin2john.py

And then you can try "mask" attacks (or maybe even wordlists): https://hashcat.net/wiki/doku.php?id=mask_attack


This (rather enthusiastic) youtube tutorial explains the basics fairly well and should be a good starting point: https://www.youtube.com/watch?v=d1Y6TPGzVn0


Note: If you don't have a fairly decent GPU (ideally a highend GTX 10,20 or 30 series, ie. 1080, 2080, 3080 etc), attempting to bruteforce the password is going to be incredibly slow regardless of what program you attempt to use.

An option is to use the "hash" generated by Bitcoin2John.py and getting someone else to attempt to crack it for you using their system (with powerful GPU(s))... Note that they can't get your coins from just the hash, all they can do is find the correct wallet password.

So, NEVER give the wallet.dat to anyone... only give the extracted hash!

Found a reference to these wkey's here: https://renenyffenegger.ch/notes/development/Crypto-Currencies/Bitcoin/wallet

It seems they are no longer used:


Indeed, the most recent versions seem to have removed support completely:

Support was dropped in this commit: https://github.com/bitcoin/bitcoin/commit/0b1f4b3c6685d0a6307926d43d166add538061b7#diff-49a07da77d79017222ba989b99048c0a629d3230988ce7b6b74df0d14f727626


Anyway... it looks like this "wkey" may indeed contain a Private key:

You can see the privkey being read out of the wkey object.


The definition of the "OldKey" struct is here: https://github.com/bitcoin/bitcoin/blob/914923d125f5d17b39b4dc05f666d130e80a68b2/src/wallet/wallet.h#L679

Not quite sure how that relates to the raw hex in the wallet file tho... Seems you might just be better off attempting to load the wallet file with an old version of Bitcoin Core (ie. <= 0.18) which should be able to handle the wkey records properly.

Have you logged a description of this issue over on the Bitcoin Core github issue register? https://github.com/bitcoin/bitcoin/issues

It seems to me that you might get a better response from the developers by posting there.

There is nothing "obvious" in the debug as to why the app keeps shutting down when you receive a transaction from nicehash. Have you checked the Windows Event Viewer to see if there are any errors logged there for Bitcoin-Qt.exe?

Also, have you successfully received transactions from other sources? ie. Does Bitcoin Core shutdown when receiving any transaction... or does it only do it when you are receiving a transaction specifically from a nicehash payout?

The problem with the solution offered by BitMaxz, is that I suspect the bulk of your coins are on a change address... NOT a receiving address. Bitcoin Core treats change addresses as "internal only" and tends to hide their existence from you. As such, change addresses will NOT be displayed in the "Receiving Addresses" list


However, you can actually get Bitcoin Core to display ALL your current "Unspent Transaction Outputs" (aka UTXOs) in a fairly easy manner...

1. Set Bitcoin Core to enable "Coin Control Features"
- Goto: Settings -> Options:



- Select the "Wallet" tab... and make sure that "Enable Coin Control Features" is TICKED:



2. View all available UTXOs:
- On the main Bitcoin Core screen, select the "Send" Tab:



- You should now see the new section at the top labelled "Coin Control Features"... click the "Inputs..." button:


Assuming that your Bitcoin Core is fully synced and scanned (like your encrypted wallet should be), You'll see a list of all the coins that your wallet believes are currently available to be spent by your wallet. You will also see any "change" addresses listed with the label "(change)" as per the screenshot above. By default, "receive" addresses will tend to have "(no label)", but they can also have user-defined labels if one was manually added.

Each UTXO will also have the associated address listed with it... which you can easily copy by right clicking on the appropriate line and selecting "copy address" from the pop up menu... you can then paste the address into the blockexplorer of your choice to confirm that the coins/balance are correct etc.

You can also get the Transaction ID for the transaction that created that specific UTXO from the same pop up menu.


Hopefully, this method will allow you to see exactly which addresses your coins are currently associated with, and whether those addresses are "change" addresses, or "receive" addresses.

Rather than poll on what single item is the most important to users, I think you should ask users to rank all the items in order of priority. Then collate the results to get an indication of which items are considered by the majority to be the ones to focus on.

Personally... I would probably rank it as:
1. Security
2. Ease of Use
3. Price
4. Look
5. Number of currencies it supports
6. Touch Screen


But honestly... 4, 5 & 6 don't really bother me much... as long as you have 1, 2 & 3

Theoretically, you can quite happily use whatever combination of whatever words you like... regardless of the checksum... you'll still be able to convert those words to a "valid" 256 bit seed (following the BIP39 algorithm), which can then be used to generate "valid" addresses.

The issue with not having a valid checksum, is that no "strictly" BIP39 compatible wallet will (or should) accept your 24 words... as it will be "invalid". Having said that, I know of at least one wallet^[1] that will indeed allow you to input and use a set of 24 words that fail the BIP39 checksum test.

Additionally, without a valid checksum, you have no way of knowing/testing that you have actually recorded the correct words in the correct order. This could lead to numerous issues in the future should you need to attempt wallet recovery.

TLDR; not having a valid checksum is a "bad idea"™



[1] Electrum

I don't see any unconfirmed transactions for this address? Or are you saying that you have an unconfirmed (withdrawal) transaction from your ByBit account?

Looking up deposit addresses on an exchange and trying to match it to your account activity (trades/transfers/exchanges + withdrawals) is meaningless. None of the activity (except for deposits and withdrawals) is done onchain, and the coins you put into your deposit address are unlikely to be the coins you get back when you withdraw... and all the trades/transfers/exchanges etc are just numbers in their database and you won't be able to track that by looking at blockchain data.


Once you start using your exchange account to trade/transfer/exchange/withdraw, then the balance in your deposit address is in no way indicative of what your account balance could or should be.

ByBit, could leave all the money you have ever deposited into that address there for years... or remove it all the second it is deposited... and it would make no difference to your "account" balance.

What you need to do is check to make sure that all your account history within your ByBit account adds up. If all the deposits + trades/transfers/exchanges + withdrawals add up to your current account balance of zero, then it is safe to assume that everything is OK.

However, if you find that deposits + transfers/exchanges + withdrawals do not match your account balance, then you'll need to contact ByBit support and ask them why.

Seems like your transaction: c88171092b0992812cef1a0ae73e4c4e4b2f5b95b06047e00f8690408153e7e5 was confirmed several hours ago.

Hopefully, while you were waiting, you have managed to find a better alternative to Jaxx... it might look "pretty", but it's a "pretty terrible" wallet to be honest.

Did you try disconnecting/unplugging the hardware wallet... and then shutting down Electrum (and/or even restarting the computer completely)... and then try repairing your Trezor with the multisig wallet?

I've had issues in the past with Electrum when trying to switch from one hardware wallet to another hardware wallet without disconnecting the device... where the device won't be "detected" after trying to switch wallets until I shut everything down and then start again.

Correct... Bitcoin Core has only ever supported signing messages from Legacy addresses.

Verifying signed messages that have used SegWit address (nested or native) can be problematic. I've seen issues where messages signed using a Nested SegWit address by the Trezor wallet software could only be verified in Trezor wallet. While messages signed in Mycelium or Electrum could generally be verified in both.

Even the modified BrainwalletX verification tool that supposedly supports P2SH-P2WPKH (Nested SegWit) addresses (https://jhoenicke.github.io/brainwallet.github.io/#verify) struggles with signed messages from some sources

One of the advantages of Bitcoin Core I guess... it will generate legacy, nested or native segwit... all from the same seed/wallet... and you can do so "at will", by simply specifying the type you want when using getnewaddress

don't use the getaccountaddress command... just use the output address that you found from the last send transaction that shows "ismine: true" in the "encrypted" wallet.dat (and "ismine: false" in the old wallet.dat)... That address is where the "missing" coins are.

Then simply search that address on blockchain.com and see what the history/balance of that address is.


Also, I suspect you're using an old version of Bitcoin Core... getaccountaddress was deprecated several versions ago (v0.17 and removed in v0.18)...

Correct, you can import an address into Blockchain.com wallet (ie. a "watching-only" wallet) and 1Blockchain.com will be able to monitor the transactions and balance etc... but you won't be able to send any transactions without the private key.


Probably not. As far as I can tell, Bittylicious does not generate private keys or have wallet functionality available to users. You need to already have a wallet of some kind (web wallet like blockchain, paper wallet, desktop wallet like multibit/electrum etc) and when you buy bitcoins, you enter you wallet address and Bittylicious sends the coins directly to that wallet address.


Without seeing the paper wallet and it's design etc. it's impossible to say really... but I am fairly sure that you didn't get it from either Blockchain or Bittylicious... I don't think either of those services ever produced "paperwallets".



I don't think you imported it from Bittylicious. You would have sent the coins to a bitcoin address when purchasing them from Bittylicious... but Bittylicious does not generate private key/addresses for you.


Can you see if the letters/numbers underneath the QR code start with a "5", an "L" or a "K"? If it does... then those letters/numbers are indeed the private key that is on the paper wallet (no guarantees that it is the private key that matches your imported address, but it is a good start)


I don't think so... not if the only thing you have in blockchain.com wallet is an address... the private key was likely generated elsewhere.

---

At this point I would suggest:

1. Getting a magnifying glass and attempting to read the letters/numbers underneath the QR code
or
2. Make a physical copy of the QR Code using a photocopier and then darken up the QRCode code on the copy by hand with a pen/marker
or
3. You could attempt to make a copy of the QR Code and then darken up the image (using photoshop or similar) so it can be read by your phone
or
4. Attempt to re-create the QR Code in a QR Code generator app that allows pixel by pixel editing, like this: https://www.pixilart.com/draw/qr-code-c70c8f58df


Note that making a digital copy of the QR Code (ie. options #3 and #4) is NOT recommended unless you are happy that your computer is malware free... if someone gets hold of that QRCode, they could take your coins... which, being 2 BTC, is quite a significant sum. Appropriate precautions should be taken.

I would personally attempt #1 first.

As I suspected... at some point after adding the encryption passphrase to the wallet.dat, you have then spent some coins using the "encrypted" wallet.dat... and that transaction has created "change" which was sent to a "change" address that is not in your "old unencrypted" wallet.dat

Effectively, the only way you're going to be able to recover all your coins, is to recover your wallet passphrase... All this to-ing and fro-ing with checking address balances and stuff really doesn't matter.

You've synced the blockchain, and you've rescanned the "encrypted" wallet.dat... you can be confident that the balance it is showing is "correct". However, without the wallet passphrase, you're not going to be able to get the full balance... as there are coins controlled by private keys that you cannot access. As, you have limited access to some of the keys with the "unencrypted" wallet.dat, then you'll only be able to get the balance that is shown in the "unencrypted" wallet (assuming that the unencrypted wallet has been fully synced/rescanned).

---

So, it now boils down to this:

- Do you have any idea at all what the passphrase might be?
- Did you ever make notes about your passwords?
- Did you use a common set of passphrases for things back when you were using these wallets?
- Did you use a common "structure" to your passphrases (ie. 6 chars starting with 1 uppercase + 4 numbers)?
- Were your passphrases relatively short (<=10 chars)?
- Just letters+numbers or did you use "special" characters like !@#$%^&*()_+ etc?

Your chances of recovering the passphrase depend on the answers to these questions.

Effectively no... they are, for all intents and purposes, exactly the same... as long as you use "128" and "standard" parameters when calling make_seed()

If you use different values, then it will generate seeds with different amounts of entropy or different features, ie. 2fa etc.

That depends on the wallet... and the way it is deriving addresses... theoretically (according to the registered coin types in SLIP0132), Bitcoin mainnet should be using the "coin" value of "0":
m/44'/0'/0'
m/49'/0'/0'
m/84'/0'/0'

whereas... Bitcoin testnet should be using "coin" value of "1":
m/44'/1'/0'
m/49'/1'/0'
m/84'/1'/0'


So, the account extended xpubs etc, should be different for each network... even when they are generated from the same seed.

oh... you're running a pruned wallet... that could potentially be problematic with attempting to "sync" (ie. rescan) a wallet.dat file... Bitcoin Core can't scan blocks it doesn't have on disk... so if your node is pruned, it can't scan the pruned blocks... hence the error message about needing to "reindex" (and redownload the missing blocks).

However, using the getaddressinfo should still identify which address you have the private keys to... regardless of whether the wallet.dat is properly synced (rescanned) or not... and regardless of whether or not the node is pruned... and regardless of whether or not the node is fully synced (ie. all blocks downloaded/indexed)

How many output addresses where in the last send transaction? One... or two?

If there is only one, then it's likely an external address... so try going back to the next "Send" transaction... and find the output addresses from that and check those... you're really trying to find the most "send" transaction that has at least two output addresses.

Bitcoin Core defaults to opening the last wallet that you had open when you shut it down. If you shut down Bitcoin Core (without explicitly closing the wallet file first, using "File -> Close Wallet") and then subsequently deleted the wallet file, then Bitcoin Core will be attempting to automatically re-open a (now) non-existant file.

If NotATether's solution doesn't work, also make sure that there isn't a "wallet=" line in the bitcoin.conf file... although, I concur with NotATether that the most likely culprit will be the "wallet" value in your settings.json file (which should be located in your Bitcoin Core datadir)

If you want to prevent this from happening again in the future... whenever you are planning to delete a wallet.dat file... make sure that you use the "File -> Close Wallet" option in Bitcoin Core to make sure the wallet file has been properly "closed" before you shutdown Bitcoin Core... Bitcoin Core will then remove it from the settings.json record and will not attempt to re-open the wallet when the application is re-started.