Contact us for help with web develpment. We are developing several web about cryptos in English and Spanish.
Web samples:
https://dereformasmadrid.com
https://dereformasvalencia.com
https://dereformasmallorca.com
https://dereformasbarcelona.com
https://dereformasmalaga.com
https://dereformaszaragoza.com
Topic: Address generation for web services (Read 887 times)
It's fine to run a wallet on your web server or a nearby sergver, so long as the server itself is reasonably secured and you set rpcallowip in bitcoin.conf. One thing you might want to do is to sweep received payments off to another wallet which is located on another server, or offline.
As we build some bitcoin based web services I'm curious to get some input on the best way to generate payment addresses securely for a web service.
For obvious reasons I will not keep a wallet on the web servers, for receiving payments it's hardly necessary. However, assuming a successful web service we will need to generate new payment addresses for at least every customer if not every transaction. (The database will record the intent to pay, the block chain will show the payment is received).
Should I procedurally generate a million keys from the client using our secure wallet machine, and put them in an address cache in the DB?
Is there another way to generate valid key pairs with tools like GNUPG/PGP?
Maybe I should just cycle through a smaller set of addresses, that have time limits on payment? (i.e. pay this address in the next 24 hours, a la mtgox)
Do I need to run the client on the web server, or are there server side tools for evaluating the block chain?
Any other ideas or issues?
Now what about the reverse? If we create a sight that involves paying people out in bitcoins. What's the most secure way to process these transactions?
Thanks in advance for your input.
MrJ
For obvious reasons I will not keep a wallet on the web servers, for receiving payments it's hardly necessary. However, assuming a successful web service we will need to generate new payment addresses for at least every customer if not every transaction. (The database will record the intent to pay, the block chain will show the payment is received).
Should I procedurally generate a million keys from the client using our secure wallet machine, and put them in an address cache in the DB?
Is there another way to generate valid key pairs with tools like GNUPG/PGP?
Maybe I should just cycle through a smaller set of addresses, that have time limits on payment? (i.e. pay this address in the next 24 hours, a la mtgox)
Do I need to run the client on the web server, or are there server side tools for evaluating the block chain?
Any other ideas or issues?
Now what about the reverse? If we create a sight that involves paying people out in bitcoins. What's the most secure way to process these transactions?
Thanks in advance for your input.
MrJ
Jump to: