<blockquote>
  <p>Surely the address must exist first before the raw block can allocate the mined coins to it?</p>
</blockquote>

<p>No. The network has no concept of addresses. When you send money, you're actually sending funds to a public key or public key hash. The Bitcoin address format you're familiar with is just a way of representing public key hashes in a human-readable way.</p>

<p>This is especially true of generation transactions, which typically send money directly to a public key. Bitcoin-Qt normally doesn't calculate or display the address in such cases, though it's still possible to calculate it.</p>

<p>The "coinbase" doesn't contain the address or public key. That's just mostly-arbitrary data. It contains the block height, extraNonce, etc. The address is in "scriptPubKey". In the genesis block's generation transaction, the scriptPubKey is:</p>

<pre><code>04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG
</code></pre>

<p>This is a direct-to-public-key transaction, not a normal address transaction. 04678... is the uncompressed ECDSA public key. Follow the instructions on that wiki page to get the address, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. But again, this transaction doesn't contain this address, or even its base58-decoded (binary) equivalent. The address is just a way of representing the public key.</p>

CC BY-SA 3.0
2013-10-30T00:43:11.997Z
Small nit: signatures are encoded using DER, but public keys aren't. The standard for encoding public keys is described by SEC1 (http://www.secg.org/index.php?action=secg,docs_secg).
Pieter Wuille
CC BY-SA 3.0
2013-10-30T00:44:34.770Z
Another nit: from the point of view of the network rules, the output of the genesis block is actually unspendable (intentionally or due to a bug), so its address is really irrelevant.
Pieter Wuille
CC BY-SA 3.0
2013-10-30T01:00:45.543Z
@PieterWuille I fixed the DER bit, thanks. Even though the genesis transaction is unspendable, I think that its address is not totally irrelevant. For example, you can use it to easily see that people have sent BTC to the public key listed by Satoshi in the genesis transaction. This is interesting info.
theymos
CC BY-SA 3.0
2013-10-30T11:12:02.923Z
i don't think my question "Surely the address must exist first before the raw block can allocate the mined coins to it?" was clearly phrased, so i have updated it to explain better what i mean.
mulllhausen
CC BY-SA 3.0
2013-10-30T11:21:19.653Z
The payout address is indeed known before block mining begins, by the way.
Pieter Wuille
CC BY-SA 3.0
2013-10-30T13:27:38.527Z
yeah, that's what i meant.
mulllhausen
CC BY-SA 3.0
2013-10-30T00:31:10.027Z
2013-10-30T00:58:49.613Z
2013-10-30T00:58:49.613Z
theymos
<p>I'm just starting to write a bitcoin script parser and I am wondering how to get the address from the genesis block? <a href="http://blockexplorer.com/rawblock/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f" rel="nofollow">blockexplorer.com shows the coinbase value to be</a></p>

<blockquote>
  <p>04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73</p>
</blockquote>

<p>in the raw block data. But it also <a href="http://blockexplorer.com/b/0" rel="nofollow">shows the receiving address for this transaction to be</a></p>

<blockquote>
  <p>1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa</p>
</blockquote>

<p>How can I derive the address from the raw transaction? I found a <a href="https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses" rel="nofollow">page in the wiki</a> that talks about creating an address, but this seems like it is going about the process in a back-to-front order. Surely the address must exist first before the raw block can allocate the mined coins to it? Otherwise, the blockchain would simply have to allocate mined funds into the ether. The receiving address must have been known to the mining algorithm before it generated the very first mining transaction.</p>

<p>Please could someone walk me through the steps of deriving the address from the raw transaction script.</p>

<address>
Deriving the Bitcoin address from the raw block script
mulllhausen
# Deriving the Bitcoin address from the raw block script

(Asked by: username_0 on 2013-10-29)

I'm just starting to write a bitcoin script parser and I am wondering how to get the address from the genesis block? [blockexplorer.com shows the coinbase value to be](http://blockexplorer.com/rawblock/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f)

> 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

in the raw block data. But it also [shows the receiving address for this transaction to be](http://blockexplorer.com/b/0)

> 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa

How can I derive the address from the raw transaction? I found a [page in the wiki](https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses) that talks about creating an address, but this seems like it is going about the process in a back-to-front order. Surely the address must exist first before the raw block can allocate the mined coins to it? Otherwise, the blockchain would simply have to allocate mined funds into the ether. The receiving address must have been known to the mining algorithm before it generated the very first mining transaction.

Please could someone walk me through the steps of deriving the address from the raw transaction script.

**Tags:** address


---

## 1 answers

### Answer by username_1 on 2013-10-30. Score: 2 | Accepted answer

Surely the address must exist first before the raw block can allocate the mined coins to it?

No. The network has no concept of addresses. When you send money, you're actually sending funds to a public key or public key hash. The Bitcoin address format you're familiar with is just a way of representing public key hashes in a human-readable way.
This is especially true of generation transactions, which typically send money directly to a public key. Bitcoin-Qt normally doesn't calculate or display the address in such cases, though it's still possible to calculate it.
The "coinbase" doesn't contain the address or public key. That's just mostly-arbitrary data. It contains the block height, extraNonce, etc. The address is in "scriptPubKey". In the genesis block's generation transaction, the scriptPubKey is:
04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG

This is a direct-to-public-key transaction, not a normal address transaction. 04678... is the uncompressed ECDSA public key. Follow the instructions on that wiki page to get the address, 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. But again, this transaction doesn't contain this address, or even its base58-decoded (binary) equivalent. The address is just a way of representing the public key.

> **Comments:**
> **username_2**: Small nit: signatures are encoded using DER, but public keys aren't. The standard for encoding public keys is described by SEC1 (http://www.secg.org/index.php?action=secg,docs_secg).  
> **username_2**: Another nit: from the point of view of the network rules, the output of the genesis block is actually unspendable (intentionally or due to a bug), so its address is really irrelevant.  
> **username_1**: @PieterWuille I fixed the DER bit, thanks. Even though the genesis transaction is unspendable, I think that its address is not totally irrelevant. For example, you can use it to easily see that people have sent BTC to the public key listed by Satoshi in the genesis transaction. This is interesting info.  
> **username_0**: i don't think my question "Surely the address must exist first before the raw block can allocate the mined coins to it?" was clearly phrased, so i have updated it to explain better what i mean.  
> **username_2**: The payout address is indeed known before block mining begins, by the way.  
> **username_0**: yeah, that's what i meant.  

---

