Bitcoin Forum

SOLVED: It seems that best practices are already listed at https://en.bitcoin.it/wiki/Accounts_explained#Typical_Uses (https://en.bitcoin.it/wiki/Accounts_explained#Typical_Uses). Feel free to add your further comments and opinions.

I am working on a website running on bitcoin. Users will be able to deposit and withdraw bitcoins, also there will be transactions between users and the site possibly several times a day for each user. I'd like to do some premature optimization and build something that can scale for large number of users. What are the best practices in your opinion? I am considering three options:

1) Always consolidate option: Accounts will be maintained by bitcoind for every user. Every time a transaction happens bitcoins will be moved between accounts.
PROS:
No other background process (More reliable, faster website?)
Simpler database (faster?)
Less code
Incoming transaction confirmations will be handled by bitcoind
Account balance will be checked only by bitcoind calls
Transaction history checks are trivial
CONS:
More load on the bitcoin network (EDIT: WRONG!)
Lots of transaction fees (EDIT: WRONG!)
Performance issues with bitcoind for lots of accounts and transactions?


2) Periodic consolidation option: Every user still has own account in bitcoind. But transaction are stored in the database and committed periodically (once a day?) to bitcoind.
PROS:
Minimal load on the bitcoin network
Less transaction fees (EDIT: WRONG!)
Incoming transaction confirmations will be handled by bitcoind
CONS:
Extra daemon and database to maintain
Account balance checks require both database and bitcoind calls
Withdrawals require extra account consolidations
Transaction history checks might be tricky
Performance issues of bitcoind for large number of accounts?


3) No consolidation option: There will be single account for the whole site, but users will be given unique addresses for deposits. All internal transactions will be maintained in the database. External transactions will be monitored frequently (every minute?) and committed to the database.
PROS:
No unnecessary load on the bitcoin network
No unnecessary transaction fees
Account balance checks will only require a database call
Transaction history checks are trivial (but may be unreliable?)
Better bitcoind performance?
CONS:
Too much load by the daemon (overall performance issues?)
Extra daemon and database to maintain
More code
Issues with incoming transaction validations

Currently I am leaning towards the second option, but please add options, pros, cons or other opinion.
Thanks.

cj

Hi. Sorry if I'm missing something, but why don't you use the 'move' RPC command?


For my online wallet in-development, I'm currently letting bitcoind handle all this stuff and just add extra data in the application database, like custom address labels or transaction verifications.
(http://forum.bitcoin.org/index.php?topic=12403.0 if you are interested in details)

There is also a patch which implements pushing for new transactions/blocks: https://github.com/bitcoin/bitcoin/pull/198

So what you are suggesting is the first option. I was thinking that, for the network "move" commands are just transactions and require transaction fees. Am I wrong? Do we only pay transaction fees for wallet to wallet transactions?

Also I wasn't sure if bitcoind is good enough to handle many many accounts if the site happens to grow.

From the bitcoin wiki:
https://en.bitcoin.it/wiki/Accounts_explained (https://en.bitcoin.it/wiki/Accounts_explained)

So I was wrong. This makes the first option more compelling.