discover sender's address

[mike80439]

I'm using bitcoinj to develop a new app.  Presently I'm using testnet3. 

When I send a transaction from address <a> to address <b>, I get the WalletEventListener callback that a transaction has arrived.

My problem is that nowhere in the transaction do I see address <a> (which the app needs to adjust account balances). 

Is there a method to discover the original sender's address from the received transaction?

Thx

[1715068205]

1715068205

[1715068205]

1715068205

[1715068205]

1715068205

[1715068205]

1715068205

[1715068205]

1715068205

[1715068205]

1715068205

[DeathAndTaxes]

There is no such thing as the sender's address.  Transactions consist of multiple inputs and multiple outputs.

In Bitcoinj the transaction class contains an array of inputs.  You an iterate the inputs to get the adresses they were from.

Do understand this is bad practice.  If the user is sending from a web wallet, an exchange, a mining pool, a mixer service, or anywhere where they don't have control over the underlying wallet the addresses where the inputs originate from isn't guaranteed to represent the user. 

A much better solution is to simply give every user a unique address.  If user A is assigned bitcoin address 123456 then when you receive a tx sent to bitcoin address 123456 you simply credit account A.

[odolvlobo]

The source of the money in a transaction can be found by looking at the outputs of the input transactions (the indexes tells you which ones).

But as D&T wrote, this is not really what you want. The simple fact that a transaction can have (and generally does have) several inputs is an obvious impediment. Mainly though, the concept of a "sender's address" is wrong. A wallet is collection of addresses. When someone sends you money from their wallet, it will come from one or more of these addresses.

In short, you can't know who sent you money by looking at the sending address(es).

[mike80439]

OK, I understand that.  What does the average merchant do when he needs to send "change" to the customer?  Maybe several hours after the original transaction?

And thank you very much for the hand holding.

[DeathAndTaxes]

One options is to ask for a refund address.  How this is done can vary depending on the circumstances.

For example is the user has an account the user could set a refund address (i.e. all refunds go HERE).  On a per tx basis is refunds are likely then a refund could be asked at the time of the transaction (before use is given the unique single use "deposit/payment" address).  For most merchants where refunds are unlikely (say less than 1% of all txs are refunded) the merchant could simply ask the user if/when the order is cancelled and needs to be refunded.

Tangible Cryptography uses the second option.  As part of the order process the user is required to provide a valid (checking using Bitcoin validaiton rules) refund address. 

[mike80439]

Would there be a way for, say, a website to be able to generate fresh addresses (public key hashes) for each transaction without the website having access to the the private keys?

[hackjealousy]

Would there be a way for, say, a website to be able to generate fresh addresses (public key hashes) for each transaction without the website having access to the the private keys?

A secret key, k, is a 256-bit number and the corresponding public key is kG, where G is the generator of our elliptic curve group.

If you want a website to generate an address to receive funds, use a PRNG that seeds itself with a (unique) transaction number and a (global) secret known to the webserver and the back-end wallet.  This PRNG will generate a (probably) unique random number r.  Take r and construct a new public key kG + rG = (k + r)G.  You can now construct a Bitcoin address that is (probably) unique to this transaction by taking the correct hash of the public key (k + r)G.

This is secure.  The webserver knows kG and r, but not k.  Because of the properties of elliptic curves, we can't figure out k given kG and (k + r)G.  Therefore the webserver does not have access to the funds in (k + r)G.

The back-end wallet knows k and the global secret.  Thus, if you give the back-end wallet the (unique) transaction number, it can re-construct r.  This gives the back-end wallet both k and r, thus k + r, and hence the secret key for the public key (k + r)G.

This is the math behind your question anyway.  There is existing code out there that already does (essentially) this.  In general, this type of thing will be made easier when BIP0032, Hierarchical Deterministic Wallets, is implemented.

[mike80439]

Can you point me to the existing code?

Thanks

[koin]

Is there a method to discover the original sender's address from the received transaction?

another dice app?  roulette maybe?

ughhh.

[mike80439]

Would there be a way for, say, a website to be able to generate fresh addresses (public key hashes) for each transaction without the website having access to the the private keys?

A secret key, k, is a 256-bit number and the corresponding public key is kG, where G is the generator of our elliptic curve group.

If you want a website to generate an address to receive funds, use a PRNG that seeds itself with a (unique) transaction number and a (global) secret known to the webserver and the back-end wallet.  This PRNG will generate a (probably) unique random number r.  Take r and construct a new public key kG + rG = (k + r)G.  You can now construct a Bitcoin address that is (probably) unique to this transaction by taking the correct hash of the public key (k + r)G.

This is secure.  The webserver knows kG and r, but not k.  Because of the properties of elliptic curves, we can't figure out k given kG and (k + r)G.  Therefore the webserver does not have access to the funds in (k + r)G.

The back-end wallet knows k and the global secret.  Thus, if you give the back-end wallet the (unique) transaction number, it can re-construct r.  This gives the back-end wallet both k and r, thus k + r, and hence the secret key for the public key (k + r)G.

This is the math behind your question anyway.  There is existing code out there that already does (essentially) this.  In general, this type of thing will be made easier when BIP0032, Hierarchical Deterministic Wallets, is implemented.

Could you explain how to construct the new public key kG + rG = (k + r)G?  kG and rG are (x,y) points on the curve--how does one "add" them to produce a meaningful value?.

[hackjealousy]

A secret key, k, is a 256-bit number and the corresponding public key is kG, where G is the generator of our elliptic curve group.

Could you explain how to construct the new public key kG + rG = (k + r)G?  kG and rG are (x,y) points on the curve--how does one "add" them to produce a meaningful value?.

This is a very good question.  In fact, this question goes to the central idea behind elliptic-curve cryptography: how do you put a group structure on a curve?  However, there are far better explanations of elliptic-curve groups than I could give already out on the net.  Just Google "how do elliptic curve groups work?" and I'm sure you'll find a number of excellent answers.

If you'd like examples in code, the Bitcoin Armory client and the vanity address generator are good sources.  (Or at least ones I've used before and the first that come to mind.)