How to receive bitcoin in one wallet but somehow know who sent it?

[loquitus_of_borg]

Hi.

I am trying to build a service where I provide my users the ability to deposit bitcoin into a hosted wallet of sorts. So obviously, they need to be given a bitcoin address to send the coins to.

A couple options I thought of:

- Provide each user a unique "deposit" bitcoin address to send to. This now means I need to create and manage a pub/private key pair for each user, and then monitor each of these for incoming payments. Not my favorite approach. Tedious and more spammy.

- Provide one bitcoin address for everyone to deposit to and look at the sender bitcoin address. But now each user on my system is constrained to register a single bitcoin address with me so I can recognize their deposits. I could now look at the sender's address in the tx, right? I know this might sound obvious but I am a bit confused about unspent inputs from the sending address. Namely, if address A receives bitcoin from a bunch of different senders and then A wants to send to B, as far as B is concerned, all those payments came from A as the sender right?

Are there any other options that are cleaner than these? Any errors in my assumptions?

[DannyHamilton]

- snip -
- Provide each user a unique "deposit" bitcoin address to send to. This now means I need to create and manage a pub/private key pair for each user, and then monitor each of these for incoming payments. Not my favorite approach. Tedious and more spammy.
- snip -

Addresses are not account numbers.  You shouldn't re-use addresses.  You should think of an address more like an invoice number.  It is a unique identifier that you give to someone so that they can send you a payment.  If they will send you a new payment, they should get a new address. You should give a new address for EVERY payment you will receive.

- Provide one bitcoin address for everyone to deposit to and look at the sender bitcoin address.

Bitcoins don't have "sender addresses".  Some services make an attempt to guess at the sender based on some assumptions about the previous transactions, but there is always a chance you will guess wrong.  This will result in confusion and frustrated customers.

Are there any other options that are cleaner than these?

Yes.  Do it the right way.  Treat each address as a unique payment identifier, and generate a new address for every payment that any user will be sending you.  Then keep that list of addresses in a database that you can reference.

Any errors in my assumptions?

Yes.

You cannot count on a user having control over what address their bitcoins were previously received at.  Do not attempt to guess at a "Sending address" on a transaction.  The bitcoin protocol does not spend bitcoins from addresses, it uses unspent outputs to provide value to a transaction.  Those unspent outputs might not have been received at any address at all, they might have been received at multiple addresses, the address they were previously received at might not even be under the control of the user that is sending you bitcoins.

[Kefkius]

As an absolute minimum, you need every user to have 1 deposit address. For bonus points, users need to be able to generate a new deposit address at their own volition. If you want to be a model of responsible Bitcoin handling, tell users that their deposit addresses are one-time-only and automatically generate a new one after each deposit. (Note that this last option may cause users to be inconvenienced since they can't just deposit to one address repeatedly.)

The easy way to do this is with Hierarchical Deterministic (HD) keys. See BIP-0044. Using a master key and BIP-0044, your scheme would look like this:

User #0 deposit address #0: m/44'/0'/0'/0/0
User #0 deposit address #1: m/44'/0'/0'/0/1
User #1 deposit address #0: m/44'/0'/1'/0/0
etc.

There are some handy tools for working with HD keys; one I use a lot is pycoin.

[tertius993]

Addresses are not account numbers.  You shouldn't re-use addresses.  You should think of an address more like an invoice number.  It is a unique identifier that you give to someone so that they can send you a payment.  If they will send you a new payment, they should get a new address. You should give a new address for EVERY payment you will receive.

I think this is one of the most difficult concepts to get one's head around.  I suspect it's because we "want" to think of them as being analogous to bank accounts, plus of course the shorthand habit of referring to them as "wallets" means one's instinct as to consider them as a place where you put "money" and if you put it there, then it stands to reason that is where you expect to take it from.

[loquitus_of_borg]

- snip -
- Provide each user a unique "deposit" bitcoin address to send to. This now means I need to create and manage a pub/private key pair for each user, and then monitor each of these for incoming payments. Not my favorite approach. Tedious and more spammy.
- snip -

Addresses are not account numbers.  You shouldn't re-use addresses.  You should think of an address more like an invoice number.  It is a unique identifier that you give to someone so that they can send you a payment.  If they will send you a new payment, they should get a new address. You should give a new address for EVERY payment you will receive.

Out of curiosity, is this a philosophical thing? I mean -- why not use an address as an account number? Technically, it is feasible, right? You are holding a certain private key, and that private key translates to some unique public key that translates to a specific BTC address.

So is this suggestion there to increase and maintain anonymity?

Even if a user keeps using different "throwaway" BTC addresses for each payment, these are each funded by their "master" BTC address, right? Or is this not true due to your "unspent" outputs statement?

[virtualx]

- snip -
- Provide each user a unique "deposit" bitcoin address to send to. This now means I need to create and manage a pub/private key pair for each user, and then monitor each of these for incoming payments. Not my favorite approach. Tedious and more spammy.
- snip -

Addresses are not account numbers.  You shouldn't re-use addresses.  You should think of an address more like an invoice number.  It is a unique identifier that you give to someone so that they can send you a payment.  If they will send you a new payment, they should get a new address. You should give a new address for EVERY payment you will receive.

Out of curiosity, is this a philosophical thing? I mean -- why not use an address as an account number? Technically, it is feasible, right? You are holding a certain private key, and that private key translates to some unique public key that translates to a specific BTC address.

So is this suggestion there to increase and maintain anonymity?

Even if a user keeps using different "throwaway" BTC addresses for each payment, these are each funded by their "master" BTC address, right? Or is this not true due to your "unspent" outputs statement?

A bitcoin address is not an account number. You can use the same address many times and this works by "accident", not by design. It is considered a bad practice, and not something that should be done.  The bitcoin system does not have any  account numbers. https://en.bitcoin.it/wiki/Address_reuse

Especially:

Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins. Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm.

All bitcoin online payment sites use different addresses for receiving and sending money. It is free to create a bitcoin address so there is no problem with that.

[DannyHamilton]

I think this is one of the most difficult concepts to get one's head around.  I suspect it's because we "want" to think of them as being analogous to bank accounts, plus of course the shorthand habit of referring to them as "wallets" means one's instinct as to consider them as a place where you put "money" and if you put it there, then it stands to reason that is where you expect to take it from.

An address is not a wallet.  A wallet is a collection of one or more addresses along with the private keys necessary to spend any bitcoins received at that wallet.

If you think of a bitcoin address as an invoice number, then the idea that there is no "sent from" address makes a lot more sense.

I can give out a dozen invoices to people that are going to pay me.  Each of them will include the invoice number when they send their payment.  They can even think of it as sending the money to the invoice. Then when I receive the cash, it all goes into the wallet in my back pocket.  Later when I buy something, I don't take the money "from and invoice number", I just take money out of my wallet.  My wallet doesn't have an identifier that I supply to the grocery store.

Another thing to remember is that, at the protocol level, there aren't any addresses.  There are only scripts that encumber an output with a requirement that must be met before the output can be used as an input to a transaction.  We humans use "addresses" as a convenient shorthand to request a particular script on our outputs, but other scripts that aren't currently encodable as an address can also exist.

- snip -
- Provide each user a unique "deposit" bitcoin address to send to. This now means I need to create and manage a pub/private key pair for each user, and then monitor each of these for incoming payments. Not my favorite approach. Tedious and more spammy.
- snip -

Addresses are not account numbers.  You shouldn't re-use addresses.  You should think of an address more like an invoice number.  It is a unique identifier that you give to someone so that they can send you a payment.  If they will send you a new payment, they should get a new address. You should give a new address for EVERY payment you will receive.

Out of curiosity, is this a philosophical thing? I mean -- why not use an address as an account number? Technically, it is feasible, right? You are holding a certain private key, and that private key translates to some unique public key that translates to a specific BTC address.

Yes, you CAN use a bitcoin address as an "account number" if you want to, but you CAN'T FORCE everyone else to do the same.  If you choose to operate a service where you expect all your users to use bitcoin addresses as account numbers, then you need to make this VERY clear to any and all potential users.  Unfortunately, many users don't understand how their chosen method of storing bitcoins works, so they'll attempt to use your service and then be surprised when they discover that it doesn't work properly. They may not know all their addresses, they may not control their private key, or they may be using a service that stores bitcoins with scripts other than version 1 and version 3.

As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction.  The change from their transaction will be sent to this new address.  They won't know what the new address is, it won't show up anywhere in the user interface.  If you ask them what their "sending address" or "wallet address" is, they'll give you a RECEIVING address.  Then when they send bitcoins from the wallet, the bitcoins will appear to come "from" an address that they don't know anything about.

As another example, a user may have just purchased bitcoins at localbitcoins.com.  Then they may send the bitcoins to you from their localbitcoins.com account. They won't have any control at all over what the "sending" address is.  Localbitcoins will simply send from their own wallet and then adjust the database entry for their user's account in their own system.  If you send bitcoins "back" to ANY of the addresses that look like "sending" address in that transaction, the user will NOT receive the bitcoins back.  Instead localbitcoins will receive the bitcoins in their own wallet and won't know which of their thousands of users the bitcoins were supposed to be credited to.

As another example, someone may create a complex output script that can not currently be encoded as an address.  They may send their bitcoins to an output that is encumbered with this script.  Then later when they spend the output to send bitcoins to you, you won't be able to find any sending "address" at all.

It is a "philosophical thing" that YOU shouldn't use your own bitcoin address as an account. It is NOT a "philosophical thing" that you can't assume that EVERYONE ELSE is using their bitcoin addresses as accounts.

So is this suggestion there to increase and maintain anonymity?

You do increase personal privacy and anonymity, as well as improving the fungible nature of bitcoins by using a new address for every transaction.  However, there are many other reasons that a service shouldn't try to guess what someone's address is. There are security reasons that a service should provide a new address for every transaction.

Even if a user keeps using different "throwaway" BTC addresses for each payment, these are each funded by their "master" BTC address, right?

No.  That is not how bitcoin works.  I'm using Bitcoin Core, and every transaction I have ever received goes to a brand new randomly generated address.  There is no "master address".  When I want bitcoins, I click the "Request Payment" button, and the wallet generates a BRAND NEW address for me.  Then I give this address to the person that is sending me the bitcoins.  Once I close the "Request Payment" window, the address disappears, and I never see the address again.  There are some wallets and services that allow users to re-use addresses, but I tend to avoid those services when possible.  Any service that is lazy enough to create such a poor design can't be trusted to safely handle my bitcoins.

Or is this not true due to your "unspent" outputs statement?

Correct.  At the protocol level, there are no "addresses".  There are no "accounts".  There are no "balances".  These are all words that we humans use to abstract the underlying process to make it easier to talk about the transfer of control over value. In reality there are only transactions that use previously unspent outputs as inputs and which create new unspent outputs.  Outputs are encumbered with a requirement (in the form of a computer program called a "script") that must be met in order to be used as inputs.  We have taken just two of those scripts and decided that they are common enough that they can be assigned a version number (version 1 scripts, and version 3 scripts).  Then we use that version number along with a chunk of data that is necessary for building the script and a checksum to prevent typing errors.  We concatenate those three pieces of information, and call it an "address".  Meanwhile, there can be outputs that are encumbered with a script that is neither version 1, nor version 3.  Such an output cannot currently be encoded as an address at all.

[loquitus_of_borg]

@DannyHamilton

Thanks for the wonderful response. I think it clears up much.

I understand now that when I "login" to see my wallet, what I am logging into is really a semantic that has nothing at all to do with Bitcoin. I am logging into an environment that now has access to all the private/public key pairs that "belong" to me. The pairs that involve unspent inputs are important since these contain BTC that have value and I could spend.

Whenever I want to receive BTC from some arbitrary user Bob, I do not at any point tell Bob ANYTHING about my existing public keys that I hold the private key for (where the public key is effectively a BTC address). What I do instead is generate a NEW key pair, keeping the private key stored only in this secure environment I just logged into (how this is implemented is not relevant -- could be stored in the cloud or on my local hard drive or whatever), and give Bob the BTC address corresponding to the public key from this pair. Bob makes the payment, not knowing anything about what other pairs I hold nor any unspent inputs among them.

Now, once I have received that BTC from Bob, I have another pair that I manage that has unspent inputs.

Some questions:

1. Is the above accurate?
2. Over time, won't this environment I am managing become rather unwieldy to manage? Over the course of say 80 years of a human life time for someone who is 15 years old now and using this environment, they will have a new pair for every single payment they ever receive. That could be thousands of BTC addresses they now have pairs for.
3. This bit confuses me: "As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction". I can see how when I want Bob to send me BTC, I generate a new key pair. But to send, how do I have a new address generated automatically? I mean sure, I could generate one, but I have to "fund" it with the unspent inputs from one of the other keypairs I own before I can make a payment from it, right? How is that anonymous? Now, there is a connection from this new keypair to the one that funded it. So the recipient may as well just receive BTC from the original keypair (ie: the original keypair may as well sign off on spending some of its unspent inputs to pay Bob).
4. In general, I get that if Alice pays Bob, Bob can create new keypairs so Alice never knows about what Bob has in his "wallet" other than all the addresses Alice paid Bob from. But whenever Bob pays Carol, he has to use previous keypairs to fund the payment to Carol, so Carol now knows through the blockchain what addresses Bob funded with. Furthermore, Alice can see where the BTC she sent Bob went on to. Am I getting this right? So basically, Bob cannot anonymize the source of his payments to Carol -- he can only anonymize his holdings from Alice who pays him.

[achow101_alt]

1. Is the above accurate?

yes.

2. Over time, won't this environment I am managing become rather unwieldy to manage? Over the course of say 80 years of a human life time for someone who is 15 years old now and using this environment, they will have a new pair for every single payment they ever receive. That could be thousands of BTC addresses they now have pairs for.

It could be, but the keypairs are very small, and several thousand addresses would only take up a couple Mb tops. With current technology, and the current growth, this will never become a problem.

3. This bit confuses me: "As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction". I can see how when I want Bob to send me BTC, I generate a new key pair. But to send, how do I have a new address generated automatically? I mean sure, I could generate one, but I have to "fund" it with the unspent inputs from one of the other keypairs I own before I can make a payment from it, right? How is that anonymous? Now, there is a connection from this new keypair to the one that funded it. So the recipient may as well just receive BTC from the original keypair (ie: the original keypair may as well sign off on spending some of its unspent inputs to pay Bob).

A new keypair is not generated for each send. Bitcoin core sends your funds from one or more of the addresses you own, and the remainder from the address goes to a newly generated address as the change. It will try to involve as few inputs as possible in order to create your transaction.

4. In general, I get that if Alice pays Bob, Bob can create new keypairs so Alice never knows about what Bob has in his "wallet" other than all the addresses Alice paid Bob from. But whenever Bob pays Carol, he has to use previous keypairs to fund the payment to Carol, so Carol now knows through the blockchain what addresses Bob funded with. Furthermore, Alice can see where the BTC she sent Bob went on to. Am I getting this right? So basically, Bob cannot anonymize the source of his payments to Carol -- he can only anonymize his holdings from Alice who pays him.

Bob can send his bitcoin to a mixer. The mixer service allows Bob to send multiple payments, one from each of his addresses, to them and then he can withdraw his bitcoin from the service when all of his Bitcoin has been sent there. The withdrawal takes Bitcoin from addresses that he did not send to and sends that to another newly generated address owned by Bob, thus anonymizing his Bitcoin. Alice will only know that the Bitcoin she sent Bob went to another address, but she will have lost her trail on Bob. Carol will only know that he funded his address from other addresses, but tracing those, she will be tracing Bob's payments.

If Bob does not use a mixer, then Carol can see the addresses she is being paid from, and Alice can see where the Bitcoin is being sent. If Bob also sends from many of his addresses, then both Carol and Alice will know what addresses Bob has.

[DannyHamilton]

@DannyHamilton

Thanks for the wonderful response. I think it clears up much.

I understand now that when I "login" to see my wallet, what I am logging into is really a semantic that has nothing at all to do with Bitcoin. I am logging into an environment that now has access to all the private/public key pairs that "belong" to me. The pairs that involve unspent inputs are important since these contain BTC that have value and I could spend.

Whenever I want to receive BTC from some arbitrary user Bob, I do not at any point tell Bob ANYTHING about my existing public keys that I hold the private key for (where the public key is effectively a BTC address). What I do instead is generate a NEW key pair, keeping the private key stored only in this secure environment I just logged into (how this is implemented is not relevant -- could be stored in the cloud or on my local hard drive or whatever), and give Bob the BTC address corresponding to the public key from this pair. Bob makes the payment, not knowing anything about what other pairs I hold nor any unspent inputs among them.

Now, once I have received that BTC from Bob, I have another pair that I manage that has unspent inputs.

Some questions:

1. Is the above accurate?

You're getting closer, but I think you're still missing some big pieces about how bitcoin works. Have you read the bitcoin whitepaper yet?  It really should be a prerequisite to engage in the "Development & Technical Discussion" forum to have at least read the whitepaper for a basic understanding of what bitcoin attempts to accomplish and how it attempts to accomplish it.

2. Over time, won't this environment I am managing become rather unwieldy to manage? Over the course of say 80 years of a human life time for someone who is 15 years old now and using this environment, they will have a new pair for every single payment they ever receive. That could be thousands of BTC addresses they now have pairs for.

Sure, I suppose there could be thousands of pairs in a wallet if the user NEVER switches to a new wallet for their entire life.  That seems unlikely to me, but a computer should manage a few thousand keypairs without an problem.  Why would it be "unwieldy"?

3. This bit confuses me: "As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction". I can see how when I want Bob to send me BTC, I generate a new key pair. But to send, how do I have a new address generated automatically? I mean sure, I could generate one, but I have to "fund" it with the unspent inputs from one of the other keypairs I own before I can make a payment from it, right? How is that anonymous? Now, there is a connection from this new keypair to the one that funded it. So the recipient may as well just receive BTC from the original keypair (ie: the original keypair may as well sign off on spending some of its unspent inputs to pay Bob).

Yep, I was right, you're definitely still missing some big pieces about how bitcoin works.  Please read the whitepaper, then read about transaction "change".  Then we'll discuss this further if you still have questions.

4. In general, I get that if Alice pays Bob, Bob can create new keypairs so Alice never knows about what Bob has in his "wallet" other than all the addresses Alice paid Bob from. But whenever Bob pays Carol, he has to use previous keypairs to fund the payment to Carol, so Carol now knows through the blockchain what addresses Bob funded with. Furthermore, Alice can see where the BTC she sent Bob went on to. Am I getting this right? So basically, Bob cannot anonymize the source of his payments to Carol -- he can only anonymize his holdings from Alice who pays him.

Carol doesn't know anything about which addresses Alice was using, or what other addresses Bob received bitcoins at.  Alice doesn't know anything about Carol's addresses, or what other funds Bob may have sent in other transactions.

It is possible for some addresses to be linked together.  If a user is careful (especially if they use a wallet that provides "coin control" features), then they can reduce the connections and improve their privacy.

Bitcoin Whitepaper:
https://bitcoin.org/bitcoin.pdf

Change:
https://en.bitcoin.it/wiki/Change

[loquitus_of_borg]

2. Over time, won't this environment I am managing become rather unwieldy to manage? Over the course of say 80 years of a human life time for someone who is 15 years old now and using this environment, they will have a new pair for every single payment they ever receive. That could be thousands of BTC addresses they now have pairs for.

It could be, but the keypairs are very small, and several thousand addresses would only take up a couple Mb tops. With current technology, and the current growth, this will never become a problem.

I suppose that once a keypair has 0 BTC left as unspent inputs, we could discard it from the "environment"? Thereby keeping the "environment" lean?

Still, it means we have a Blockchain that grows like mad. Over time, every BTC address ever used by ever user since genesis is in there. There is no real way to "compress" or trim this Blockchain if a person's "balance" it determined as a result of their transaction trail.

3. This bit confuses me: "As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction". I can see how when I want Bob to send me BTC, I generate a new key pair. But to send, how do I have a new address generated automatically? I mean sure, I could generate one, but I have to "fund" it with the unspent inputs from one of the other keypairs I own before I can make a payment from it, right? How is that anonymous? Now, there is a connection from this new keypair to the one that funded it. So the recipient may as well just receive BTC from the original keypair (ie: the original keypair may as well sign off on spending some of its unspent inputs to pay Bob).

A new keypair is not generated for each send. Bitcoin core sends your funds from one or more of the addresses you own, and the remainder from the address goes to a newly generated address as the change. It will try to involve as few inputs as possible in order to create your transaction.

So indeed the recipient now knows who paid me. And who paid me now knows who I paid?

Why even bother with a new change address? It is still tied back to the receiving keypair. So no anonymity gained here...

4. In general, I get that if Alice pays Bob, Bob can create new keypairs so Alice never knows about what Bob has in his "wallet" other than all the addresses Alice paid Bob from. But whenever Bob pays Carol, he has to use previous keypairs to fund the payment to Carol, so Carol now knows through the blockchain what addresses Bob funded with. Furthermore, Alice can see where the BTC she sent Bob went on to. Am I getting this right? So basically, Bob cannot anonymize the source of his payments to Carol -- he can only anonymize his holdings from Alice who pays him.

Bob can send his bitcoin to a mixer. The mixer service allows Bob to send multiple payments, one from each of his addresses, to them and then he can withdraw his bitcoin from the service when all of his Bitcoin has been sent there. The withdrawal takes Bitcoin from addresses that he did not send to and sends that to another newly generated address owned by Bob, thus anonymizing his Bitcoin. Alice will only know that the Bitcoin she sent Bob went to another address, but she will have lost her trail on Bob. Carol will only know that he funded his address from other addresses, but tracing those, she will be tracing Bob's payments.

If Bob does not use a mixer, then Carol can see the addresses she is being paid from, and Alice can see where the Bitcoin is being sent. If Bob also sends from many of his addresses, then both Carol and Alice will know what addresses Bob has.
[/quote]

Well, I heard about mixers. But this is now a value added service on top of Bitcoin and Bob has to trust the mixer to not decide to vanish at that point in time and walk away with whatever is in the "bowl" at that time, right?

Overall then, all the people who paid me for a certain "group" of BTC will know all the people I paid that BTC out to, and vice versa. I can create "islands" of privacy so that each time I am paid, I have a new keypair that has nothing to do with the existing ones, but now all the people who get paid by the BTC on this new island know who paid me on the same island.

Furthermore, if I need to make a big payment in BTC, I will likely have to combine the BTC from many different islands. Now, all those people who were on all those islands know about each other, as well as the guy I making the big payment to. Is this accurate?

[loquitus_of_borg]

@DannyHamilton

Thanks for the wonderful response. I think it clears up much.

I understand now that when I "login" to see my wallet, what I am logging into is really a semantic that has nothing at all to do with Bitcoin. I am logging into an environment that now has access to all the private/public key pairs that "belong" to me. The pairs that involve unspent inputs are important since these contain BTC that have value and I could spend.

Whenever I want to receive BTC from some arbitrary user Bob, I do not at any point tell Bob ANYTHING about my existing public keys that I hold the private key for (where the public key is effectively a BTC address). What I do instead is generate a NEW key pair, keeping the private key stored only in this secure environment I just logged into (how this is implemented is not relevant -- could be stored in the cloud or on my local hard drive or whatever), and give Bob the BTC address corresponding to the public key from this pair. Bob makes the payment, not knowing anything about what other pairs I hold nor any unspent inputs among them.

Now, once I have received that BTC from Bob, I have another pair that I manage that has unspent inputs.

Some questions:

1. Is the above accurate?

You're getting closer, but I think you're still missing some big pieces about how bitcoin works. Have you read the bitcoin whitepaper yet?  It really should be a prerequisite to engage in the "Development & Technical Discussion" forum to have at least read the whitepaper for a basic understanding of what bitcoin attempts to accomplish and how it attempts to accomplish it.

2. Over time, won't this environment I am managing become rather unwieldy to manage? Over the course of say 80 years of a human life time for someone who is 15 years old now and using this environment, they will have a new pair for every single payment they ever receive. That could be thousands of BTC addresses they now have pairs for.

Sure, I suppose there could be thousands of pairs in a wallet if the user NEVER switches to a new wallet for their entire life.  That seems unlikely to me, but a computer should manage a few thousand keypairs without an problem.  Why would it be "unwieldy"?

3. This bit confuses me: "As an example, any casual user of Bitcoin Core will have new addresses generated for them without their knowledge every time they send a transaction". I can see how when I want Bob to send me BTC, I generate a new key pair. But to send, how do I have a new address generated automatically? I mean sure, I could generate one, but I have to "fund" it with the unspent inputs from one of the other keypairs I own before I can make a payment from it, right? How is that anonymous? Now, there is a connection from this new keypair to the one that funded it. So the recipient may as well just receive BTC from the original keypair (ie: the original keypair may as well sign off on spending some of its unspent inputs to pay Bob).

Yep, I was right, you're definitely still missing some big pieces about how bitcoin works.  Please read the whitepaper, then read about transaction "change".  Then we'll discuss this further if you still have questions.

4. In general, I get that if Alice pays Bob, Bob can create new keypairs so Alice never knows about what Bob has in his "wallet" other than all the addresses Alice paid Bob from. But whenever Bob pays Carol, he has to use previous keypairs to fund the payment to Carol, so Carol now knows through the blockchain what addresses Bob funded with. Furthermore, Alice can see where the BTC she sent Bob went on to. Am I getting this right? So basically, Bob cannot anonymize the source of his payments to Carol -- he can only anonymize his holdings from Alice who pays him.

Carol doesn't know anything about which addresses Alice was using, or what other addresses Bob received bitcoins at.  Alice doesn't know anything about Carol's addresses, or what other funds Bob may have sent in other transactions.

It is possible for some addresses to be linked together.  If a user is careful (especially if they use a wallet that provides "coin control" features), then they can reduce the connections and improve their privacy.

Bitcoin Whitepaper:
https://bitcoin.org/bitcoin.pdf

Change:
https://en.bitcoin.it/wiki/Change

Actually, I did read it. A while ago. I will give it another go. Thanks for the quick response.

[loquitus_of_borg]

So here are 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?

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?

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?

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?

[achow101_alt]

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.

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.

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.

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.

[loquitus_of_borg]

What is the main reason my second scenario is not ideal? Is it the re-use of the payment address because now, that can be tracked and reduces anonymity? Or are there any other reasons? What about any increased risks?

[achow101_alt]

What is the main reason my second scenario is not ideal? Is it the re-use of the payment address because now, that can be tracked and reduces anonymity? Or are there any other reasons? What about any increased risks?

Primarily because people can track someone's payments to a site and reduces the anonymity.

[loquitus_of_borg]

It is a bit odd. Bitcoin Forum has a field for "Bitcoin Address". I don't actually have a "Bitcoin Address", do I?

Makes me wonder. In general, if I want anonymity, there is no way for me to advertise an address of mine. I know that sounds obvious, but if I wanted to receive payments, someone would have to goto my site and ask me for one.

[Mikestang]

You shouldn't re-use addresses.

Satoshi made one post about the re-use of bitcoin addresses and everyone takes it to the extreme.

Please explain why someone should not re-use an address.

I'll save you the effort, because there are no valid technical reasons.  There are "privacy reasons" (bearing in mind that bitcoin was never intended to be, or portrayed as, an anonymous payment method) why re-use may be considered less than ideal, but I'm tired of seeing people say you should not do it like it's a plague or something.

[achow101_alt]

You shouldn't re-use addresses.

Satoshi made one post about the re-use of bitcoin addresses and everyone takes it to the extreme.

Please explain why someone should not re-use an address.

I'll save you the effort, because there are no valid technical reasons.  There are "privacy reasons" (bearing in mind that bitcoin was never intended to be, or portrayed as, an anonymous payment method) why re-use may be considered less than ideal, but I'm tired of seeing people say you should not do it like it's a plague or something.

The only good reason that people shouldn't reuse addresses is to maintain privacy. By not reusing addresses, it becomes more difficult to monitor and track someone's payments. As a service provider, it would be easier to give each customer their own address, BUT, many bitcoiners do not like to have their payments to be easily tracked, and by generating new addresses for each deposit, a service will appease the privacy minded and could gain more business.

It is a bit odd. Bitcoin Forum has a field for "Bitcoin Address". I don't actually have a "Bitcoin Address", do I?

The Bitcoin Address field is a place for you to advertise your bitcoin address.

Makes me wonder. In general, if I want anonymity, there is no way for me to advertise an address of mine. I know that sounds obvious, but if I wanted to receive payments, someone would have to goto my site and ask me for one.

It is still possible to maintain anonymity even with advertising an address. You could send the Bitcoin received by that address to a mixer or use any other method of mixing and anonymizing Bitcoin. It will prevent others from knowing what your other addresses are.

[loquitus_of_borg]

Even with a mixer, the bitcoin address that the payment was sent to is still fixed. If it is for a porn site, now everyone knows what BTC addresses have made payments to a porn site. They may not know what the porn site did with the proceeds, but in this context, how important is that?