Account-feature stable?

[hardcode]

Is the account feature in the bitcoind client stable to manage 1,000's of accounts for a wallet service or is it better to manage balances/transactions using it's own database?

[1715203035]

1715203035

[1715203035]

1715203035

[DannyHamilton]

Use your own database.

The account feature in the Bitcoin Core wallet doesn't work the way most people seem to assume it works.

[hardcode]

Use your own database.

The account feature in the Bitcoin Core wallet doesn't work the way most people seem to assume it works.

I know how it works and found a way to make it work with my application, but my question is what would be better in terms of performance and stability. How do others do it when developing wallet functionality? I found a few code examples but seem to be using the account feature instead.

Are there any better alternatives to the bitcoin core wallet to do this?

[Muhammed Zakir]

I know how it works and found a way to make it work with my application, but my question is what would be better in terms of performance and stability. How do others do it when developing wallet functionality? I found a few code examples but seem to be using the account feature instead.

Are there any better alternatives to the bitcoin core wallet to do this?

AFAIK almost all people use Bitcoin core for these things including exchanges. I don't know of any other wallets which have or is good for RPC.

[hardcode]

I know how it works and found a way to make it work with my application, but my question is what would be better in terms of performance and stability. How do others do it when developing wallet functionality? I found a few code examples but seem to be using the account feature instead.

Are there any better alternatives to the bitcoin core wallet to do this?

AFAIK almost all people use Bitcoin core for these things including exchanges. I don't know of any other wallets which have or is good for RPC.

I was looking and couldn't find any others indeed. Would these exchanges use their own DB or rely on the accounting feature in the core client?

[2112]

I know how it works and found a way to make it work with my application, but my question is what would be better in terms of performance and stability. How do others do it when developing wallet functionality? I found a few code examples but seem to be using the account feature instead.

Thus far any business that claimed to understand and utilize the built-in account functionality turned out to be either:

1) incompetent (they only thought they understand)
2) fraudulent (it was just a convenient scapegoat for a premeditated scam)
3) some combination of above

with the end result being the loss of the depositor's funds.

[DannyHamilton]

I know how it works and found a way to make it work with my application, but my question is what would be better in terms of performance and stability. How do others do it when developing wallet functionality? I found a few code examples but seem to be using the account feature instead.

Thus far any business that claimed to understand and utilize the built-in account functionality turned out to be either:

1) incompetent (they only thought they understand)
2) fraudulent (it was just a convenient scapegoat for a premeditated scam)
3) some combination of above

with the end result being the loss of the depositor's funds.

Exactly.

It is perhaps possible that hardcode is in the small percentage of developers that have taken the time to carefully understand exactly how the account feature works and how to use it properly.  However, it is FAR more likely that hardcode is just one of the vast majority of developers that have misunderstood how the account feature works and is likely to end up unpleasantly surprised if they choose not to create their own account system in their own database.

[hardcode]

I think this clears all my questions out, thank you everybody for giving me the advice!

[theymos]

I like the accounts feature. It is probably slower than a real database (though I haven't benchmarked it), but it promotes good practices and it's very easy to use once you know how it works. However, it is designed mainly for the simple case of accepting payments, and that's probably all you should use it for. Don't use it as the basis of any sort of EWallet. Don't allow users to automatically withdraw BTC from your site if you're using accounts (unless you're a Bitcoin expert and you're super careful).

Bitcointalk.org uses accounts for the registration fee. Each user gets a unique account "forumuser_$UID" (so I'd be "forumuser_35"). I get their address with getaccountaddress forumuser_$user and check their balance with getbalance forumuser_$user $minconf. Bitcointalk.org's core Bitcoin handling code is just 82 lines, and it uses no libraries (JSON-RPC handling is 34 of these lines).

AFAIK accounts don't scale well enough for huge services to use them, but most sites should be fine. Keep in mind that you should not store much money on a live server, so you should sweep all money to an offline wallet frequently or do some sort of watch-only wallet setup. Also, you must backup wallet.dat at least as often as you backup your database, since it will contain the important user<->address database.

[DannyHamilton]

I like the accounts feature. It is probably slower than a real database (though I haven't benchmarked it), but it promotes good practices and it's very easy to use once you know how it works. However, it is designed mainly for the simple case of accepting payments, and that's probably all you should use it for.

I don't have anything against the accounts feature.  It's certainly a nice feature when used correctly.

Don't use it as the basis of any sort of EWallet.

And yet so many developers (including the OP) attempt to use it for exactly this purpose.

Don't allow users to withdraw BTC from your site if you're using accounts (unless you're a Bitcoin expert and you're super careful).

Exactly.  If you don't know exactly how the accounts feature works, there is a tendency to make assumptions.  Those assumptions tend to lead to disaster.