|
June 29, 2014, 03:04:21 PM |
|
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.
|