Provisioning multiple wallets via code? - bitcoin-qt in server mode

[cloverme]

I'm working on a project where I need to access multiple wallets on the same server through bitcoind using JSON.  I started going this route because I read that the practice or use of using accounts had been deprecated. That being said, is is possible to interface with bitcoind to do wallet management or is that not supported?  My goal is to manage multiple balances and account activity with separate wallet pass-phrases. Thanks for any feedback in advance.

[ncsupanda]

What do you mean by wallet management? From reading your question I don't see any reason as to why not.

By multiple wallets do you mean actual wallets and not different addresses? I could see you running into a port conflict if you try to launch multiple bitcoinds.

[cloverme]

What do you mean by wallet management? From reading your question I don't see any reason as to why not.

By multiple wallets do you mean actual wallets and not different addresses? I could see you running into a port conflict if you try to launch multiple bitcoinds.

Yes, ideally I'd like to have multiple wallets (opposed to addresses) for my development project.  There's lot of functionality in the api list (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list) but not a lot of functions for wallet management (aside from backup and changing the passphrase). I wasn't sure if there was a (new-wallet, open-wallet, close-wallet) type of functionality, which there doesn't appear to be.

So in my application, a "customer" will have an address that's associated with the server wallet. I can obtain the number of bitcoins associated with that address in the single wallet as well. In my database, I associate that "customer" with the bitcoin address that was generated for that specific "customer" when the customer account was setup.  I was thinking about using "accounts" within the wallet but I read here (https://en.bitcoin.it/wiki/Accounts_explained) that accounts don't scale well when dealing with thousands of accounts.

In short, it's not a big deal, there's just a tad more liability/risk with a single wallet being used with a single passphrase.

[ncsupanda]

What do you mean by wallet management? From reading your question I don't see any reason as to why not.

By multiple wallets do you mean actual wallets and not different addresses? I could see you running into a port conflict if you try to launch multiple bitcoinds.

Yes, ideally I'd like to have multiple wallets (opposed to addresses) for my development project.  There's lot of functionality in the api list (https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list) but not a lot of functions for wallet management (aside from backup and changing the passphrase). I wasn't sure if there was a (new-wallet, open-wallet, close-wallet) type of functionality, which there doesn't appear to be.

So in my application, a "customer" will have an address that's associated with the server wallet. I can obtain the number of bitcoins associated with that address in the single wallet as well. In my database, I associate that "customer" with the bitcoin address that was generated for that specific "customer" when the customer account was setup.  I was thinking about using "accounts" within the wallet but I read here (https://en.bitcoin.it/wiki/Accounts_explained) that accounts don't scale well when dealing with thousands of accounts.

In short, it's not a big deal, there's just a tad more liability/risk with a single wallet being used with a single passphrase.

It wouldn't scale well because of the number of resources needed on the hosting end to provide it.

If you wanted to have multiple wallets, you could try hosting them in a situation such as in individual virtual machines and connecting that way (You can see how this will get very messy very quickly).

Most people who deal in this kind of online-wallet system almost always use one "hot" wallet because of the fact that it's just not realizable to offer individual wallets per person.

Cold storage is your friend. Good luck!

[andytoshi]

Let me just cut off this train wreck of a thread.

@cloverme The technical problems around storing users' money are by far the easiest --- getting the appropriate legal protection and authorization, security audits, accounting, backup/recovery, etc. systems in place are much much harder. But you seem to be struggling at a very fundamental level with the technical problems. These are also problems with traditional payment mechanisms, but Bitcoin makes them much more serious because it requires the programmer to deal in low-level cryptographic primitives, and its transfers are irreversible. So I implore you to not write code handling other peoples' money.

Managing multiple users by giving them each different wallets is not only a terrible idea from a scalability perspective, it does not make conceptual sense. The money you are holding is in your possession, and that means you need to track all of the keys material, track transactions, etc. Smearing this stuff across hundreds or thousands of files is insane.

Addresses are ephemeral: you generate a new one for each payment you intend to receive, and it identifies that specific payment. It is like an invoice number. Having one per user is also a conceptual confusion.

The correct way to do this involves a proper delegated key management setup (using BIP32, for example) designed and audited by experts in this field. It is possible to use bitcoind to manage keys, though this adds quite a bit of complexity to creating a secure system. The majority of your funds at all times should be "cold", as some other users are saying. This means that no network-connected system is in possession of cryptographic keys required to move them.

[cloverme]

Let me just cut off this train wreck of a thread.
@cloverme The technical problems around storing users' money are by far the easiest --- getting the appropriate legal protection and authorization, security audits, accounting, backup/recovery, etc. systems in place are much much harder. But you seem to be struggling at a very fundamental level with the technical problems. These are also problems with traditional payment mechanisms, but Bitcoin makes them much more serious because it requires the programmer to deal in low-level cryptographic primitives, and its transfers are irreversible. So I implore you to not write code handling other peoples' money.
Managing multiple users by giving them each different wallets is not only a terrible idea from a scalability perspective, it does not make conceptual sense. The money you are holding is in your possession, and that means you need to track all of the keys material, track transactions, etc. Smearing this stuff across hundreds or thousands of files is insane.
Addresses are ephemeral: you generate a new one for each payment you intend to receive, and it identifies that specific payment. It is like an invoice number. Having one per user is also a conceptual confusion.
The correct way to do this involves a proper delegated key management setup (using BIP32, for example) designed and audited by experts in this field. It is possible to use bitcoind to manage keys, though this adds quite a bit of complexity to creating a secure system. The majority of your funds at all times should be "cold", as some other users are saying. This means that no network-connected system is in possession of cryptographic keys required to move them.

Thanks for the help, using a new address for each payment to be received is a good idea as is keeping a majority of the funds in cold storage. I've also received some tips to use Blockchain.info and their API's which doesn't look like a terrible idea since they support JSON RPC too. I'm in the research/design phase so there's no waste of good advice here.

[Luke-Jr]

Let me just cut off this train wreck of a thread.
@cloverme The technical problems around storing users' money are by far the easiest --- getting the appropriate legal protection and authorization, security audits, accounting, backup/recovery, etc. systems in place are much much harder. But you seem to be struggling at a very fundamental level with the technical problems. These are also problems with traditional payment mechanisms, but Bitcoin makes them much more serious because it requires the programmer to deal in low-level cryptographic primitives, and its transfers are irreversible. So I implore you to not write code handling other peoples' money.
Managing multiple users by giving them each different wallets is not only a terrible idea from a scalability perspective, it does not make conceptual sense. The money you are holding is in your possession, and that means you need to track all of the keys material, track transactions, etc. Smearing this stuff across hundreds or thousands of files is insane.
Addresses are ephemeral: you generate a new one for each payment you intend to receive, and it identifies that specific payment. It is like an invoice number. Having one per user is also a conceptual confusion.
The correct way to do this involves a proper delegated key management setup (using BIP32, for example) designed and audited by experts in this field. It is possible to use bitcoind to manage keys, though this adds quite a bit of complexity to creating a secure system. The majority of your funds at all times should be "cold", as some other users are saying. This means that no network-connected system is in possession of cryptographic keys required to move them.

Thanks for the help, using a new address for each payment to be received is a good idea as is keeping a majority of the funds in cold storage. I've also received some tips to use Blockchain.info and their API's which doesn't look like a terrible idea since they support JSON RPC too. I'm in the research/design phase so there's no waste of good advice here.

Using blockchain.info for anything is insanity and terrible advice.
Anyone advising that should be put on a "do not take advice about bitcoin from" list...

[cloverme]

Hmmm I was more inclined to use the wrappers for bitcoind locally anyway... that's what my test harness is using at the moment.  I believe blockchain.info had some thefts a year ago, so not a big selling point for me.