How do I develop web applications for Bitcoin?

Question

Although similar to this question about mobile app development, I would like to know how I should go about the development of web applications that make use of Bitcoin. It can be assumed that all the standard recommendations mentioned in this famous question will have been noted and implemented where applicable.

This question is about Bitcoin specific design requirements that experienced developers would like to hand down to those just starting out.

Edit to clarify further

I'm looking for design requirements that a web application using the Bitcoin protocol in some way would be advised to apply before releasing their code to the public. For example

• additional security arrangements (offline elements? manual interventions?)
• network connectivity concerns (what is an appropriate uptime expectation? does Bitcoin introduce greater bandwidth consumption than standard web technologies?)
• recommended deployment configurations (distributed via EC2+EBS+S3? personally managed servers? and so on)
• data privacy concerns (Know Your Customer?)

There have been many issues with Bitcoin web applications suffering from design issues that should have been avoided. Hopefully, the answers to this question will help other developers working on these projects to not repeat them.

Answer 1

Some tips:

1) Don't keep the full amount in the wallet on the server (have it on a server that's offline, think of it as an active reserve)

2)Have the actuall bitcoind software and wallet on a different machine from which the webapp is

An alternative to running bitcoind (and dealing with all it's issues) is to use a web wallet with an API, GLBSE (GLBSE.com, note I'm the founder) has a python client for interacting with it.

3)Require at least 8 confirmations before crediting someones bitcoin account.

Answer 2

All points by Nefario are spot-on. In addition to these, here are some Bitcoin-specific suggestions from Camp BX's experience so far:

1) Use testnet. Testnet is an excellent resource, that unfortunately does not see as much use as it should outside the core development team. Make sure you launch your project on testnet, and test all major subsequent releases there as well.

2) Bounties are overrated.
If you want to find bugs in your Bitcoin project, do not rely on bounties. Perform L&P testing, Unit testing, System testing on all your code and hire professional security auditors if possible.

3) Use 64-bit architecture (This may not apply to all projects.) Many developers use an old 32-bit server for testing and 64-bit system as production server. It is worth the extra investment to make sure your test server is 64-bit architecture as well.

Hope this helps.

Answer 3

Depending on what your web application does you might want to consider keeping the private keys off the server entirely. For MultiBitMerchant we have gone with an architecture that keeps the private keys on an unrelated machine and only uploads the Bitcoin addresses.

You can verify BTC received and generate payment requests with just the Bitcoin addresses - it all depends on if you want to do bitcoin spends on the server. If you have a deterministic private key structure you can sign your transactions in the browser and use the server to broadcast the transaction.

This appears to be a popular approach eg BCCAPI, blockchain.info.

If the server never knows the private keys it makes it much less attractive as a target.

Answer 4

Consider the Stratum Overlay Network (work in progress) to simplify server code - it allows you to transact securely without managing a blockchain.