Blockchain.info shows your first transaction. But with a fee of 1 sat/B it won't get confirmed.
However.. blockcypher[1] for example abandoned your first transaction and recieved your second transaction sitting in their mempool.
In this case you have to wait until a miner (with the 2nd tx in the mempool) will mine a block and include your transaction into it.
Quite a few don't even accept transaction with 1 sat/B anymore.. so this TX probably will get 'dropped from the network' soon.

[1] https://live.blockcypher.com/btc/tx/3c25bb7e62833533c87aea751f8998701ac6771fc6a684fad63a2126c49c0962/

Both of your transaction do not exist in the network and both of your addresses show zero balance.
Are these the recieving or sending addresses? Please provide more information. So far it seems nothing happend (no btc's has been sent).
If one of these addresses should contain an amount (sending address), could you please check the incoming transaction (whether it has been confirmed).

There are quite a few tutorials available online. One example: https://daniel-lima.github.io/bitcoin-devenv/docker/how-to/compile-bitcoin-core-for-windows.html.

The easiest probably is to just compile it (windows version) in linux.
If you have no clue about linux i can't imagine why you would need to compile it yourself.

If you just want to verify the integrity you can use the checksum.
On windows: certUtil -hashfile bitcoin-0.15.1-win32.zip SHA256
Compare the hash to the officially stated at github.

You can't check every address derivated by a seed. Addresses are being generated on demand. Up to 'an infinite amount'.
Ledgers chrome app is 'generating' them 1 by 1. And Electrum does generate about 20 at once, and more on demand.
There is nothing wrong with the ledgers chrome app only checking the balance one by one, because thats how they implemented their UI.

Exporting seems to be the easiest solution to this strange behaviour.
You can export your xprv-key by clicking on your account -> "export" from menu and then write the xpriv key down by hand (xpriv, not xpub).
Afterwards you could download electrum[1] for example, which allows to import xpriv keys.
But be careful with your xpriv-key. Everyone who has access to it has access to your bitcoins. Don't import it into an infected/public pc.

[1] https://electrum.org/#home

Like written earlier, this tool:
can check all possible words if you got 1 word wrong.

Now, since you have 23 words.. you could call that 23 correct words + 1 wrong word.
Now try to make 24 seeds with your 23 correct words and your 1 wrong word starting at position 1, moving always one to the right.
So your second seed to check has the wrong word in the 2nd position, your third seed in the 3rd position, and so on..

Afterwards you run the script mentionoed above on all 24 seeds. The script will replace the wrong word with all possible words (for each of your 24 possible missing word-positions).


As far as i know there is no script yet which does exactly this. But you can easily do this 'by hand' or write a small python script by yourself which
calls the recovery-script 24 time with different seeds. If you are not a 'friend of computer' at all:

Bitlocker is not open source. And additionally its made by microsoft. You have no clue whether they implemented any backdoors, etc..
Veracrypt on the other hand IS open source and is more trustworthy than bitlocker by far (in terms of security).
Plus Bitlocker is not free (requires windows PRO version), where veracrypt is completely free.

Next time just create a new thread please.

Did you already try to unlock your nano s + open bitcoin application before setting up your electrum wallet?
And did you scroll down to settings and check for "Browser Support" being disabled.

This might also be the issue. A lot of user are complaining about jaxx recently.
Most of them seem to be unable to send any funds (mostly connection issues).
This could be your problem too, it would explain why your balance got deducted first (jaxx trying to send funds) and
afterwards it appeared again (jaxx failed to connect to push tx(?)).

You can try to send your funds again (but make sure to include a high enough fee: https://bitcoinfees.earn.com/).
If you furthermore won't be able to send anything out from jaxx you can [1] export your private keys and [2] import them into another wallet (e.g. electrum).

[1] https://decentral.zendesk.com/hc/en-us/articles/218375657-How-can-I-view-my-private-keys-
[2] http://docs.electrum.org/en/latest/faq.html#can-i-import-private-keys-from-other-bitcoin-clients

You could iterate the 'wrong-world-role' between those 24 positions, running the script 24 times.
Its just 24 times slower than the 'normal usage'.. its still doable (and pretty straight forward).

Did you just plug your old HD into your new pc and used it as an additional (non-main) HD? Or did you wipe it before?
Or are you using your old harddrive as your main (OS-) harddrive? Its crucial to know how you 'handled' those drives the whole time.

If you are serious about the recovery of your files and you already deleted them from your HD, you should stop using the HD containing the files immediately.
You would have to plug your HD out and 1) back it up, then 2) try to recover any deleted files concerning your wallet (do you remember which you were using? Bitcoin Core?).

1) The best would be to use linux on a portable device you boot from, afterwards copying your whole HD (e.g. with https://wiki.ubuntuusers.de/dd/) and only work on the copy!
2) Preferably a write blocker (software wb: http://www.forensicswiki.org/wiki/Write_Blockers#Software_Write_Blockers together with any forensic tool (e.g. FTK: https://accessdata.com/products-services/forensic-toolkit-ftk)
Downloadable here: https://accessdata.com/product-download/ftk-download-page/

I was talking about the maximum amount possible.
I took a look and you are right it got changed to a maximum weight of 400.000 [1].
Since non-segwit transaction have a weight of 4*tx_size my calculation still should be correct.

[1] Defined as constant here: https://github.com/bitcoin/bitcoin/blob/3c098a8aa0780009c11b66b1a5d488a928629ebf/src/policy/policy.h#L24
[1] and checked/used here: https://github.com/bitcoin/bitcoin/blob/3c098a8aa0780009c11b66b1a5d488a928629ebf/src/net_processing.cpp#L661-L665

The ledger bitcoin wallet app checks your recieving addresses 1 by 1.
The application basically increases a counter (which is used to derive the addresses) until a newly generated address doesn't contain any balance.
This isn't a problem at all. If the nano s is being used with their chrome app there is no reason to increase the number of checked addresses.
And if the nano s is used with electrum then its not a problem either as long as you still use electrum.
Your coins are never lost. They are recoverable with the seed, regardless of which application/address is used for storing the coins.

The 51% attack is regarded as successfull if you can compromise/gain control over 51% of the networks computation power (here: hash rate).
So your 1.000.000 virtual machines would be useless until they had hosting machines which would raise those 51% of the total hash rate (in this case 1 host theoretically would be enough.
Currently the hashrate is at about 8,481,426,000 GH/s (Source: https://bitcoinwisdom.com/bitcoin/difficulty).

Your electrum application is not compromised.
This is a 'bug' in an older version of the nano s firmware. It asks to confirm the change output additionally to the first output.
You can get rid of this with updating your nano s.

• Current Secure element version: 1.3.1
• Bitcoin chrome app: 1.9.12

Make sure to have a backup of your 24 word seed phrase available in case of the need of reentering your phrase.

You can use the btcrecover tool: https://github.com/gurnec/btcrecover/.
Or to be more precise the seedrecovery.py: https://github.com/gurnec/btcrecover/blob/master/docs/Seedrecover_Quick_Start_Guide.md

This tool checks your seed for mistakes and tries to replace the wrong word.
The safest would be if you read yourself into installing/setting up the seedrecovery tool.
If you aren't able to set it up properly you should try to find a reputable(!) and honest person on this forum to do this for you for a small fee.

The isStandard() test supports transactions up to 100kb i believe.

Assuming a P2SH/P2PKH transaction is being created, the size (in byte) of a TX with one input and y outputs would be:

For a maximum of 100 kb you could therefore create a (valid) transaction with 3025 outputs.
Correct me if i am wrong, but i didn't found any rule which would lead to such a transaction being non-standard.

Your transaction got confirmed about 2-3 minutes after broadcasting. It went through as it should.
https://blockchain.info/tx/45040b8ad51b86e8cf5d79018c17b6dd9c1924d2cb2f36dab99ed4dc11586a13

The only one able to help you is the support of cex.io. You can contact them here: https://support.cex.io/hc/en-us
Next time you could just look your transaction up in a block explorer before posting.

Beside of its 'user friendly' UI there isn't an advantage.
Openssl is perfectly fine for that.

To encrypt it with AES for example:
You will be prompted to enter a password.

If you chose to use an encryption with a private key instead of a password you should check if your entropy pool is 'filled enough'.
On linux:
If the number shown is bigger than 300-400 then your result will be 'random enough'.

Afterwards you could create your RSA private key with:
and your public key with:

Then to encrypt your file:
and to decrypt afterwards:

Key encryption gives you a higher grade of security regarding brute force / social engineering attacks.
Just make sure to keep your key at a safe place, with different backups.
But if you just want to encrypt it with a password thats not too risky either as long as the password is random enough.

There is only 1 way to generate an address out of a public key: address = ripemd160(sha256(public_key)))
The public key (composed of: prefix, x-coordinate, y-coordinate) can be either compressed or uncompressed.
Which doesn't matter in this case because the second multiplier (y) can be derived from the first multiplier and the prefix.

The problem is most likely the wrong derivation path used while trying to recover the correct keys.
m/44'/0'/0' should be the right path for JAXX wallets to restore. Depending on the client you use to generate your keys m/44H/0H/0H may be another accepted format.