Pages:
Author

Topic: How to receive bitcoin in one wallet but somehow know who sent it? - page 2. (Read 2065 times)

member
Activity: 64
Merit: 20
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.
legendary
Activity: 3472
Merit: 4801
- 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.
newbie
Activity: 50
Merit: 0
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?
Pages:
Jump to: