Lazy API: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
WalletBit (talk | contribs)
No edit summary
removing explicit address mention
 
(11 intermediate revisions by 7 users not shown)
Line 4: Line 4:


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 sending bitcoins==
Use the [https://mtgox.com/support/tradeAPI MtGox API] which allows you to use the offchain payment network.


==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 (i.e. http://blockexplorer.com/q/getreceivedbyaddress/19hMEAaRMbEhfSkeU4GT8mgSuyR4t4M6TH/1) - the /1 is the number of confirmations you require
# Check blockexplorer to see if they sent the right amount
# Give them what they paid for
# Give them what they paid for
# After a reasonable amount of time has passed, you can re-use the address for another customer


==Risks==
==Risks==
Line 32: Line 26:
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.


==See Also==
Note that this attack can be performed no matter which API or client is being used.
 
* [[BitAddress]] Generate address and private key pairs for an offline wallet
* [[BitcoinNotify]] Register addresses and receive email or SMS alerts when a payment to that address occurs


[[de:API_für_Faule]]
[[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

  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
  5. 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.