Would anyone be kind enough to spare 5 minutes to explain how to set up remotely

[bitcoins_vendor]

My problem is i had both bitcoind and website both on my local linux (ubuntu) server while i was developing and all worked great, but now i have just moved my site to my hosting account with all my other sites on a shared godaddy server but bitcoind is odiously still on my local server (where i want it to be) but i can not get it to work, i have a dedicated ip address for the domain and i have a static ip address at home. i will be honest here and say im relatively new to linux but since leaving windows i have not looked back, but one thing ive not had any experience with is ssh and i want to be sure the connection between the servers is secure so you might think im being dense but i would rather ask here where people know for sure how to do this, i spent an hour on the phone to godaddy last night and i had to explain what bitcoins are if you can believe that someone how is highly involved in this industry didnt know. so if you can explain how i should set this up you would be really helping, this is only a test project to prove the non believers its possible and until now ive not had any problems. thank you for your time but i need to be sure, im sure you understand why i need to ask.

server at godaddy has dedicated ip and home has static, the live url is http://theheadshop.org.uk if you want to look, use buyer for username and 123123 for password.

oh and also have ssl cert as recommended.

[1714893807]

1714893807

[1714893807]

1714893807

[Rannasha]

Assuming the requirements of a simple webshop (you can probably expand on this concept for more advanced features).

What you need is:
- Bitcoin addresses for payments.
- Coupling an address to a customer / invoice.
- Tracking payments to an address and flagging the invoice as paid.

An example approach would be to use 2 servers, like you have. A website server and a Bitcoin server. The Bitcoin server generates addresses in large quantities, say a few thousand, and sends the public address to the website. The website could simply implement a script that lets the Bitcoin server submit new addresses, for example: example.com/submitaddress.php?address=1BTCblablabla. Obviously this approach needs to be enhanced with some form of authentication to prevent unauthorized users from accessing it. Instead of submitting single addresses, the script could accept a file with a bunch of them.

Anyway, after this, the website has a set of unused addresses (to which the Bitcoin server has the private keys) and stores them in a DB. When a customer makes a purchase, the website selects one of the unused addresses, shows it to the user, flags it as used and stores the link between customer/invoice/address in the database. Meanwhile, the Bitcoin server monitors all its addresses and reports payments to the website through example.com/paymentreceived.php?address=1BTCblablabla&amount=1.234 (again: authentication needs to be added!).

In this setup, the website doesn't need to know where the Bitcoin server is, as long as the Bitcoin server has the correct authentication it can submit new addresses and report payments to the website (its IP address will still appear in access logs on the website-server though). Certain functions such as supplying new addresses can be done with a cron job, first firing a request to ask how many unused addresses the website has left and the supplying a new batch based on the response.

Authentication is essential in this scheme, otherwise an attacker may be able to inject his own addresses or confirm payments that have never occurred. A simple authentication scheme is to use asymmetric cryptography (just like Bitcoin uses) and to have the Bitcoin-server sign all its requests with a private key, after which the website can easily establish its authenticity by using the associated public key (or public address if you just use Bitcoin features). In this setup, the Bitcoin-server never has to accept an incoming connection, as it is the initiator of all message-passing. This means that you can make the firewall very strict and drop any incoming connections to the Bitcoin server (except perhaps SSH from local LAN if you have no direct keyboard-access).

Obviously the above is just an example setup, there are variations. But it should put you in a decent frame of mind when it comes to thinking about these things.

[Justin00]

which part isn't working ?
I briefly read your OP, then read again, little confused which the bit that isnt working ?
bitcoind/rpc ??

I'm fairly familiar with linux from my sys admin days....  I can help you, for free if you need someone to ssh in and check it out.