Quote from: loquitus_of_borg on May 20, 2015, 07:24:58 PM

So here is a few questions...

Blockchain lets you send BTC to someone, obviously. It has the option of "any address" vs selecting a specific address from a list.

1. Is it reasonable to assume that if I select a specific address, it will limit what I can send to the sum of all the unspent inputs sent to that specific address?

Yes. I know that in some clients, like Bitcoin Armory, you can specify which address(es) to send from, and it will only be able to spend from the unspent inputs for that address.

Quote from: loquitus_of_borg on May 20, 2015, 07:24:58 PM

2. Or is there more magic to this? Like say if I don't have enough on that specific address's own unspent inputs (but do from other addresses), it first sends the necessary unspent inputs from those others to the selected one, and then sends from the selected one to my intended recipient, sending the change to whereever I designate?

It will prevent you from being able to send more than the amount for that address and it will not use other inputs unless you tell it to.

Quote from: loquitus_of_borg on May 20, 2015, 07:24:58 PM

3. What would "any address" mean? Does it simply mean use any of the unspent inputs from any of the keypairs I have the private key for? So in theory, the "sender" could be a bunch of different addresses I have the private key for?

Any address means that it will create and send the transaction using as little input transactions as possible to keep the transaction as small as possible.

The "sender" could be many different addresses. However, the more input transactions you use, the higher fee you will need to pay.

Quote from: loquitus_of_borg on May 20, 2015, 07:24:58 PM

MOST importantly...

4. If I am building out a service where I want to receive BTC from my customers, what is best practice for this? Give each of them a unique and unchanging BTC address to make payments to? Does this violate the principle then that BTC addresses are not to be re-used? I am trying to avoid burdening my customers with the need to goto my site each time they want to make a payment to me to request a new BTC address to pay me with. I am also trying to avoid a related burden then of having to store all the keypair information for all the BTC addresses of all my customers.

The ideal scenario would have been that I have ONE BTC address that ALL BTC payments from ALL customers come to. I own the private key for this address. This would require me to look at the sending address of payment to know who sent it. BAD idea. The sending address is not deterministic.

Less ideal scenario is I have ONE BTC address for EACH customer. So Bob has his deposit address with me. Alice has own own. I own the private keys for these. So now, I can infer that if a payment comes into Bob's deposit address, I credit Bob. Etc. I am making no assumptions on Bob's sending address. But Bob's deposit address is now fixed. A BTC address is being re-used.

Least preferable scenario is everytime Bob wants to send me BTC, he can login to my site, as for a new BTC address, and pay to that address. He could technically pay more than once to the same address but the point here is Bob can keep getting new BTC address to pay me with. I have to now remember all of Bob's deposit addresses on the backend.

Thoughts? I am I right about these three scenarios?

Your first scenario would not be ideal, as different wallets and services may send from addresses that the customer does not actually own. It would be difficult to determine who sent what transaction and the customer may not be reusing addresses, so you would get lots of complaints, and it would be hard to manage each customer's payments.

The second scenario is very good for management, but reusing addresses is not recommended. However, it would allow you to easily track who is sending payments and easily credit them. You could also periodically sweep the funds from those addresses into your own main address. This however, breaks some of the anonymity because then others can see how much and when someone is depositing into your service.

Ideally you would use the third scenario, which gives each customer a new address each time, and your backend would need to know which address will be the one that receives the payment so that it can record the total balance in a database. Then, after the payment confirms, it generates a new address and waits for a payment to that address. This helps the payments stay anonymous to outsiders. You could then periodically sweep all of the funds into your main address.