bitcoind accounts, alternatives?

[zzzezs]

Hello, I am currently extending my service which will now also support payment via. bitcoins and I have a few concerns/questions.

I have implemented my service to support bitcoind in a test network with the accounts feature, but I am starting to have second thoughts about using it in production.

According to Gavin Andresen, this "accounts" feature may or may not be removed in the future. I can not depend on something that may or may not be removed in a year or two.
Source: https://www.youtube.com/watch?v=GfMN2rFgowY

I'm not too worried about real-time balance updates. I only care that the users balance gets eventually synced (in the worst case max 45-60mins) with their current addresses balance, so that the users can then spend that amount.

Right now the balance of the users gets updated periodically using a cron job every n minutes where "n" is configurable. A cron job every 5-15 minutes is good enough for my needs.

I could use walletnotify etc. to calculate the users balance, but it seems like a lot more work than should be necessary for simply accepting bitcoin payments.

I can not depend on  any web services like blockchain, as there would probably be too many requests per hour.

Currently, each user receives a top-up address and an account which they can then send bitcoins to. It then checks the balance of this account with minimum x confirmations and updates my database accordingly. Then when the user wishes to purchase something my server moves funds from that users account to my account, and they then receive the goods.

Any advice?

[zzzezs]

In case anyone finds this via. google, instead of relying on the accounts feature you should use the rpc method "getreceivedbyaddress" in a cron script and calculate the users balance separately.

As real-time balance is not important for me, I will see how well this scales (probably not very well) and move over to the walletnotify/blocknotify methods described elsewhere if the cron script fails to keep up in the near future.

[CIYAM]

The accounts "feature" of Bitcoin has never been particularly useful (and have heard of very few people that actually use it because of the way that it works).

For anyone familiar with "accounting" it does not function in the way that you'd think it should (it was more designed for "user accounts" but as the Bitcoin wallet itself doesn't scale up no large websites have used it - or at least have only used it for a short time until they realise it kills their wallet performance).

I would tend to think that "removing" it would indeed be a good idea.

[alejandroZ]

I agree with CIYAM, it's probably better to write your own account system. What stack are you using? (I may have examples)

[zzzezs]

The accounts "feature" of Bitcoin has never been particularly useful (and have heard of very few people that actually use it because of the way that it works).

For anyone familiar with "accounting" it does not function in the way that you'd think it should (it was more designed for "user accounts" but as the Bitcoin wallet itself doesn't scale up no large websites have used it - or at least have only used it for a short time until they realise it kills their wallet performance).

I would tend to think that "removing" it would indeed be a good idea.

Yes it is not what I thought it was, I agree that removing it would be a good idea.

Initially I wanted to implement this with normal purchases rather than using a top up system, where I do not have to keep track of the users balance. In my system the user can not withdraw their funds, it is not an exchange so any amount the user sends to the top up address should be spent in the store.

I agree with CIYAM, it's probably better to write your own account system. What stack are you using? (I may have examples)

Thanks for the offer but I already implemented it.

[kjj]

For any serious use, you should be using blocknotify and walletnotify as part of an active monitoring system.

Checking balances in a cron job is fine for showing user balances, but you should not be taking any irreversible actions (shipping product, for example) based just on that information.