Bitcoin Forum
April 23, 2024, 02:21:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Questions about implementing "Bitcoin accepted here"  (Read 889 times)
TobyGoodwin (OP)
Newbie
*
Offline Offline

Activity: 31
Merit: 0



View Profile WWW
May 27, 2012, 09:34:59 PM
 #1

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:
  • 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.
1713882089
Hero Member
*
Offline Offline

Posts: 1713882089

View Profile Personal Message (Offline)

Ignore
1713882089
Reply with quote  #2

1713882089
Report to moderator
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1010


View Profile
May 27, 2012, 11:47:37 PM
Last edit: May 30, 2012, 03:07:59 AM by Stephen Gornick
 #2

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.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


FreeMoney
Legendary
*
Offline Offline

Activity: 1246
Merit: 1014


Strength in numbers


View Profile WWW
May 30, 2012, 01:43:05 AM
 #3

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.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
memvola
Hero Member
*****
Offline Offline

Activity: 938
Merit: 1002


View Profile
May 30, 2012, 02:01:33 AM
 #4

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.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!