Lazy API

From Bitcoin Wiki
Revision as of 03:15, 1 October 2011 by Sgornick (talk | contribs) (Add See Also section and add entries for BitAddress and BitcoinNotify.)
Jump to navigation Jump to search

For the incredibly lazy and/or incompetent web developer, present is the lazy man's bitcoin API (copied from a forum post):

Problem

Lazy web designer wants to use bitcoins without dealing with installing bitcoin on a server, installing a shopping cart interface, or using ugly merchant services with callbacks.

Solution for sending bitcoins

Use the MtGox API

Solution for receiving bitcoins

  1. Input a list of bitcoin receiving addresses to your database
  2. Give a bitcoin address to a potential customer
  3. Have the customer tell you when they have sent the coins and have at least 1 confirmation (you can choose a number higher than 1 if you are worried about double-spending)
  4. Check blockexplorer to see if they sent the right amount (i.e. http://blockexplorer.com/q/getreceivedbyaddress/19hMEAaRMbEhfSkeU4GT8mgSuyR4t4M6TH/1) - the /1 is the number of confirmations you require
  5. Give them what they paid for
  6. After a reasonable amount of time has passed, you can re-use the address for another customer

You could avoid having a list of addresses and reusing them if one of the wallet services someday lets you get a new address via API call, but this will work for now.

Risks

External Service

BlockExplorer is a service that is provided by a private party. There is no guarantee that the information provided by BlockExplorer matches the blockchain.

There have not been any reports that BlockExplorer has reported transaction data incorrectly.

Double Spending

A merchant is exposed to a double spending attack when recognizing a payment before it has been confirmed with a sufficient number of blocks.

For an attacker to be successful with this double spend tactic a significant effort is required and thus the risk of this attack being made against the typical retail merchant is pretty minimal. It would not be advisable for a merchant with little to no recourse against an attacker to accept payment without a sufficient number of confirmations however.

See Also