There seems to be an exploit where you can send it more data than it is expecting and thus write into memory that you shouldn't thus allowing for a remote code execution exploit.

Edit: That is actually not exploitable. However bitmain supposedly has a way to reflash firmware remotely: https://www.reddit.com/r/Bitcoin/comments/67qwqv/antbleed_exposing_the_malicious_backdoor_on/dgsk6cf/

Read http://www.antbleed.com/ for more info

The shutdown backdoor has been independently tested by multiple people.

Edit:

I have analyzed the code and I have determined how this is happening and most likely why it was put there.
First, let's start with the how. The firmware will spawn a thread which calls the send_mac function which, as the name implies, sends data about the machine to the AUTH_URL auth.minerlink.com. The device then will attempt to receive data from the server and check if the response is false. If it is, the function returns true which sets the stop_mining global variable to be true.

When that variable is true, in the temperature checking thread, it will set the status_error global variable to true. That will then tell the work update function to not send out jobs so it is no longer mining.

---

Now for the why.

Bitmain previously was going to launch a service called Minerlink. This service never launched, but it was intended get the "real-time miner status remotely". There is probably a feature that allows you to make sure that the only miners submitting work for you are your miners, hence the need for an auth url. It is also possible that another feature was to allow you to remotely stop a machine from mining if it were misbehaving. This would explain why this code was put there in the first place. However, since minerlink does not exist, this functionality is now a liability and should have been removed long ago.

Use the JSON-RPC interface. You can write some php code that will send a POST request to the bitcoind to get the information that you need.

Ah, I missed that.

That is the problem. I just checked with my node. The transaction has been dropped from my node, so it has likely been dropped from most nodes on the network (block explorers being the exception). You will need to first broadcast the unconfirmed transaction which you are spending from and then broadcast your spending transaction.

Besides that, it looks like you are using the wrong public key as it does not match the hash specified in the output script you are spending from. You are probably using the wrong private key.

Use a different exchange. Since you have no control over how the transaction is made, there is nothing you can do.

The transaction fee on all of your transactions is too low. It pays a fee of 100 sat/byte whereas the current recommended fee is 200 sat/byte according to https://bitcoinfees.21.co/.

Read https://bitcointalk.org/index.php?topic=1802212.0 for what you can do about the transactions. Unfortunately, because you are using exchange wallets, there is not much you can do besides waiting.

The "missing inputs" error has nothing to do with input scripts. The problem is because you have the wrong txid. For some reason, the tx_hash given by blockchain.info is in little endian but basically everything takes the txid as a big endian argument. You should use "tx_hash_big_endian":"c54ffd2b302b03f81342fe0c2c42960dd160d6b1ad8db7d3539f83a1ca8cb5d5", for the txid of the transaction that you are spending from.

It does not matter what address you use, they will all be tracked for payments. There is nothing you need to to do to "save" an address. All addresses after being generated are tracked forever. Addresses are never deleted nor is there anything that prevents you from using one multiple times.

There are libraries (e.g. python-bitcoinlib) that do this stuff for you so you could use those instead of figuring out the calculation yourself.

Bitcoin Core is running out of memory since you only have 4 GB of RAM. Try upgrading to Bitcoin Core 0.14.1 which has reduced the memory usage in order to run on lower RAM systems.

What version of Armory and Bitcoin Core are you using?

Can you please post the log files?

Is Armory fully synced? In the bottom right hand corner it says how many blocks it has synced. Check that that number matches what Bitcoin Core says and what a block explorer says.

Please provide armorylog.txt and dbLog.txt.

What version of Bitcoin Core are you using? Have you removed the databases (moved, renamed, or deleted) in the Armory datadir when you upgraded? Are you running Bitcoin Core manually or letting Armory run it?

0.95.1 has many benefits over 0.93.3, including a much much smaller database (a few MB vs. several GB), faster loading time, and segwit compatibility.

Who are "they"? What service are you trying to get verified for?

Regardless of whoever it is, users here cannot help you. All you can do is wait for the service to process everything and contact their support.

Since you used walletgenerator.net to create the private key, you can also use it to decrypt the private key. In the wallet details tab, if you enter a BIP38 encrypted key in the "Private key" box, another box will appear for your password so you can get the decrypted private key to import into your wallet.

The merkle tree consists of all of the transactions in the block. The merkle root is only one part of the block header though. There is a version number, the previous block hash, the time stamp, the bits (target), and the nonce in addition to the merkle root which forms the block header. All of those things are then hashed to get the block hash. The merkle root itself is not the block hash.

You will need a wallet that supports importing BIP38 encrypted private keys. When you import, you will be prompted for your password by the wallet software so that it can decrypt the key.

Both chains? I don't think there would be a chain split. In the case of just a merkle root collision (i.e. block hashes are different due to timestamp or nonce) the blocks with the collided merkle root are just two valid blocks and you just have the normal orphan race.

If you are talking about two block hashes colliding, that's an entirely different and more complex matter.

The hack was in May 2015. OP's account was registered in Nov 2015. His account being hacked is due to something else.

The only way to make sure that your Bitcoin has the benefits provided by an HD wallet is to send the Bitcoin from your old wallet to your new wallet. Importing the private keys will not be any more useful.

First make sure that Bitcoin Core is shut down. Then make a backup of your wallet.dat file. Move or rename the wallet.dat file so that there is no longer a file named wallet.dat in the Bitcoin Core data directory. Start Bitcoin Core and it will generate a new HD wallet and a corresponding wallet.dat file. Get as many addresses as you need and copy them somewhere. Then stop Bitcoin Core and make a backup of the new wallet.dat file. Move or rename it so that there is no longer a file named wallet.dat in the datadir. Then move or rename your original wallet file back to wallet.dat in the datadir. Start Bitcoin Core again. Send Bitcoin to the addresses that you copied down. Then stop Bitcoin Core, and replace the wallet.dat with the new wallet.dat that was created.

The PRNG still produces a random number that is based upon transforming the entropy. Your private key is still a random number.