Lazy API: Difference between revisions
m →Double Spending: Readability. |
removing explicit address mention |
||
| (24 intermediate revisions by 12 users not shown) | |||
| Line 1: | Line 1: | ||
For the incredibly lazy and/or incompetent web developer, present is the lazy man's bitcoin API (copied from [ | For the incredibly lazy and/or incompetent web developer, present is the lazy man's bitcoin API (copied from [https://bitcointalk.org/index.php?topic=4324.msg77187#msg77187 a forum post]): | ||
==Problem== | ==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. | 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== | ==Solution for receiving bitcoins== | ||
| Line 13: | 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== | ||
| Line 29: | Line 22: | ||
===Double Spending=== | ===Double Spending=== | ||
A merchant is exposed to a double spending attack when recognizing a payment before it has been [[confirmation|confirmed]] with a sufficient number of blocks. | A merchant is exposed to a [[double-spending]] attack when recognizing a payment before it has been [[confirmation|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. | 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. | |||
[[de:API_für_Faule]] | |||
[[Category:Developer]] | [[Category:Developer]] | ||
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.