Why do the exchanges use temporary deposit addresses?

[thomkaufmann]

If the bitcoin server is able to generate addresses for each user's account, why do the exchange sites use temporary addresses?
Thanks in advance.

[1714799231]

1714799231

[sublimnl]

It makes tracking the deposit, or in my case a purchase, to ensure the full amount was received and confirmed. Also makes it easier to keep a ledger of all transactions by their unique id's so you can handle bookkeeping more efficiently - it's like each address is a receipt basically.

[ahtremblay]

It makes tracking the deposit, or in my case a purchase, to ensure the full amount was received and confirmed. Also makes it easier to keep a ledger of all transactions by their unique id's so you can handle bookkeeping more efficiently - it's like each address is a receipt basically.

You can still do al lof that with the address you send the funds to, even if you dont control the address.

[Ian Maxwell]

If the bitcoin server is able to generate addresses for each user's account

What bitcoin server?

why do the exchange sites use temporary addresses?

Because it's best practice for any business. It allows the receiver to say, "These 10 bitcoins were sent in payment of this invoice," because that invoice listed that address for payment.

[thomkaufmann]

If the bitcoin server is able to generate addresses for each user's account

What bitcoin server?

why do the exchange sites use temporary addresses?

Because it's best practice for any business. It allows the receiver to say, "These 10 bitcoins were sent in payment of this invoice," because that invoice listed that address for payment.

Thanks all for the responses.

bitcoind listtransactions <account>

That command will show you all of the transactions for user with account = <account>. So you can see exactly what deposits came in for that user.
It just seems odd that these exchanges would need additional management for depositing into the account. Why not just use bitcoin's existing functionality? In addition, expiring temporary addresses for end users seem clunky. Would an end user not prefer to have a permanent address to which they can send BTC to their exchange account?

[koin]

Would an end user not prefer to have a permanent address to which they can send BTC to their exchange account?

some will treat it that way, and maybe their loss is the ewallet owner's gain?  like a tip for the sweeper that finds loose change on the carpet after all the customers have left?

or perhaps those addresses are re-used in the future so that it makes it harder to simply assume that all funds sent to a single address went to a single account?

[Stephen Gornick]

Would an end user not prefer to have a permanent address to which they can send BTC to their exchange account?

  Ah ha!
  Simply appears to be a design issue.  By expiring addresses after a certain amount of time those expired addresses no longer clog up the list that is used to determine which account the funds received should go to.  This is an easily solved problem so perhaps the exchange will at some point allow addresses to be static and available for re-use.
 - http://forum.bitcoin.org/index.php?topic=15157.msg205605#msg205605

[just_someguy]

I can't speak to why someone else would do it but there are two reasons I would:

1. It makes maintenance easier.

Instead of locking yourself into maintaining a single ever expanding wallet.dat file forever you can refresh it occasionally. You can point new orders to a new install, wait 24 hours, transfer the funds from the old wallet to the new and have a trimmed down wallet.dat.

2. Security.

I think people are crazy for having a direct link between their web server and Bitcoin JSON-RPC.
If you are just accepting payments through bitcoin there is no reason to do this.
Instead you pre-generate 10,000 keys and take the wallet offline.
Load the addresses for these keys into a database and lock the private portion in a safe.
Now you can rotate the receiving addresses for whatever you receiving target window happens to be without risking someone breaking in to your wallet.
You could reuse these addresses forever without ever exposing your private key until you want to send.

If you trust it you can even verify payments totally offline by checking against blockexplorer.

(IMO, an open source block explorer would be one of the greatest security enhancements that could be made to bitcoin commerce.)

[thomkaufmann]

I can't speak to why someone else would do it but there are two reasons I would:

1. It makes maintenance easier.

Instead of locking yourself into maintaining a single ever expanding wallet.dat file forever you can refresh it occasionally. You can point new orders to a new install, wait 24 hours, transfer the funds from the old wallet to the new and have a trimmed down wallet.dat.

2. Security.

I think people are crazy for having a direct link between their web server and Bitcoin JSON-RPC.
If you are just accepting payments through bitcoin there is no reason to do this.
Instead you pre-generate 10,000 keys and take the wallet offline.
Load the addresses for these keys into a database and lock the private portion in a safe.
Now you can rotate the receiving addresses for whatever you receiving target window happens to be without risking someone breaking in to your wallet.
You could reuse these addresses forever without ever exposing your private key until you want to send.

If you trust it you can even verify payments totally offline by checking against blockexplorer.

(IMO, an open source block explorer would be one of the greatest security enhancements that could be made to bitcoin commerce.)

thanks, guy. I appreciate the explanation. So the final part, how do you send BTC to a user if your Bitcoin JSON-RPC is isolated from the webserver?

[just_someguy]

thanks, guy. I appreciate the explanation. So the final part, how do you send BTC to a user if your Bitcoin JSON-RPC is isolated from the webserver?

I would have a script/program on the sending machine download the latest withdrawal requests and process them from there.
You could get close to real time depending on how often you run the script, or you could just run it once an hour after checking to make sure nothing seems out of the ordinary.

If you suspect someone has broken in you can just not run the script and they have no way of directly reaching your funds.