Ideas are everywhere. Are you still in school or do you have a job? Your social and professional circles are a great way to generate ideas. When you think of an idea, write it down immediately. I write all my new ideas down into a single text file. I call it my "sparks" file. The reason I do this is to not distract myself from whatever project(s) I am currently working on. I can always look back at my sparks file and re-read all of my previous ideas. If you look at an idea you had 6 months ago and you still think it's a great idea, then it's probably worth pursuing.

I don't have any more ideas. Sorry I couldn't help you fix your problem

Best of luck!

That's not much to go on. What kind of debugging tools are available for you with the miner? Does it have a screen? Can you access it via SSH from your computer? What operating system is it running?

--- EDIT ---

Also, just a shot in the dark.. Is there a testnet option that you might have to set in the miner's configuration? It might be necessary to explicitly set such a flag, beyond setting the RPC port to 18332.

Try leaving out the rpcallowip directive anyways. What have you done to be sure that the miner is not able to connect via RPC?

I would suggest not using the rpcallowip at all. Here's how I currently have a bitcoind setup with remote RPC access:

* Add firewall settings to the bitcoind server that allow 127.0.0.1 to access the RPC port (18332 for testnet, 8332 for mainnet).
* Create a new linux user on the bitcoind server for the sole purpose of providing port forwarding via SSH for the RPC port.
* Setup SSH tunnel access from the machine(s) that require remote RPC access to the bitcoind server. The SSH tunnel should use the new linux user for the SSH session. I like to use public/private RSA keys to setup passwordless SSH between machines. Lastly, for security, when you are adding a public key to the list of authorized keys for the new linux user, you'll want to prevent command execution and restrict port forwarding to only the required RPC port.

Here's a snippet that let's you lock down an SSH session in the manner I just described:

This setup allows remote RPC access via an SSH tunnel without having to expose bitcoind ports to the net (only to the local machine).

If you have never setup passwordless SSH before, I wrote an article a while back that I posted on my site:
https://degreesofzero.com/article/passwordless-ssh-on-linux.html


-------- EDIT --------

You know it just occurs to me. You're referencing port 18333 everywhere. That's not the testnet RPC port. Port 18332 is the testnet RPC port that you should be attempting to connect to when using RPC.

You can't access the RPC port you mean? Or bitcoind is failing to establish any connections and is failing to download any blocks as a result? Is there anything interesting in the debug.log file? This file should be located in the testnet3 directory.

Correct me if I am wrong, but wouldn't the above command filter out any result that did *not* include 833? What results do you get when you try the following?

So I finally got things working on an Ubuntu 14.04 server. Here's what the final, working /etc/init/bitcoind.conf looks like:


Once you've added/updated your /etc/init/bitcoin.conf file, be sure to run the following:


Basically this was just a lot of guess and check to make this finally work. Here's the important bit:


Essentially, this is telling upstart how many times the target process will be forked while starting. If you tell it wrong, it'll hang while starting. Read here for the specifics on this.

You should be able to manually start bitcoind as a service, like this:


Or stop it, like this:


If you restart your server, the bitcoind service should be started automatically. And, if the bitcoind process is killed or crashes, it will be automatically respawned. You can test that part out on your server by first finding the PID of the bitcoind process:


Then, kill the process manually:


Then, try to get the PID of the bitcoind process again:


It should still be running and with a new PID.