Wait... so the 0.0139 BTC amount is what you have calculated manually using the values in the CSV... but the wallet application is only showing a balance of 0.00382 BTC?

If so, did you add up the fee column in the CSV and check what all the fee's total up to?

I've seen that error before... it is usually the result of not being able to create the __db.00x files in the "datadir" given... is your F:\ actually writeable? Maybe create a subdirectory on F:\ and put the wallet file in that... and then pass the path to that subdirectory as the --datadir value.


Addtionally, I've created a "dirty" little Python script that will take an unencrypted wallet.dat and does a byte search through the file looking for "0201010420" hex markers. It then grabs the next 32 bytes (which should be a private key), converts them to both uncompressed and compressed WIF format and outputs to STDOUT (along with the generated addresses so you can search for a key by address if required)

Script is here: https://github.com/HardCorePawn/dump_unenc_keys

Note that this only works with Python 3... it is does NOT work on Python 2.

What Bitcoin wallet did you try to send to? Was it Bitcoin Core or Electrum or something else? And did the bitcoin address that you sent the LTC to start with a "1" or a "3"?

Yeah... you're now looking at fees in excess of 200 sats/vbyte to stand any chance of "quick" confirmation times... 60 sats/vbyte is over 36 MB from the tip. That's at least 6 hours assuming no new transactions are added! and it doesn't look like the transaction rate is slowing down.

mempoolminfee is over 13 sats/vbyte!

I remember the #goodOldDays when I used to be able to send 1 sat/vbyte transactions and get confirmation in an hour

Bitcoin dropped almost 10% the other day... in less than 30 minutes!!?! So, trying to send an "exact" amount of fiat using BTC is a fool's errand... you might get close, but the value when you send will likely not be the value when it is received/confirmed.

If you need to send an exact "fiat" amount... then you should use "fiat" transfer services

Otherwise, you will need to agree to an exact amount of BTC with whomever you are sending to or receiving from. Once both parties have agreed on a set amount of BTC, then that amount should be sent... any variance in the fiat value of BTC is then irrelevant.

The wallet file seems to have a space in the name... Is that correct? If so you'll need to wrap it in " "s otherwise Python thinks you have moved onto the next option...

Only insofar that you would be unable to recover your coins using Electrum in the event that your device was lost/stolen/damaged.

However, as long as Electrum kept the Trezor/Ledger plugins, the devices themselves would still be able to continue to function normally. After all, the HW BIP39 seed is never actually used by Electrum for anything (nor should it be except for emergency recovery), so whether the device is using a BIP39 seed or not makes zero difference. Electrum only ever receives an Xpub from the device (for creating the watching-only wallet), so unless the Electrum dev's decided to also do away with BIP32 and xpub support etc, everything should continue to work.

It should be noted that this is just one method of encrypting a wallet... Not all wallets employ this particular method of encryption.

Indeed it seems that this is the method specifically employed by Bitcoin Core for encrypting private key data in the wallet.dat file.

There is also good ol' PyWallet... it has a "recover" option for scanning for deleted wallets etc... it does require some ability with commandline, as it is a Python script with no GUI etc: https://github.com/jackjack-jj/pywallet

It's suitable only for old "Bitcoin Core" (and altcoin clone) wallet applications that use the BerkeleyDB "wallet.dat" file format.

There are also the more generic "data recovery" apps like Recuva, EaseUS etc...

Or you can hex search for various markers used in wallet.dat's... like the ones listed here: https://bitcoin.stackexchange.com/questions/41447/filesystem-is-corrupt-how-to-find-wallet-dat

If you suspect that files were deleted, you should "clone" the drives/create raw binary images of the drives and work on the images to prevent any further data lose etc.


If you don't think files were deleted, you could just search old drives for .dat files, but that might throw up a lot of "false positives" as numerous applications use .dat as a generic "Data file" extension. You could also search for "bitcoin" or "btc" or "wallet" or "crypto"...

Note that "wallet" and "crypto" might throw up the odd false positive or two as Windows has some files and folders that include "wallet" and/or "crypto" that have no relation to cryptocurrency whatsoever.

Is the transaction history showing a transaction spending the balance? If so, when was it spent? recently or several years ago?

Pretty sure one of the RBF rules is that the fee has to be higher... and has to be higher by at least the minimum relay fee for another transaction. The idea being to prevent "DoS" attacks by spamming new replacement transactions etc... and also to encourage miners to not violate the system by taking an "earlier" transaction that paid a higher fee etc.

Refer: https://bitcoincore.org/en/faq/optin_rbf/#who-invented-unconfirmed-transaction-replacement-does-it-go-against-the-vision-of-bitcoin

Correct... seems the fee rates have dropped back slightly and your transaction got confirmed!

At this time: 20210418-0800 it seems anything above 120 sats/vbyte is getting confirmed.

Bitcoin Core 0.8.6 is available on the Bitcoin Core download repository... you just have to "hunt" for it a little bit: https://bitcoincore.org/bin/insecure/bitcoin-core-0.8.6/

Do note that this is in the "insecure" folder for a reason... there are security vulnerabilities in this old versions. Caution is advised.

Because of the unfixable security vulnerability in the Trezor ONE, most users would probably regard the passphrase as "required" (and a relatively long, complex one at that!) to maintain the "same level" of security as most hardware wallets provide.

As already noted, without the passphrase, your seed and therefore your private keys are trivially easy to get access to for anyone with physical access to your hardware wallet. A desktop wallet with a password would have more protection!

So, it depends on your personal risk profile/acceptance... if you're satisfied that the odds of the device being physically compromised are lower than forgetting your passphrase then it's not "required" per se.

At this time, there are no known exploits to be able to remotely hack the device.

00 is a perfectly valid byte value in a private key... all values between 0x01 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140 are valid private keys.

refer: https://developer.bitcoin.org/devguide/wallets.html#private-key-formats

check this on bitaddress

Does the return time increase if you request the same block over and over? or is it increasing for a specific "set" of blocks?

If there is a particular block or blocks where it always takes a long time, have you checked those blocks manually to see if there are any attributes of the blocks that might cause the slowdown? ie. transactions with large number of outputs or transactions with large number of inputs etc.

it's also possible that your node is throttling your RPC connection because you're making repeated calls to getrawtransaction... I've never experienced that myself, but I've never had a script that has the potential to make repeated calls over and over either.

I believe these are the markers that it uses: https://github.com/jackjack-jj/pywallet/blob/master/pywallet.py#L165

How big was your "bigger fee"? The network is massively overloaded at the moment... fees are ridiculous... you'll likely need a fee rate of 175+sats/vbyte to have any chance of getting your transaction confirmed in a reasonable amount of time at the moment

refer: https://mempool.space/
and https://jochen-hoenicke.de/queue/#BTC,24h,weight

Right... so you managed to recover the private key for your CNI address then? If so, that's great news!

As for trying to bruteforce a key with missing HEX characters, it's technically possible, but the big question is how many characters are missing? If it's more than 8-10 characters missing is going to take quite a long time... 9 missing characters would be: 68719476736 possible combinations... 10 missing characters is: 1099511627776 possibilities... and it just keeps growing exponentially.

If you were indeed sending to the "3NftS...x" address... then I have some bad news for you. Because you didn't send 0.0055 BTC... you've sent 0.0055 mBTC!!?!   which is only 550 sats!
https://www.blockchain.com/btc/tx/dca6be0411b6c796a95ec5ec574aa312cc4b3f97638aa821d47e5b209c1a19ba


What wallet were you sending the coins from?


I suspect the alert was trying to warn you that you were about to spend 0.00018150 BTC to send only 0.00000550 BTC!!?!