How to Identify bitcoin sender?

[mnemonix]

Hi,

Assuming something like e**Y. Peter buys something for an amount of 100BTC and has to send Fritz money. How can Fritz distinguish Peter's payment from other payments?

Code:

    (10BTC) IN1-|------------|
    (20BTC) IN2-|            |
    (5BTC)  IN3-|      TX    |-OUT1 (100BTC)
    (35BTC) IN4-|            |-OUT2 (5BTC Change)
    (35BTC) IN5-|------------|

Peter could tell Fritz his bitcoin-addr he will use, but it is very likely that Peter won't even know his own address which will be used for the transfer, because the bitcoin client may combine coins from 5 or 10 or more different addresses out of Peter's wallet.

How can Fritz be certain of receiving coins from Peter?

Another difficulty ... Assume there is a 3rd party which is monitoring the transfer (e.g. like e**Y which can acknowledge, the transfer has been completed like p*yp*l instant payment notification)-

How could the system be sure that Peter transfered all coins to Fritz?

I would very appreciate any help I can get on this ...

All the best,
Thomas

[1715094912]

1715094912

[1715094912]

1715094912

[1715094912]

1715094912

[1715094912]

1715094912

[Caesium]

Simple - generate a new receiving address for every transaction and give the new one to each new person you deal with.

[JoelKatz]

Simple - generate a new receiving address for every transaction and give the new one to each new person you deal with.

Exactly.

1) The recipient creates a new address.
2) The recipient posts that address in a way that it is archived by the 3rd party and passed to the sender.
3) The sender sends bitcoins to that address.
4) The 3rd party now knows the sender has paid the recipient.

[mnemonix]

Thank you for your replies ...

Wow, what a waste of addresses

Does someone know an estimation of the number of all transfers in $ ever? I hope it is far away from 2^160

But you are right ... This seems to be the way ... Generating a private address only the buyer can know ...

Thank you!

Best regards,
Thomas

[Yatta99]

This could also be done with the sender using two wallets (two different instances of the bitcoin app). Wallet1 is the receiving wallet from all sources with a number of different receiving addresses. You then send the aggregate amount to a single address in Wallet2. Then you send from Wallet2 to pay with a known sending address. The only catch being that you need to do the transfer sufficiently ahead of time to have enough verifications in the block chain for the coins in Wallet2.

Your example would change to:

Code:

    (10BTC) IN1-|------------|
    (20BTC) IN2-|            |
    (5BTC)  IN3-|      TX    |-OUT (105BTC) to Wallet2 address ----> payment from Wallet2 address ----> recipients wallet
    (35BTC) IN4-|            |
    (35BTC) IN5-|------------|

[w1R903]

Just think of the addresses as invoice numbers.

[Regulus]

I'm in the process of building a service for sales tracking where you enter in multiple addresses and then when someone fills out one of your order forms it will let you know to "watch for payment at _____" whatever the address is. Many of the features required to launch the site are already implemented and there's just a few more things that I need to do. Feel free to sign up for an account and play around or use the combination of TestUser2011 / password7: http://bitcoinevolution.com.

[kjj]

Thank you for your replies ...

Wow, what a waste of addresses

Does someone know an estimation of the number of all transfers in $ ever? I hope it is far away from 2^160

But you are right ... This seems to be the way ... Generating a private address only the buyer can know ...

Wasting addresses is a good security measure.  A lot of cryptosystems attacks involve comparing multiple outputs from the same key and calculating portions of the key from properties in the repeated outputs.  Historically, I think Enigma was first broken this way.

Generating a new address each and every time reduces the chances of an attack like that being possible, assuming that weaknesses of that sort are someday found in SHA256 and RIPE-MD160.

Oh, and if we assume 100,000,000,000 people in the world, and each of them doing 10,000 transactions each day, it will take 3.8*10^30 years to run out of addresses.  The first address collision will, of course, come a bit sooner than that.  For comparison, the current age of the universe is generally thought to be around 1.3*10^10 years.

[beckspace]

Oh, and if we assume 100,000,000,000 people in the world, and each of them doing 10,000 transactions each day, it will take 3.8*10^30 years to run out of addresses.  The first address collision will, of course, come a bit sooner than that.  For comparison, the current age of the universe is generally thought to be around 1.3*10^10 years.

That's good info. I was looking for this math. The system seems really robust.


We'll have reached Civilization Type 3 by the time we run out of addresses.