Simple Merchant Payment Processing w/o a 3rd Party

[judah]

[Request for Comment]

A generalized and extendable merchant payments system utilizing hierarchical deterministic keys (BIP 32).  

Needs addressed:

• Role-your-own payment systems are often narrowly focused, too technical for typical merchants and/or potentially insecure.
• Consolidation of Merchant Payments via Trusted Third Parties, while extremely valuable at this juncture, runs counter to Bitcoin's Ideals of decentralization and psuedo-anonymity.  TTPs can analyze and store customer IP addresses, associating them with bitcoin addresses, frequency and quantity of purchases.  If a TTP experiences downtime or regulatory pressure, Bitcoin commerce can suffer.

Proposed Solution:
1. A core set of end-use agnostic merchant tools
2. Bridges to specific merchant environments developed and shared as needed.
   With a stable core back-end providing key management and bitcoin network communication, bridge work can focus directly on meeting merchant needs.
   A bounty system can be used to develop special-use bridges.
   Examples: a REST bridge for Android or a Megento bridge with automatic fiat-to-btc conversion.

Core functionality (draft, requesting feedback)

• Public-Key-Only unique address generation upon request using BIP 32.
• Watch-only support for generated addresses using SPV (not 3rd party but also not full-node)
• Callback interface extendable to specific use cases
• Persistence of received payments for reporting
• Configuration

Simplest walkthrough:
a) Core configured with master public extended key and datastore.
b) request for payment of 1btc received (with attached callback)
c) created address returned, SPV watch set on address
d) Zero-conf payment received, callback and datastore notified
   - confirmations subsequently received, callback and datastore notified
e) or, configured timeout time reached, watched address dropped, callback canceled.
f) --later-- audit report requested for all payments received (i.e., over a given timeframe).

Why isn't this already developed? If it is, why haven't I heard of it?

Similar Projects (please supply more):
   acceptbit.com: Uses BIP 32, Http interface, uses blockchain.info for notifications, *can be hosted locally.
   BitcoinSCI (Shopping Cart Interface):  Uses BIP 32, PHP/MySQL implementation, uses blockexplorer.com for watch wallet. BitShop  Web Store package uses BitcoinSCI
   MultiBit Merchant:  In development, full Web Store/multi-use implementation.
   Shopping cart interfaces list at Bitcoin Wiki.

project website: bitcashier.org
related Reddit thread
edit: formatting, this is my first bitcointalk post, please be gentle.

[judah]

General Module Diagram

https://i.imgur.com/RgNHhaP.png

Bridge and Persistence modules can chosen to best match the Merchant's needs and desires.

[jedunnigan]

d) Zero-conf payment received, callback and datastore notified

me again.

To minimize the probability of a double spend attack I recommend you increase the default number of node connections to around 100. This will be implemented in the protocol somewhere down the line (hopefully soon) but regardless it is something to think about.

0 confs are tricky be careful with those.

source: http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf

[judah]

0 confs are tricky be careful with those.

Yes certainly, especially with sales of digital media.

zero-conf would primarily be used to notify the customer that their broadcast has been received.
Merchant business logic should actually place the order on 4, 5, 6, confirmations or whichever is necessary.

Point-of-sale (i.e., a restaurant) is an interesting case because the double-spender would physically be present while another agent would be elsewhere trying to double spend within the same block, correct?

[jedunnigan]

0 confs are tricky be careful with those.

Yes certainly, especially with sales of digital media.

zero-conf would primarily be used to notify the customer that their broadcast has been received.
Merchant business logic should actually place the order on 4, 5, 6, confirmations or whichever is necessary.

Point-of-sale (i.e., a restaurant) is an interesting case because the double-spender would physically be present while another agent would be elsewhere trying to double spend within the same block, correct?

A double spend occurs when an attacker broadcasts two txs at once spending the same coin, one to the receiving party and the other to themselves. There is a ~75% chance that the first tx seen by the network will be accepted. There is a 50/50 chance that either one will be seen first, so a double spend has ~32.5% probability of occurring right now. It can be lowered pretty significantly with a few minor changes to the merchant's client software. You can read about it here (disclaimer, I wrote the summary): http://btcgsa.info/?p=284

You should read about the return chaining as well, because giving change is definitely a feature you will need.