<p>I was intending to answer <a href="https://bitcoin.stackexchange.com/q/8852/120">another question</a>, which was closed as a duplicate in the meantime, but I will use the case that was described there as an example to answer this question.</p>

<p>Assuming <a href="https://blockchain.info/tx-index/63705791" rel="nofollow noreferrer">the transaction</a> is in fact a standard transaction, the script does in fact reveal the sender of the transaction. According to the standard transaction description in the <a href="https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address" rel="nofollow noreferrer">protocol specification</a> the transaction has to first prove ownership of an output in order to claim it and spend it in the new transaction. The <a href="https://blockchain.info/tx/f8c71a9f7ef2d4a5dd118691885f9835bcce2aa00a594f21a8af9ecc235f4b29" rel="nofollow noreferrer">transaction that gave the sender the funds</a> specifies the hash of a public key to which to send the funds. In this case it's the output script 1 of transaction <code>f8c71a9f7...</code>:</p>

<pre><code>OP_DUP OP_HASH160 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7 OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>Notice the <code>496650cdb4b6275ca4478c0ce98cb6f7224bb1e7</code> in there. That is the hash of the public key. To claim this output, and then send it to you, the sender has to provide both the public key and a valid signature. So let's take a look at the script that claimed this output:</p>

<pre><code>304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb
</code></pre>

<p>This being a standard transaction it will conform to the format <code>&lt;sig&gt; &lt;pubKey&gt;</code>, so the public key is <code>0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb</code>. To verify this we check an see if the hashes match (python code ahead):</p>

<pre><code>script = "304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb".split()
h = hashlib.sha256(script[1].decode("hex")).digest()
ripe160 =  hashlib.new('ripemd160')
ripe160.update(h)
d = ripe160.digest()
print d.encode("hex")
</code></pre>

<p>This should result in <code>496650cdb4b6275ca4478c0ce98cb6f7224bb1e7</code>, which is the hash we have seen in the output script of the claimed out that was finally sent to you. Notice that to calculate this we did not have to fetch the transaction <code>f8c71a9f7...</code> but merely relied on information you could get from the transaction that you received. Now since an address is not much more than the hash of a public key we can simply build an address from the information we have gathered so far (having the hash already we start from step 4 in the <a href="https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses" rel="nofollow noreferrer">address construction</a>):</p>

<pre><code>#Prepend the Mainnet prefix
address = ('\x00' + d)
#Calculate checksum
checksum = hashlib.sha256(hashlib.sha256(address).digest()).digest()[:4]
# Build the raw address
address += checksum
# Encode the address in base58
encoded_address = b58encode(address)
print encoded_address
</code></pre>

<p>The encoding can be done with any base58 encoder, I used <a href="https://github.com/jtobey/bitcoin-abe/blob/master/Abe/base58.py" rel="nofollow noreferrer">this</a>. This should print out the address <code>17h6u26N2TVmoPRcvxwUdfAUjDzBJX513V</code> which is the address that sent the bitcoins in the transaction that we were looking at all the time. So you see, the information you were looking for was in the transaction all along, but quite hidden. So given an incoming transaction (or an outgoing as a matter of fact) you can reconstruct who the sender (or receiver) was. Notice that this allows you to reconstruct the sender of each individual input, which might be multiple addresses. Simply assuming that any of the addresses signing the inputs is the sender of the transaction may or may not lead to the desired semantic result.</p>

CC BY-SA 3.0
2013-03-30T11:46:53.537Z
2013-03-30T11:46:53.537Z
2017-04-13T12:47:36.647Z
cdecker
<p>I think it's because of the intended security model - you generate an address for a customer, who sends bitcoins to it.</p>

<p>Allowing people to figure out the sending address might cause people to create one bitcoin address, then ask customers to enter their sending address.</p>

<p>As for how...</p>

<p>I found these three threads:</p>

<ul>
<li><a href="https://bitcointalk.org/index.php?topic=4220.0" rel="nofollow">How do I know who paid me?</a></li>
<li><a href="https://bitcointalk.org/index.php?topic=4140.0" rel="nofollow">Bitcoin "From" address, can i change it?</a></li>
<li><a href="https://bitcointalk.org/index.php?topic=4561.0" rel="nofollow">Question abount getting the sender's address in a transaction</a></li>
</ul>

CC BY-SA 3.0
2013-02-21T19:03:54.807Z
I don't get it: if I enter the txid into blockchain.info it tells me the sender address, since it obviously is present in the blockchain... so it's just a choice of `bitcoind` not to tell me?
o0'.
CC BY-SA 3.0
2013-03-30T00:45:58.567Z
It is not a choice: Bitcoin transactions do not *have* a "from" address. What they do have is inputs, and each input refers to an output of a previous transaction. Each of these previous outputs may or may not have an identifiable address it sent things to. It would be both inefficient to look it up, and incorrect to rely on it. It gives you an address owned by someone who previously controlled those outputs (which may be different from the sender, e.g. for e-wallets), and who may not intend to receive anything there.
Pieter Wuille
CC BY-SA 3.0
2013-03-30T00:54:56.947Z
@PieterWuille I don't follow: how does blockchain.info tells me the input address, how much is that precise? (sending back anything there is out of the scope of the question)
o0'.
CC BY-SA 3.0
2013-03-30T00:59:43.563Z
They give you the address (if any) the consumed previous outputs belonged to. This is not part of the transaction itself, and finding out requires looking up all previous transactions whose outputs were spent by this one. It's certainly doable, but it's inefficient, it's not part of the transaction you're looking up (which is what getrawtransaction fetches), and it reinforces the incorrect notion of that Bitcoin transactions have a from address.
Pieter Wuille
CC BY-SA 3.0
2013-02-21T18:34:34.167Z
2013-02-21T18:34:34.167Z
Nick ODell
<p>Both on "send" and "receive" transactions, the command <code>gettransaction</code> gives me the account name, and the receiving address, ignoring the send address. Why should I care about <em>receiving</em> address in a "receive" transaction? I want to know the <em>send</em> address, of course...</p>

<ul>
<li>"receive" --> send address, receive account</li>
<li>"send" --> send account, receive address</li>
</ul>

<p>Why doesn't it work this way, <strong>what am I missing</strong>, and how can I get the send address in a receive transaction?</p>

<p><strong>edit</strong>: I'd like to stress out the question about <em>why</em> it behaves this way? as in this comment "I don't get it: if I enter the txid into blockchain.info it tells me the sender address, since it obviously is present in the blockchain... so it's just a choice of <code>bitcoind</code> not to tell me?"</p>

<p><strong>edit</strong>: sending back anything to the from address is totally out of the scope of the question, so it is irrelevant if they might not wish receiving anything there.</p>

<bitcoind><bitcoin-core-accounts><gettransaction>
Why does gettransaction report me only the receiving address?
o0'.
# Why does gettransaction report me only the receiving address?

(Asked by: username_0 on 2013-02-21)

Both on "send" and "receive" transactions, the command `gettransaction` gives me the account name, and the receiving address, ignoring the send address. Why should I care about *receiving* address in a "receive" transaction? I want to know the *send* address, of course...

* "receive" --> send address, receive account
* "send" --> send account, receive address

Why doesn't it work this way, **what am I missing**, and how can I get the send address in a receive transaction?

**edit**: I'd like to stress out the question about *why* it behaves this way? as in this comment "I don't get it: if I enter the txid into blockchain.info it tells me the sender address, since it obviously is present in the blockchain... so it's just a choice of `bitcoind` not to tell me?"

**edit**: sending back anything to the from address is totally out of the scope of the question, so it is irrelevant if they might not wish receiving anything there.

**Tags:** bitcoind, bitcoin-core-accounts, gettransaction


---

## 2 answers

### Answer by username_1 on 2013-03-30. Score: 10

I was intending to answer [another question](https://bitcoin.stackexchange.com/q/8852/120), which was closed as a duplicate in the meantime, but I will use the case that was described there as an example to answer this question.

Assuming [the transaction](https://blockchain.info/tx-index/63705791) is in fact a standard transaction, the script does in fact reveal the sender of the transaction. According to the standard transaction description in the [protocol specification](https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address) the transaction has to first prove ownership of an output in order to claim it and spend it in the new transaction. The [transaction that gave the sender the funds](https://blockchain.info/tx/f8c71a9f7ef2d4a5dd118691885f9835bcce2aa00a594f21a8af9ecc235f4b29) specifies the hash of a public key to which to send the funds. In this case it's the output script 1 of transaction `f8c71a9f7...`:

```
OP_DUP OP_HASH160 496650cdb4b6275ca4478c0ce98cb6f7224bb1e7 OP_EQUALVERIFY OP_CHECKSIG

```

Notice the `496650cdb4b6275ca4478c0ce98cb6f7224bb1e7` in there. That is the hash of the public key. To claim this output, and then send it to you, the sender has to provide both the public key and a valid signature. So let's take a look at the script that claimed this output:

```
304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb

```

This being a standard transaction it will conform to the format `<sig> <pubKey>`, so the public key is `0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb`. To verify this we check an see if the hashes match (python code ahead):

```
script = "304402205e81e8ed0b1f7cf6d1d415961859d3b95f5e5c353af303b6cef1e3efa6c3349702202fa9fdd6914abd0e9606c78899e7f3010cafdad211645cf459ae18b3b827b2c101 0365e0beb9a0c1497f3667067aeb8f3ea9dc4c9d5696cee7f19eae49f9457a5cfb".split()
h = hashlib.sha256(script[1].decode("hex")).digest()
ripe160 =  hashlib.new('ripemd160')
ripe160.update(h)
d = ripe160.digest()
print d.encode("hex")

```

This should result in `496650cdb4b6275ca4478c0ce98cb6f7224bb1e7`, which is the hash we have seen in the output script of the claimed out that was finally sent to you. Notice that to calculate this we did not have to fetch the transaction `f8c71a9f7...` but merely relied on information you could get from the transaction that you received. Now since an address is not much more than the hash of a public key we can simply build an address from the information we have gathered so far (having the hash already we start from step 4 in the [address construction](https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses)):

```
#Prepend the Mainnet prefix
address = ('\x00' + d)
#Calculate checksum
checksum = hashlib.sha256(hashlib.sha256(address).digest()).digest()[:4]
# Build the raw address
address += checksum
# Encode the address in base58
encoded_address = b58encode(address)
print encoded_address

```

The encoding can be done with any base58 encoder, I used [this](https://github.com/jtobey/bitcoin-abe/blob/master/Abe/base58.py). This should print out the address `17h6u26N2TVmoPRcvxwUdfAUjDzBJX513V` which is the address that sent the bitcoins in the transaction that we were looking at all the time. So you see, the information you were looking for was in the transaction all along, but quite hidden. So given an incoming transaction (or an outgoing as a matter of fact) you can reconstruct who the sender (or receiver) was. Notice that this allows you to reconstruct the sender of each individual input, which might be multiple addresses. Simply assuming that any of the addresses signing the inputs is the sender of the transaction may or may not lead to the desired semantic result.


---

### Answer by username_2 on 2013-02-21. Score: 1

I think it's because of the intended security model - you generate an address for a customer, who sends bitcoins to it.

Allowing people to figure out the sending address might cause people to create one bitcoin address, then ask customers to enter their sending address.

As for how...

I found these three threads:

* [How do I know who paid me?](https://bitcointalk.org/index.php?topic=4220.0)
* [Bitcoin "From" address, can i change it?](https://bitcointalk.org/index.php?topic=4140.0)
* [Question abount getting the sender's address in a transaction](https://bitcointalk.org/index.php?topic=4561.0)

> **Comments:**
> **username_0**: I don't get it: if I enter the txid into blockchain.info it tells me the sender address, since it obviously is present in the blockchain... so it's just a choice of `bitcoind` not to tell me?  
> **username_3**: It is not a choice: Bitcoin transactions do not *have* a "from" address. What they do have is inputs, and each input refers to an output of a previous transaction. Each of these previous outputs may or may not have an identifiable address it sent things to. It would be both inefficient to look it up, and incorrect to rely on it. It gives you an address owned by someone who previously controlled those outputs (which may be different from the sender, e.g. for e-wallets), and who may not intend to receive anything there.  
> **username_0**: @username_3 I don't follow: how does blockchain.info tells me the input address, how much is that precise? (sending back anything there is out of the scope of the question)  
> **username_3**: They give you the address (if any) the consumed previous outputs belonged to. This is not part of the transaction itself, and finding out requires looking up all previous transactions whose outputs were spent by this one. It's certainly doable, but it's inefficient, it's not part of the transaction you're looking up (which is what getrawtransaction fetches), and it reinforces the incorrect notion of that Bitcoin transactions have a from address.  

---

