My Bitcoin experience after a few thousand transaction

[FrankDizapo]

In this post I will shortly detail my experience in dealing with Bitcoin transactions for a website. Maybe this well help other people starting out.

Background
I work for a company that sells online storage space. Users can get a free upload account with 50 GB and buy extra storage space using PayPal or Bitcoin. My task was to create a system where users would be able to buy extra storage space for Bitcoins and also sell their files and earn 95% of the profit. These are the pros and cons we experienced when working with Bitcoin.

Pros

• Implementation is easy, the bitcoin daemon is reachable with RPC which is very easy to implement in PHP.
• No third party involvement. Unlike PayPal a transaction cannot be undone by a third party, so we do refunds manually.
• Generating unique addresses is very quick, we auto generate new accounts and addresses on the fly, generate a QR code in Javascript and people can pay within seconds.
• The Bitcoin daemon is stable but a bit CPU and memory intensive compared to other daemons on the system.

Cons

• Confirmations can literally take hours. Doing a transaction often takes minutes or even hours to get confirmed. We currently wait a few seconds before accepting a payment but cannot afford to wait for confirmations. (and thus have a less secure payment system than we'd like).
• Transaction fees are relatively high for micro transactions. For example, when people sell their art pictures for 20 eurocents/2 mbtc each, the transaction fees increase the price by roughly 25%. This is hurting the really small transactions, we hope the network will reduce transaction fees to 0.1 mBTC or even less in the future.

Other considerations

• Recurring payments are not possible, might be a problem depending on your niche.
• We have a few thousand accounts and a few thousand addresses. Bitcoind queries are still very fast but we couldn't find any reliable metrics on queries against super large wallets with millions of addresses.

Conlcusion
We are very happy with Bitcoin as a payment option. Implementation is simple, easier and cheaper than PayPal and payment is virtually anonymous. However, we do risk double spending to reduce user annoyance and micro transactions are still not very cheap with Bitcoin. We consider these issues small compared to the benefits!

[1715296820]

1715296820

[1715296820]

1715296820

[1715296820]

1715296820

[1715296820]

1715296820

[jedimental]

Confirmation speed could be the death of bitcoin being a widely accepted means of exchange. Services like Bitpay, on the other hand, from what I gather is a service that makes this easy for a business to accept bitcoin even if they are not bitcoin savvy.

I agree totally about the overly exuberant price of today's transaction fee.

[DannyHamilton]

• Confirmations can literally take hours. Doing a transaction often takes minutes or even hours to get confirmed. We currently wait a few seconds before accepting a payment but cannot afford to wait for confirmations. (and thus have a less secure payment system than we'd like).

I'm curious.  Given the "less secure payment system than you'd like", what percent of the bitcoin transactions you've received have been reversed via a "double-spend" attack so far?

If a payment is reversed via a "double-spend" attack, does it get noticed?  Do you then block the user from accessing the storage space?  If a user sells a file, and the bitcoin payment is reversed with a "double-spend" attack, do you still pay the seller their 95% of the expected revenue, or does the seller take on all the risk?

• . . . we hope the network will reduce transaction fees to 0.1 mBTC or even less in the future.

I believe this is already implemented in the next version of Bitcoin-Qt.

[Akka]

The standart transaction fees are actually reduced to the 0.0001 BTC in the new Version of the QT Client. Which is in RC right now, so it will probably come out soon.

For the rest of your cons I agree and I hope that it will become saver in the future to accept 0 confirmation transactions, but actually it is not very risky yet, compared to cargeback risks of other systems.

In the few thousand transactions, where there a single double spend?

Thanks for sharing.

[htcking]

Interesting

[yigh]

The standart transaction fees are actually reduced to the 0.0001 BTC in the new Version of the QT Client. Which is in RC right now, so it will probably come out soon.

 

[malevolent]

• The Bitcoin daemon is stable but a bit CPU and memory intensive compared to other daemons on the system.

Can you make it work on only 1 cpu core?

Cons

• Confirmations can literally take hours. Doing a transaction often takes minutes or even hours to get confirmed. We currently wait a few seconds before accepting a payment but cannot afford to wait for confirmations. (and thus have a less secure payment system than we'd like).
• Transaction fees are relatively high for micro transactions. For example, when people sell their art pictures for 20 eurocents/2 mbtc each, the transaction fees increase the price by roughly 25%. This is hurting the really small transactions, we hope the network will reduce transaction fees to 0.1 mBTC or even less in the future.

Other considerations

• Recurring payments are not possible, might be a problem depending on your niche.
• We have a few thousand accounts and a few thousand addresses. Bitcoind queries are still very fast but we couldn't find any reliable metrics on queries against super large wallets with millions of addresses.

0-conf tx can be quite safe (for low-valued transactions of course, I wouldn't risk with cars or real estate) if you follow a few measures e.g. connect to a select number of whitelisted and trusted nodes and disable incoming connections.

Also read up how the tx fees are calculated and how you can reduce their sizes to pay lower fees and adjust them depending on the tx so that it goes in quicker.

Recurring payments? https://walletbit.com/docs/subscriptions

As for the part about micro transactions until more effective measures of storing the transactions that will take up less space are developed it will become more difficult.
Have you considered maybe using some alt-coins for the low-valued transactions and exchanging them automatically to BTC via some exchange's API?

From what I've read up from some users here (ie. those operating exchanges etc.) a 'heavy' (as in size) wallet.dat will slow down the client.[/list]

[marvingayerocks]

Yeah I find the confirmations an issue as well.. they take too long.

[bitcoinwatchdog]

I agree. The confirmation time involved is too long.  Also, opening up your "wallet" takes way too long to sync.

The fun thing about BitCoin is that it's like the Internet started over again...now we need an Amazon BitCoin, eBay BitCoin, PayPal BitCoin, Google BitCoin website search, etc.  For those that establish themselves as the brand leaders, it could be huge later.

[TangibleCryptography]

We have a few thousand accounts and a few thousand addresses. Bitcoind queries are still very fast but we couldn't find any reliable metrics on queries against super large wallets with millions of addresses.

We have found that once the wallet has more than ~5K addresses it tends to get sluggish.  Our solution is to use a unique address for each order, warn users to only send funds to the address for the current order (no re-use paying to old address).  We then create a new wallet roughly every 3,000 or so addresses and transfer funds to the new wallet.  As a precaution when we swap out wallets we save the old wallet.dat in offline backup to avoid clients losing funds if they send coins to an "old" address.  To date we have only had to retrieve funds from an offline backup once.

IMHO the most important improvement for business operators will be BIP32 (deterministic wallets) being added to reference client.  This should make "key management" related issues easier.

[TangibleCryptography]

opening up your "wallet" takes way too long to sync.

Simple, always leave your wallet open.  If you accept inbound connections, you also help keep the network decentralized by acting as a full node capable of relaying transactions to other nodes.

[Thirtybird]

Confirmation speed could be the death of bitcoin being a widely accepted means of exchange. Services like Bitpay, on the other hand, from what I gather is a service that makes this easy for a business to accept bitcoin even if they are not bitcoin savvy.

+1 to this - especially during times of high prices or a rally in the BTC price, the network can seem to crawls to a halt waiting for a new block to contain your transaction.  And if it's not propogated in that first block found after your transaction, your wait just got longer...  For the patient, it's fine, but for those who want to capitalize on a movement, it's frustrating

[FrankDizapo]

The standart transaction fees are actually reduced to the 0.0001 BTC in the new Version of the QT Client. Which is in RC right now, so it will probably come out soon.

For the rest of your cons I agree and I hope that it will become saver in the future to accept 0 confirmation transactions, but actually it is not very risky yet, compared to cargeback risks of other systems.

In the few thousand transactions, where there a single double spend?

Thanks for sharing.

Thanks for all the replies. We didn't have any double spending problems (yet).

[Zaih]

Great to hear your overall opinion on Bitcoin is positive Services like this only help the Bitcoin community out even more!

You realize 0.0002 transaction fee payments get confirmed pretty much at the same speed? You should let people know who are spending small amounts this