1.6.1 from August 2020 is the latest firmware for the Nano S.

You can always check here: https://support.ledger.com/hc/en-us/articles/360010446000-Ledger-Nano-S-firmware-release-notes


Ledger Live... and some of the coin apps... however have had plenty of updates

They say they won't store your email address... at worst, they might be creating their own list of "ledger owner email addresses"... at best they're doing the community a favour. Up to you to decide if you trust them or not.

Email address isn't a "huge" deal... they're easy enough to change and/or filter... you'll just get spam... and likely face hacking attempts on your email accounts (make sure your passwords are strong!)

Phone number is relatively annoying... no so easy to change and/or filter... people are being bombarded with texts and robo-calls. Also, opens you up to the possibility of "sim swap" attack, so any SMS based 2FA could be at risk.

Address is "dangerous"... at the very extreme, you could potentially face the threat of home invasion.

Install the "Recovery Check" app on your Nano S: https://support.ledger.com/hc/en-us/articles/360007223753-Recovery-Check

Use it to confirm that the seed you have written down/stored offline is indeed the seed currently in use by your device. If that checks out feel free to do whatever you like in terms of sending coins to your device.

Some people will send a small amount to test before loading the bulk of their coins. Others will just send away. Some people will send with low fees regardless of network conditions as they don't want to spend money on fees... others want quick confirmation times and will send with high fees to get the coins their quickly.

As for sending amounts... it depends how you envision spending coins in the future... by sending say all your 5 BTC at once, you end up with 1 UTXO... however, when you go to spend in the future, the entire world will be able to see that the address had 5 BTC on it, which means the owner had at least 5 BTC... regardless of how much you actually try to send.

So, some folks like to keep a "range" of UTXOs on different addresses... say, 10, 1, 0.1, 0.01 etc... That way they can use "coin control" to spend an appropriately sized UTXO for what they're trying to send to "obscure" their total holdings... ie. if they only want to send 0.1, they can use just the 0.1 and 0.01 UTXOs (got to cover that fee! ) and then anyone who sees the transaction will only be able to tell that the owner had at least 0.11 BTC... but they won't see the other 11+ BTC on different addresses

However, if you anticipate that you may need to shift the vast majority of your holdings somewhere, (ie. sending all to exchange to cash out)... then having a lot of smaller UTXO's will end up costing you more in transaction fees.

There is no "one size fits all" solution to this... So you're just going to have to sit down and think what your most likely scenarios are... and then create a system that works for that.

It's a "valid" Bitcoin address... but the private key for that address is not in the wallet.dat that is currently loaded by Bitcoin-QT.

Instead, that is an address that has been added to the "Address Book"

If the private key was available, you would see something like this:



If it was just a random address, you would see output like this:



Once it has been added to the "address book":



It will have an "account" value displayed when you use validateaddress:




Unfortunately, it appears you are chasing shadows with this wallet.dat... the $1.7mil worth of BTC is not in this wallet.dat

Seems like the old 0.8.6 version does not have a dumpwallet command on the console. So, as far as I can tell, the only way to do it would be using the dumpprivkey command, one address at a time

I guess that this is one of the reasons why scripts like PyWallet were originally created, so you could simply dump the whole wallet at once.

Not really.

The network is in constant flux... New transactions are being added all the time (at various rates)... while transactions are being removed from the holding pool due to being included in a block (again, at various rates due to the variability of block times).

So, the number of unconfirmed transactions and their fee rates used are constantly changing... ie. the goal posts are always shifting.

Trying to program a fee estimation tool is not as simple as you might think... if you err on the side of "fast confirmation", you'll end up with a wallet that uses higher fees and users will complain. If you err on the side "lower fees", there is a chance that user transactions will get stuck... and users will complain!

Typically what happens is that simply relying on whatever a wallet selects, is going to result in a less than optimal result... you'll either overpay or your transaction will take longer to confirm. The ideal solution is to do what you have done and learn about fee rates, the network, the "mempool" and how to deduce what a "good" fee rate is manually...

However, some people want "easy"... and just want to click a button... so they pay for that convenience with either higher fees or longer confirmation times

What was the refund address and public key that you entered when you registered on this site?


The private key, will likely be the one that is paired with the public key that you entered when you registered on the site. Unfortunately for you, there is no way to go from public key -> private key (otherwise the entire system would be fundamentally broken! )

At best, we can identify what the address is (convert the public key to address, see below), and then hopefully you will be able to find that address in your Electrum wallet and will be able to export the private key from it.

---

---

You can convert the public key to address really easily here: https://gobittest.appspot.com/Address

Simply copy/paste the public key into Box labelled: "1 - Public ECDSA Key" and click "send":


It'll most likely give you the "Invalid Public Key Length" error... but you can ignore that (the site was designed for older uncompressed public keys that start with 04, but still works with compressed public keys that start with 02 or 03)... then simply scroll down to Box labelled: "9 - Base58 encoding of 8"... and it will show the address associated with that public key:

Do realise that by sliding the slider to the left... you will have reduced the fee rate being used... it may have let you send the transaction, but it might mean that your transaction remains unconfirmed for a while if the fee rate used was too low.

You should check your transaction details and see what the fee rate used was and compare it with the fees here: https://mempool.space/ and here: https://jochen-hoenicke.de/queue/#BTC,24h,weight

What was the rate used?

If you just want to copy/paste the address only without all the Bitcoin Payment URI stuff... tap the "address" box here:



It'll open a new window with a different QR code that encodes just the address... So, you can either scan that or you can tap the "copy" button and it will copy the address to the clipboard:

There is a "Search engine" for the database leak here: https://www.argent.xyz/ledgerhack/

You simply enter your email address associated with your Ledger purchase and it will tell you if:

a. it didn't find that email address at all
b. it found only your email address in the leaked data
c. it found your email address and other details like address and phone number etc in the leaked data

When you click "Pay", you should see a prompt like this:


What are the mining fee details that it is showing you? Or are you getting the "not enough funds" error on that prompt when you click "Pay"?

If so, I suspect that it's because the fee rate being suggested is likely resulting in a transaction fee being >=10000 sats (or 0.00010000 BTC)... which is slightly more than the difference between what you're trying to send (0.00059000 BTC) and what you have (0.00068790)... which is 0.00009790 BTC.

If you tap the bold text next to "Target(....)"... it should cycle between "ETA", "mempool" and "static"... put it on static and slide the slider to the left until the "not enough funds" message goes away... then check what the fee rate is shown as. If that value is too low, you'll need to wait until the fees lower or your transaction might get stuck for a few hours/days before it gets confirmed.


Perhaps... but if Bitcoin goes on another mini-Bullrun and spikes back up over USD$60K... things could get really busy again and we could go back to the 200+ sats/byte fees again :-/

"Receive -> Request" will give you the "first" unused address from your wallet... it is probably the best way to get an address to "send yourself coins" (or to give to someone else so they can send you coins), unless you really know what you're doing and need/want to see a specific address from your wallet. I would recommend you use this method.


This method is basically just showing you ALL your receiving addresses at once. it also indicates which ones are "used" (aka have received coins) and which ones are "unused".

Electrum is what is known as a "Hierarchical Deterministic" or "HD" Wallet... this means that it uses a "seed" (derived from the 12 words you would have been shown when you created the wallet) and from that seed it will be able to automatically generate an endless number of receiving addresses. Electrum, by default, pre-generates around 25 addresses. As they become "used" (ie. they receive coins), the wallet will generate new "unused" addresses. This list shows all the ones that it has currently generated.

The reason to use a new address for each receive transaction is to prevent/reduce "Address re-use", which can reduce privacy of both the sender and receiver. It's not really a security issue. You can read more about that topic here: https://en.bitcoin.it/wiki/Address_reuse


The "Change" button, just switches the list from receiving addresses to "change" addresses (You don't really need to worry about change addresses, Electrum will use them automatically and you should not use them as an address to receive coins from an external source.)

weird... then is the highlighted text that has been partially redacted the Bitcoin Address? Because it doesn't look like that address is used in that transaction at all??!?

But like I said, it is very difficult to interpret what is going on when you're only providing heavily edited data

In any case, you're just looking at a debug.log from an early version of BitcoinQT (aka Bitcoin Core)... You likely won't discover anything of great value by analysing this.

I'm not sure how that relates to the "NotifyAddressBookChanged" snippet that I posted... the mostly obscured highlighted text (which should be the Bitcoin address) listed in there does not seem to match either of the addresses displayed in that transaction...

It's difficult because all the debug has been partially redacted, but I don't see the text: "MQwdmSZfau9X" in either of those addresses... are you sure you are looking at the correct transaction?

If you actually click on the invididual transactions, it should show you the fees. A lot of (most? all?) wallets don't show the transaction fee on the transaction history page... it is usually only shown on the transaction detail page.

The transaction history page will usually show you the total amount that was spent (being the total sent + transaction fee).

I think some of this confusion has simply been caused by the fast sync giving you an incorrect balance, when you then believe to be your actual balance... and then the shock of seeing the actual balance as reported by Electrum.

The money hasn't been lost or stolen or anything like that... it was simply an issue with the BRD fast sync (and to a certain extent your memory) reporting an incorrect amount which lead you to believe you had more coins than you actually did.

There is also a great guide from Direwolf regarding downloading and verifying Electrum: https://bitcointalk.org/index.php?topic=5240594.0

Assuming you have already done that before... following the link should be OK... personally, I see the notification and then go and manually Electrum from electrum.org (and verify the digital signatures, of course)

No... it was the client accepting a "Transaction" (most likely from an external peer) as being "valid" and adding it to the local mempool of the node. It is not necessarily a transaction that the user of the local node was creating/broadcasting.


The thing that should concern you the most about that address is the fact that it says "ismine=0"... this, combined with the fact that it is being output from the "NotifyAddressBookChanged" function would tend to indicate that it had either been added as a "watching-only" address, or as a "Destination Address" (ie. an address that you're going to send coins to)... as the wallet does not appear to contain the private key for that address... otherwise it would have stated "ismine=1"

I would check the TXID that looks like it is output after it... and see if that TX was "Receiving" coins to that address... I suspect it was.

Not overly familiar with the Dogecoin Core client (I've used it but not extensively)... but it might have the -salvagewallet option that might be able to recover something?

Failing that, Python2.7 and an old copy of PyWallet before the latest 2021 updates (made by JackJack recently) might be your best bet with a Dogecoin wallet.dat. Either this version from the last commit back in 2014... or you can try my one here: https://github.com/HardCorePawn/pywallet

Basically, the only mods I had made from the 2014 version were to stop it complaining about "key-meta" records and such that were in "newer" wallet.dat's.

Do you actually have Bitcoin Core installed and fully synced? If so, what versions of Armory and Bitcoin Core do you have installed?

Where did you download Armory from? Was it btcarmory.com or www.bitcoinarmory.com? If it was from bitcoinarmory.com, you got an old outdated version. You must download Armory from here: https://btcarmory.com/ (latest version is 0.96.5)

If you don't have Bitcoin Core installed, Armory will not work correctly. Armory requires a fully synced, unpruned Bitcoin Core node to be able to function correctly.


If you're new to Cryptocurrency and Bitcoin, then I would probably suggest that you might want to investigate other desktop wallets like Electrum... (or maybe start with: https://bitcoin.org/en/choose-your-wallet)

Armory, while a very secure wallet, can be quite complex and difficult to get setup and running correctly... and not a wallet I would generally recommend to beginners.

It looks like the contents of a debug log file... I doubt it is a wallet file and/or will contain any private key data

CTxMemPool::accept() followed by the 64 hex chars is most likely a transaction ID... try doing a search on a blockexplorer for one of those 64 character hex strings to confirm.