So I'm thinking that the customer interface will need to generate a
pending order; we'll hang onto this till we have received sufficient confirmations of the payment, then execute it. A few questions.
- Does this sound about right? Are there any other / better ways to do it?
You could use an external service with an API.
Bit-Pay, Mt. Gox and Paysius are three, among many.
-
http://en.bitcoin.it/wiki/Category:Shopping_Cart_Interfaces -
http://en.bitcoin.it/wiki/Bit-pay -
http://en.bitcoin.it/wiki/MtGox#E-Commerce- How many confirmations is enough? The number 6 is buried in the folk memory, but that comes from the assumption that an attacker might achieve 10% of the processing power of the honest chain, which seems vanishingly unlikely in this day and age. I'm inclined to plump for 2, which still gives only a 5% chance of fraud under that assumption, and about 0.05% chance of fraud if the attacker achieves 1% processing power.
Six is recommended. Some merchants accept after 3. It's unlikely you'll see a loss after accepting on just 1 confirmation even (presuming you aren't configured to accept incoming transactions).
Essentially, the rule of thumb is don't accept anything of high value below 6 confirmation unless you have recourse (e.g., can cancel the domain, or have customer's credit card on file, and can collect that way, etc.).
Their "delivered" item is a payment that includes the payment of the wager. If the payment from the wager never confirms then the payout (winnings or losing) will never confirm as well. They are at risk of a party double spending just the losing wagers and leaving intact the winning wagers. Not sure how they accommodate that risk.