Lazy API: Difference between revisions
removing spam |
removing explicit address mention |
||
| Line 9: | Line 9: | ||
# Give a bitcoin address to a potential customer | # Give a bitcoin address to a potential customer | ||
# 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) | # 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) | ||
# Check blockexplorer to see if they sent the right amount | # Check blockexplorer to see if they sent the right amount | ||
# Give them what they paid for | # Give them what they paid for | ||
==Risks== | ==Risks== | ||
Latest revision as of 16:23, 3 July 2017
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 receiving bitcoins
- Input a list of bitcoin receiving addresses to your database
- Give a bitcoin address to a potential customer
- 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)
- Check blockexplorer to see if they sent the right amount
- Give them what they paid for
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.
Note that this attack can be performed no matter which API or client is being used.