Topic: Questions about implementing "Bitcoin accepted here" (Read 916 times)
Yeah, you could detect unconfirmed transactions later and treat them as chargebacks. Or use something like zipconf maybe? Plus, there are shopping cart interfaces that let you convert payments to USD on-the-fly, like bit-pay. For instance, although I haven't tried this myself, ZipConf to MtGox should be analogous to an instant credit card payment, without the risk of chargeback. You could also consider converting only a portion of the payment to USD and keep the profits as BTC.
What do you do if someone pays with traditional money and charges back?
The chance that you get double spent on is incredibly close to zero, maybe not quite chipmunks discovered on the moon zero, but close.
Some companies are taking some risk in accepting zero confirms, but domain registration is not one of them. I bought a domain today with bitcoin and it was instant.
The chance that you get double spent on is incredibly close to zero, maybe not quite chipmunks discovered on the moon zero, but close.
Some companies are taking some risk in accepting zero confirms, but domain registration is not one of them. I bought a domain today with bitcoin and it was instant.
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.).
- Why isn't http://satoshidice.com/ victim to double spending attacks?
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.
I'm hoping to implement bitcoin payments for the small Internet hosting company I work for.
Since I'll need to start with low-valued purchases (there is some scepticism from my colleagues!), probably the first item we'll accept bitcoin for will be domain registrations. Unfortunately, these have features that make them among the hardest to implement:
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.
Thanks for any input.
Toby.
Since I'll need to start with low-valued purchases (there is some scepticism from my colleagues!), probably the first item we'll accept bitcoin for will be domain registrations. Unfortunately, these have features that make them among the hardest to implement:
- registration is completely automatic;
- the moment a domain is registered, it costs us real money with our upstream registrar;
- ideally, we want to accept domain orders from anyone, not just established customers.
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?
- I'm thinking at the moment I'll use the BitPing code to build my own notifier. Is that a good route to go?
- 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.
- Why isn't http://satoshidice.com/ victim to double spending attacks?
Thanks for any input.
Toby.
Jump to: