<p>There is nothing messy or difficult to keep track of about generating a new address for each transaction. Generating an address is a very cheap operation and you can generate thousands of them in advance if you want. The way Bitcoin is designed, there is no different between using the same address for multiple transactions or using a new address for each transaction. It makes no difference to the system at all.</p>

<p>That said, I think the Bitcoin system should have permitted you to put an identifier in the transaction. 16-bits would have been sufficient.</p>

CC BY-SA 3.0
2012-03-19T10:44:35.817Z
Cannot you put some custom identifier data (that makes sense only to sender and recipient) into the script part of the transaction (if you really feel you need that)?
Thilo
CC BY-SA 3.0
2012-03-19T11:53:37.843Z
There is no need to do that: the only data that belongs in a transaction is what is necessary for the world to verify its integrity. In most cases, you are already communicating with the sender by other means (website, e-mail, IM, ...), so why not send the identification there? Sure we need infrastructure to make this user-friendly, but one can send a signed message "please accept bitcoin tx 012d34sf56a as payment for order 12345".
Pieter Wuille
CC BY-SA 3.0
2012-03-19T15:18:44.603Z
@PieterWuille: The problem with "please accept bitcoin tx X as payment for order Y" is that the transaction information is public. What happens if you receive one of those, ship the order, and then receive another one? The merchant pretty much has to give the buyer some information that the buyer incorporates in the transaction. Right now, that can only be the receiving account. But if you could put the order number in the transaction, you could re-use accounts more easily.
David Schwartz
CC BY-SA 3.0
2012-03-19T19:01:23.433Z
What do you mean by "then receive another", and why would it be a problem?
Pieter Wuille
CC BY-SA 3.0
2012-03-19T19:09:42.787Z
@PieterWuille: You receive a message saying that transaction X was payment for order Y. You ship the order. Then you receive another such message saying that transaction X was payment for order Z. What do you do? The transaction information is public, how do you securely map it to an order?
David Schwartz
CC BY-SA 3.0
2012-03-19T21:24:34.023Z
There's two options really: a) sign it using a private key the transaction was sent with (which was what i intended above, but that requires control of the private key, and is not necessarily possible in case of an e-wallet), b) my favorite: send the transaction to the merchant directly (no one else in the world cares about getting it accepted anyway).
Pieter Wuille
CC BY-SA 3.0
2012-03-19T21:27:13.473Z
@PieterWuille: I don't see how either way works. Either of those ways still has the problem that two people (or one person, sending twice) might send you the same transaction claiming it pays different orders. How does either method ensure a transaction maps to one and only one order? Putting the order ID in the transaction clearly does this. And using an account for only one order clearly does this. I don't see how your two methods do this.
David Schwartz
CC BY-SA 3.0
2012-03-20T00:26:10.203Z
Not sure why that is a problem; just only accept the first one. Either way it requires consent from the one actually creating the transaction; it's not something that can happen by accident.
Pieter Wuille
CC BY-SA 3.0
2012-03-20T00:29:46.057Z
let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/2841/discussion-between-david-schwartz-and-pieter-wuille)
David Schwartz
CC BY-SA 3.0
2012-03-18T23:17:17.280Z
2012-03-18T23:17:17.280Z
David Schwartz
<p>Is the sender's address the only way to identify the seller?</p>

<p>I don't see how this would work for a large websites that accept bitcoins. Since all of the transactions are visible, anyone can claim address x is theirs and that they sent the payment. </p>

<p>I guess the only way would be to generate a new address for each transaction? Seems messy and hard to keep track of things.</p>

<p>Also, I though I'd add another question since I mentioned large websites. Would it be possible to automatically notify the server when a payment arrives? I'm talking about something like paypal's IPN system. So that everything would be automated. If the person buys a subscription for example, then upon payment confirmation it gets activated automatically.</p>

CC BY-SA 3.0
2012-10-17T22:15:26.793Z
possible duplicate of [How to findout the sender of a transaction](http://bitcoin.stackexchange.com/questions/3896/how-to-findout-the-sender-of-a-transaction)
Stephen Gornick
<transactions>
Identifying sender
domino
# Identifying sender

(Asked by: username_0 on 2012-03-18)

Is the sender's address the only way to identify the seller?

I don't see how this would work for a large websites that accept bitcoins. Since all of the transactions are visible, anyone can claim address x is theirs and that they sent the payment.

I guess the only way would be to generate a new address for each transaction? Seems messy and hard to keep track of things.

Also, I though I'd add another question since I mentioned large websites. Would it be possible to automatically notify the server when a payment arrives? I'm talking about something like paypal's IPN system. So that everything would be automated. If the person buys a subscription for example, then upon payment confirmation it gets activated automatically.

**Tags:** transactions

> **Comments:**
> **username_1**: possible duplicate of [How to findout the sender of a transaction](http://bitcoin.stackexchange.com/questions/3896/how-to-findout-the-sender-of-a-transaction)  

---

## 1 answers

### Answer by username_2 on 2012-03-18. Score: 3 | Accepted answer

There is nothing messy or difficult to keep track of about generating a new address for each transaction. Generating an address is a very cheap operation and you can generate thousands of them in advance if you want. The way Bitcoin is designed, there is no different between using the same address for multiple transactions or using a new address for each transaction. It makes no difference to the system at all.

That said, I think the Bitcoin system should have permitted you to put an identifier in the transaction. 16-bits would have been sufficient.

> **Comments:**
> **username_3**: Cannot you put some custom identifier data (that makes sense only to sender and recipient) into the script part of the transaction (if you really feel you need that)?  
> **username_4**: There is no need to do that: the only data that belongs in a transaction is what is necessary for the world to verify its integrity. In most cases, you are already communicating with the sender by other means (website, e-mail, IM, ...), so why not send the identification there? Sure we need infrastructure to make this user-friendly, but one can send a signed message "please accept bitcoin tx 012d34sf56a as payment for order 12345".  
> **username_2**: @username_4: The problem with "please accept bitcoin tx X as payment for order Y" is that the transaction information is public. What happens if you receive one of those, ship the order, and then receive another one? The merchant pretty much has to give the buyer some information that the buyer incorporates in the transaction. Right now, that can only be the receiving account. But if you could put the order number in the transaction, you could re-use accounts more easily.  
> **username_4**: What do you mean by "then receive another", and why would it be a problem?  
> **username_2**: @username_4: You receive a message saying that transaction X was payment for order Y. You ship the order. Then you receive another such message saying that transaction X was payment for order Z. What do you do? The transaction information is public, how do you securely map it to an order?  
> **username_4**: There's two options really: a) sign it using a private key the transaction was sent with (which was what i intended above, but that requires control of the private key, and is not necessarily possible in case of an e-wallet), b) my favorite: send the transaction to the merchant directly (no one else in the world cares about getting it accepted anyway).  
> **username_2**: @username_4: I don't see how either way works. Either of those ways still has the problem that two people (or one person, sending twice) might send you the same transaction claiming it pays different orders. How does either method ensure a transaction maps to one and only one order? Putting the order ID in the transaction clearly does this. And using an account for only one order clearly does this. I don't see how your two methods do this.  
> **username_4**: Not sure why that is a problem; just only accept the first one. Either way it requires consent from the one actually creating the transaction; it's not something that can happen by accident.  
> **username_2**: let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/2841/discussion-between-username_2-username_2-and-username_4-username_4)  

---

