Best method for store bitcoin amount information of users

[norbertVC]

Hello community,
I'm currently developing a online warehouse where you can buy goods with bitcoins.
Each user gets his own bitcoin address where the user can make deposits.

How should I handle this?
I'm running a debian root with bitcoind - should I generate for each user a own account and assign addresses to this accounts or should I create only unassigned addresses and send the bitcoin to the "main" storage address and only update the amount in the mysql database?

And another question regarding security: I only want to store 5-10% of the bitcoin in a "hot" wallet and refill this amount if necassary to provide security.
What is the best method to store the other 90-95%? Paper wallets? And how can I automatically refill the hot wallet?

Sorry for my bad english!
Greetings, norbert.

[1713513686]

1713513686

[1713513686]

1713513686

[1713513686]

1713513686

[1713513686]

1713513686

[1713513686]

1713513686

[1713513686]

1713513686

[1000000]

And how can I automatically refill the hot wallet?

That's a bad idea, think about it again.

[DannyHamilton]

Each user gets his own bitcoin address where the user can make deposits.

This is a bad idea.  You should use a new bitcoin address for every transaction.

How should I handle this?

You should have a database of bitcoin addresses.  Anytime someone needs to send bitcoins to you, you should choose an address that you haven't previously chosen from this database.  You should identify in the database which chosen addresses are for which transactions.  That way once the address receives the payment, you can look up exactly what that payment was for.

I'm running a debian root with bitcoind - should I generate for each user a own account and assign addresses to this accounts or should I create only unassigned addresses and send the bitcoin to the "main" storage address and only update the amount in the mysql database?

I'm having a difficult time determining what you are asking here.

And another question regarding security: I only want to store 5-10% of the bitcoin in a "hot" wallet and refill this amount if necassary to provide security.

If you are only receiving bitcoins (and not sending them), what is the purpose of a "hot" wallet?

What is the best method to store the other 90-95%? Paper wallets?

Armory offline is a good solution for cold storage, paper wallets are ok too as long as you are careful and understand how to use them safely.

And how can I automatically refill the hot wallet?

No.

No, no, no.

If bitcoins can be removed from cold storage "automatically", then you are lying to yourself (and your users) and you don't have any cold storage.

[norbertVC]

Okay thanks - yeah I know that I should use a new address for every transaction - sorry not to meation that.
Bitcoind has the "account" feature where you can bind addresses to these account, so i thought this is propably useful.

And yes, i send xbt too - there is a withdraw possibillity.
i'm not very experienced with paper wallets - how do I handle them securly and how should the refill progress of the hot wallet look like?

Greetings

[Foxpup]

i'm not very experienced with paper wallets - how do I handle them securly and how should the refill progress of the hot wallet look like?

Any process that withdraws from the hot wallet should call getbalance to see how much is left in the hot wallet. If it is below a certain level, the process should notify your accounting department (by email, IM, whatever) that it needs to be manually refilled. Before they do that, they must do an audit to ensure that the hot wallet is low for a reason, ie, that all outgoing payments are in fact legitimate. If your accounting procedures are in order this will not be a major inconvenience. Skipping this audit defeats the whole purpose of having a cold wallet in the first place.

[cp1]

Are you sure you want to store your bitcoins instead of converting them to dollars?

[norbertVC]

Converting them to Dollar is no option - I believe in bitcoin as its own currency.
If the USD/XBT exchange value gets low, maybe I can't let every user withdraw his funds.

So what is the best way to store paper wallets securly?
Are there any specially made cases for them?

[fbueller]

I've implemented what you're suggesting before. There's all sorts of problems with it, as the coins are only as secure as your site. Offline wallets would be best. Imagine someone could alter their magic balance in the database and withdraw? Imagine like bitmit someone from your hosting company swiped your coin? You could look at generating addresses using an electrum mpk and scraping for payments.

[norbertVC]

I've implemented what you're suggesting before. There's all sorts of problems with it, as the coins are only as secure as your site. Offline wallets would be best. Imagine someone could alter their magic balance in the database and withdraw? Imagine like bitmit someone from your hosting company swiped your coin? You could look at generating addresses using an electrum mpk and scraping for payments.

Thanks for your advice - I host the server by myself, so only I (and perhaps the NSA ) have access to it.
Any withdraw will have to be confirmed by our staff.

So I guess one weakness is the staff.
Sure - you can check them, but you can't trust anyone completly - any advice?

What do you think of http://www.bitcointrezor.com/ for securing the cold wallet?
So it would be possible to check the cold wallets balance (for solvence proofs) but not to initiate transactions.

[fbueller]

I'm assuming your letting sellers register to trade on your store. I'm working on the same, as part of Bitwasp. I have decided against using JS in my code, but if its something you would use, this could be pretty nice:

You could do something with multisig addresses. Since there's a lot of JS out there that can do this in the browser (ms-brainwallet.org, coinb.in/multisig), you don't have to expose the user to anything beyond paying to an address, and entering their passphrase.

Have users enter a passphrase when registering. Maybe assign the user  a random nonce, that is transmitted when they're entering the passphrase: the nonce is used by a JS tool to determine how many iterations of SHA256 to apply to the passphrase before using the result as a seed.

On registration, the JS would send the master public key to the site. When the user makes an order, create a 2-of-2 address between you (your site would have its own MPK) and one buyer public key.

User pays to the secure order address. You craft a raw transaction paying the seller, and yourself a fee. A jQuery script on your site would show the user the (unsigned) payment to the merchant + the site's fees. They enter their passphrase, so JS can produce the needed key, then the transaction gets signed, returned to you (your script will only add the second needed signature if the first was signed by a key known to be owned by the user - its deterministic).
The user could decide against ordering - you create a refund transaction (paying the buyer back to a new determinstic address), and you would just sign and issue a refund.

You could do 2-of-3 if you want, but you probably don't want to deal with escrow. I'm coding all of this in PHP if that's any use.