Bitcoin Forum
July 06, 2024, 11:09:08 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Bitcoind accounts best practices  (Read 819 times)
coin_love (OP)
Newbie
*
Offline Offline

Activity: 22
Merit: 0


View Profile
October 29, 2013, 08:59:55 PM
Last edit: October 29, 2013, 09:28:05 PM by coin_love
 #1

We are researching hosting of bitcoind for Bitcoin payments. According to https://en.bitcoin.it/wiki/Accounts_explained, accounts do not scale to thousands of accounts with tens of thousands of transactions due to the lack of indexing.

What is the current recommendation regarding this and does the above limitation still apply? Is it best simply to "skip" accounts and use the default account for everything? Or simply go with accounts, avoid certain calls and move critical things to the application layer?
monsterer
Legendary
*
Offline Offline

Activity: 1008
Merit: 1002


View Profile
October 29, 2013, 09:29:38 PM
 #2

I'd like to know this as well.
knowitnothing
Sr. Member
****
Offline Offline

Activity: 294
Merit: 250


View Profile
October 29, 2013, 09:57:58 PM
 #3

We are researching hosting of bitcoind for Bitcoin payments. According to https://en.bitcoin.it/wiki/Accounts_explained, accounts do not scale to thousands of accounts with tens of thousands of transactions due to the lack of indexing.

What is the current recommendation regarding this and does the above limitation still apply? Is it best simply to "skip" accounts and use the default account for everything? Or simply go with accounts, avoid certain calls and move critical things to the application layer?

It depends on the kind of Bitcoin payment you're after. If it is the basic stuff that associates accounts to each user, and accepts deposits on those accounts, then it is recommended that you create a single account in bitcoind, then generate addresses for that one account, and use another database to make the association user <-> current bitcoin address.

Let's say this account is called "myappaccount". When a new user x registers, you do a "getnewaddress myappaccount", and associate (using a typical database like mysql, postgresql, mariadb, redis, ...) that the user x currently has this address you just generated. When you receive a deposit to "myappaccount", you check the address involved and detect which of your users own that address. Upon deposits you might also generate a new address, and then you repeat the association step.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 5250
Merit: 13093


View Profile
October 29, 2013, 09:59:29 PM
 #4

If you can use accounts, I recommend doing so. They encourage you to use best practices, and there are few reasons not to use them.

Quote
The accounts code does not scale up to thousands of accounts with tens of thousands of transactions, because by-account (and by-account-by-time) indices are not implemented. So many operations (like computing an account balance) require accessing every wallet transaction.

bitcoind scans the wallet transactions for any kind of balance lookup. getbalance <account> only scans the wallet once per account, whereas manually tracking addresses with getreceivedbyaddress causes bitcoind to scan the wallet once per address. So using accounts may be faster in some cases. Accounts may accumulate many old/unused addresses over time, which can slow things down, but you can do things to prevent/fix this if it becomes an issue.

If accounts are far too slow, raw addresses will probably also be too slow. You'll need to use caching or raw transactions in this case. But both of these things are difficult to do safely (maybe deceptively so for caching), so it's best to start out with accounts and only change things when you need to.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
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!