<p>You can derive the address from the output script in the raw transaction.</p>
<p>Transaction outputs contain two fields, an 8-byte signed integer <code>amount</code> and the output script of variable length (also called <code>scriptPubKey</code> in the Bitcoin Core codebase). As the name suggests, the output script contains Script instructions or one of the standard templates that imply a set of Script instructions. Whenever a transaction is confirmed in the best chain, the assigned <code>amount</code> of funds get encumbered by the spending conditions defined per the output script.</p>
<p>We use addresses to represent certain standard output templates. An address encodes the output script in a form that is protected by a checksum and presented in a more human-consumable shape. In this specific case, we are looking at a native segwit v0 witness program with 32 bytes payload, or a <em>Pay to Witness Script Hash (P2WSH)</em> output.</p>
<p>The address is calculated from the output script by taking the human-readable part (“hrp”) and the data of the output script (witness version and witness program) to calculate a checksum. The address is then assembled by concatenating:</p>
<ul>
<li>the hrp <code>bc</code> for Bitcoin mainnet</li>
<li>the separator <code>1</code></li>
<li>the data encoded using bech32 (see table below)</li>
<li>the checksum encoded using bech32</li>
</ul>
<p><a href="https://i.sstatic.net/Ld59O.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Ld59O.png" alt="bech32 translation table via BIP173" /></a></p>
<p>Vice versa, a sender can decode the address they get from the receiver by checking the address string for validity, removing the checksum, and decoding the data part to extract the output script. Based on the version, they can check whether the witness program has the correct form (esp. length).</p>
<p>If you’re looking to implement bech32, I would suggest to check out one of the <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#reference-implementations" rel="nofollow noreferrer">eight reference implementations</a> and the <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#test-vectors" rel="nofollow noreferrer">test vectors</a> on the BIP. Note that addresses for native segwit version 1+ use the bech32m encoding defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP350</a> instead of bech32 (<a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a>). Although, the only difference is that bech32m modifies the checksum constant.</p>

CC BY-SA 4.0
2023-08-09T09:45:20.570Z
2023-10-22T12:07:05.230Z
2023-10-22T12:07:05.230Z
Murch
<blockquote>
<p><strong>How can clients know the destination address for this P2WPKH transaction?</strong></p>
</blockquote>
<p>Clients don't need to know the address.</p>
<p>Addresses are not used within the Bitcoin network protocol and are not present in transaction data.</p>
<p>Many explorers (perhaps almost all) and wallets (including Bitcoin core) invent things in an attempt to be helpful and present them as if they were present in transaction data when they were not. For example the output you used shows four different items under &quot;scriptPubKey&quot;. The reality is that these are four different interpretations of only one data item. A locking script. I find this ornamentation confusing. This is why I wrote my own blockchain data parser.</p>
<p>Addresses can be constructed for, or from, some, but not all, standard types of locking script. That includes P2WPKH.</p>
<p>See</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/113631/13866">In what format does a block store the transaction data?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/118839/13866">Is there authoritative documentation on how to generate a P2WPKH address?</a> where<br />
Vojtěch Strnad comments that the method of constructing an address is described in  BIP141 and <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a></li>
</ul>

CC BY-SA 4.0
2023-08-09T09:16:21.587Z
The output quoted by the asker looks like [output of Bitcoin Core](https://bitcoincore.org/en/doc/24.0.0/rpc/rawtransactions/decoderawtransaction/)
Murch
CC BY-SA 4.0
2023-08-09T09:22:23.770Z
@Murch: I have amended the answer to cover this.
RedGrittyBrick
CC BY-SA 4.0
2023-07-09T09:06:33.610Z
2023-08-09T09:23:53.267Z
2023-08-09T09:23:53.267Z
RedGrittyBrick
<p>The address is a representation of the scriptPubKey code, which in this case is (ASM) <code>0 c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb</code>.</p>
<p>This format (0 followed by &lt;32 bytes&gt;) indicates that this is a segwit transaction, which means the address should be encoded in bech32 format.</p>
<p>So it just needs to follow protocol to find the address: <a href="https://en.bitcoin.it/wiki/Bech32" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Bech32</a></p>

CC BY-SA 4.0
2023-07-10T06:41:28.717Z
2023-07-10T06:41:28.717Z
bordalix
<p>This is the raw hex of a random transaction I picked up on the blockchain:</p>
<pre><code>0100000000010b6872499a5059ce4a2d3344e868c7d7c40983dc75fbf365defa40f055260198c9020000000000000000f3652a79eff0f3b762941c0f31850df2babdd6f35c89e3fc9d53329ce80fd08e0000000000000000000b36c42304b8ad03fed7cac321be5618b3fd9736ad11fc85be37aa97259400c30c00000000000000002ad86fa960dcbc603337737a2f54ede1df5c1f9e1cefbe9bef556778a01a9e3e0a0000000000000000b09ae8dd51148c47d4961dbfdf6b02052c80b3d040175590d34010dbf2bfacd90100000000000000001f44687cee5ddf538932e7bdb135677040610e5bd1e0015de66143ba7f95d7d3000000000000000000437b7a76594dafe2121da3ac19b5bfb8b17513fd831a7c320b5a79cbd483e3030100000000000000005ce89e885618cd355329c0680e2dec4d5090b2423d56ca7aa420005ae2a7561b0000000000000000001efc73fa2fee9b3fcde1b5f9e31af6f94452b95ecb2e94482dcab6a7dc62ea88000000000000000000dab4b173e3ad183f7440bd1967193c99787e49b62b22461ab55b8f7cec8ea0c70100000000000000009c3d6027dc44d135edbcadb0fe5aff7871baecf93c867d591ae7c6894f9b6782010000000000000000013c22260700000000220020c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb024730440220266eafba397c9cee5f5849cfb50941e6bd4704634827181f89548d294e24a9760220721870edbc73cd9ed50bc22db1777f346073b0713e640fa1e80291c971371292012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b88657024730440220096a3e06a9947c49e0682d22c456befa4956f3b7cc18d4b13d55f9c371c35892022072ff49c4997068ff4dd3836cc4b53d3e6a4f06e40b73e84ad8c2bbd88c643447012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b8865702473044022012b34533bdb17b50836c29587327787ebd3b8b3e18fc5f3d7d4dc2c76a6ddf0302207486029cc8e78d30bfa05afff0464f917902532fc1225ef3c88ba3f8a13d5c08012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b886570247304402206f71783949cb212be9e29fae55d27d673880f8ea5fed49ae5c824136e095592c0220091e596ade1be1e25a9a8a3d2a04de079171963754e1fbd3ee2d201a442cc503012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b8865702483045022100feab4037ee830b170140767cac36d57a34cc937e5064fb7dd9a9765a2953126e02203dfed10b2706166fed3a2e72f52cd7364f908dad7ab963338c93a54237bbe1840121026398bf03486ebc2039872099240ea6894d31aa8d7b05694dd0da651e99995f9a02473044022000e69c0405f738efdec05bf8fc40b5d65cfa807f88ff6f2fdbb89d45b2223bc602205f4e124f70237e66f5eae3e02bd145b5ae18bba9e876460da92a68dc9cce42b7012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b886570247304402202fd326ad725ecf389de116737db35aa0e5de55fbc02aa50ae910cd1717d999bf0220427f208c230f6bf318ca11b59ab6cda07c4dc7841dc3c46553c697ac24b9844b012103a075642232f43dc8c894a7b278caf80048ff24acc6e501a6d0e00e6ad3bd0e8d02483045022100fa3880de255c2b46b3b5402b5a35dd7831d9437bcd2933ec30517205496c0ec602203460e1291853b8eff3dd8723c467e89dc33cbed02e7897e6c473a212775dedb5012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b88657024730440220710206efc837284fb5fbe925f336e0b158be10ed5828c7300a145089aa95f5360220669e7e28a24d4cbc6e42876d10b672b66b0a1d556bfdcca0a478884e3218ef4a0121025d98dfa4f2f0b79c1af74d4e75cd45e2894310f1837aae4a8e43d2e060322a3a02483045022100e1b3be88f937e6b52df5f0ff180c786bfbc28572a8c5124732f219613a59001d02202a82327a93bbdcb901370e11f2f3ddb6203410d9e0220e5c104ea682fa561292012102dade55e0270c11e7027b5288ed73c1e5c67e3e49ea9e8484c02dcf938be686fb0247304402200bc12ac9000471e79e0cc45803ea2fa32fd2ce4e2fee84836e97bbdea2fe2d96022040e81881402ae33642e728063b7b6f32856c00174788e90fc17a9a6bf2685a9d012103fd105fc6af5c4c76fd04fdb83cdb6951ecb6972210204fb98829425c49405bbe00000000
</code></pre>
<p>If I use <a href="https://explorer.btc.com/tools/tx/decode" rel="nofollow noreferrer">this tool</a> to decode the HEX, this is what I get:</p>
<pre><code>(...)
&quot;vout&quot;: [
        {
            &quot;value&quot;: 1.19939644,
            &quot;n&quot;: 0,
            &quot;scriptPubKey&quot;: {
                &quot;asm&quot;: &quot;0 c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb&quot;,
                &quot;hex&quot;: &quot;0020c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb&quot;,
                &quot;address&quot;: &quot;bc1qcf034mvwpcph7pq3l0cy9wtqqlj4ekyuc466mmle57hkfuks884szh3xxk&quot;,
                &quot;type&quot;: &quot;witness_v0_scripthash&quot;
            }
        }
    ]
}
</code></pre>
<p>How are they able to extract the destination address <code>bc1qcf034mvwpcph7pq3l0cy9wtqqlj4ekyuc466mmle57hkfuks884szh3xxk</code> from a P2WPKH (witness_v0_scripthash <code>OP_0 32 0x0020c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb</code>)?</p>
<p>Or they are getting it from somewhere else?</p>

CC BY-SA 4.0
2023-08-09T09:29:18.370Z
`witness_v0_scripthash` does not refer to P2WPKH but rather to P2WSH
Murch
<bech32-address><p2wpkh><output-script>
How can clients know the destination address for this P2WPKH transaction?
Pedro D.
# How can clients know the destination address for this P2WPKH transaction?

(Asked by: username_0 on 2023-07-09)

This is the raw hex of a random transaction I picked up on the blockchain:
0100000000010b6872499a5059ce4a2d3344e868c7d7c40983dc75fbf365defa40f055260198c9020000000000000000f3652a79eff0f3b762941c0f31850df2babdd6f35c89e3fc9d53329ce80fd08e0000000000000000000b36c42304b8ad03fed7cac321be5618b3fd9736ad11fc85be37aa97259400c30c00000000000000002ad86fa960dcbc603337737a2f54ede1df5c1f9e1cefbe9bef556778a01a9e3e0a0000000000000000b09ae8dd51148c47d4961dbfdf6b02052c80b3d040175590d34010dbf2bfacd90100000000000000001f44687cee5ddf538932e7bdb135677040610e5bd1e0015de66143ba7f95d7d3000000000000000000437b7a76594dafe2121da3ac19b5bfb8b17513fd831a7c320b5a79cbd483e3030100000000000000005ce89e885618cd355329c0680e2dec4d5090b2423d56ca7aa420005ae2a7561b0000000000000000001efc73fa2fee9b3fcde1b5f9e31af6f94452b95ecb2e94482dcab6a7dc62ea88000000000000000000dab4b173e3ad183f7440bd1967193c99787e49b62b22461ab55b8f7cec8ea0c70100000000000000009c3d6027dc44d135edbcadb0fe5aff7871baecf93c867d591ae7c6894f9b6782010000000000000000013c22260700000000220020c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb024730440220266eafba397c9cee5f5849cfb50941e6bd4704634827181f89548d294e24a9760220721870edbc73cd9ed50bc22db1777f346073b0713e640fa1e80291c971371292012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b88657024730440220096a3e06a9947c49e0682d22c456befa4956f3b7cc18d4b13d55f9c371c35892022072ff49c4997068ff4dd3836cc4b53d3e6a4f06e40b73e84ad8c2bbd88c643447012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b8865702473044022012b34533bdb17b50836c29587327787ebd3b8b3e18fc5f3d7d4dc2c76a6ddf0302207486029cc8e78d30bfa05afff0464f917902532fc1225ef3c88ba3f8a13d5c08012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b886570247304402206f71783949cb212be9e29fae55d27d673880f8ea5fed49ae5c824136e095592c0220091e596ade1be1e25a9a8a3d2a04de079171963754e1fbd3ee2d201a442cc503012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b8865702483045022100feab4037ee830b170140767cac36d57a34cc937e5064fb7dd9a9765a2953126e02203dfed10b2706166fed3a2e72f52cd7364f908dad7ab963338c93a54237bbe1840121026398bf03486ebc2039872099240ea6894d31aa8d7b05694dd0da651e99995f9a02473044022000e69c0405f738efdec05bf8fc40b5d65cfa807f88ff6f2fdbb89d45b2223bc602205f4e124f70237e66f5eae3e02bd145b5ae18bba9e876460da92a68dc9cce42b7012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b886570247304402202fd326ad725ecf389de116737db35aa0e5de55fbc02aa50ae910cd1717d999bf0220427f208c230f6bf318ca11b59ab6cda07c4dc7841dc3c46553c697ac24b9844b012103a075642232f43dc8c894a7b278caf80048ff24acc6e501a6d0e00e6ad3bd0e8d02483045022100fa3880de255c2b46b3b5402b5a35dd7831d9437bcd2933ec30517205496c0ec602203460e1291853b8eff3dd8723c467e89dc33cbed02e7897e6c473a212775dedb5012103be66a7efface72f4553e4beb53c1a88064c1225fb6254ab23a243b5a89b88657024730440220710206efc837284fb5fbe925f336e0b158be10ed5828c7300a145089aa95f5360220669e7e28a24d4cbc6e42876d10b672b66b0a1d556bfdcca0a478884e3218ef4a0121025d98dfa4f2f0b79c1af74d4e75cd45e2894310f1837aae4a8e43d2e060322a3a02483045022100e1b3be88f937e6b52df5f0ff180c786bfbc28572a8c5124732f219613a59001d02202a82327a93bbdcb901370e11f2f3ddb6203410d9e0220e5c104ea682fa561292012102dade55e0270c11e7027b5288ed73c1e5c67e3e49ea9e8484c02dcf938be686fb0247304402200bc12ac9000471e79e0cc45803ea2fa32fd2ce4e2fee84836e97bbdea2fe2d96022040e81881402ae33642e728063b7b6f32856c00174788e90fc17a9a6bf2685a9d012103fd105fc6af5c4c76fd04fdb83cdb6951ecb6972210204fb98829425c49405bbe00000000

If I use this tool to decode the HEX, this is what I get:
(...)
"vout": [
        {
            "value": 1.19939644,
            "n": 0,
            "scriptPubKey": {
                "asm": "0 c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb",
                "hex": "0020c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb",
                "address": "bc1qcf034mvwpcph7pq3l0cy9wtqqlj4ekyuc466mmle57hkfuks884szh3xxk",
                "type": "witness_v0_scripthash"
            }
        }
    ]
}

How are they able to extract the destination address bc1qcf034mvwpcph7pq3l0cy9wtqqlj4ekyuc466mmle57hkfuks884szh3xxk from a P2WPKH (witness_v0_scripthash OP_0 32 0x0020c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb)?
Or they are getting it from somewhere else?

**Tags:** bech32-address, p2wpkh, output-script

> **Comments:**
> **username_1**: `witness_v0_scripthash` does not refer to P2WPKH but rather to P2WSH  

---

## 3 answers

### Answer by username_1 on 2023-08-09. Score: 1 | Accepted answer

You can derive the address from the output script in the raw transaction.

Transaction outputs contain two fields, an 8-byte signed integer `amount` and the output script of variable length (also called `scriptPubKey` in the Bitcoin Core codebase). As the name suggests, the output script contains Script instructions or one of the standard templates that imply a set of Script instructions. Whenever a transaction is confirmed in the best chain, the assigned `amount` of funds get encumbered by the spending conditions defined per the output script.

We use addresses to represent certain standard output templates. An address encodes the output script in a form that is protected by a checksum and presented in a more human-consumable shape. In this specific case, we are looking at a native segwit v0 witness program with 32 bytes payload, or a *Pay to Witness Script Hash (P2WSH)* output.

The address is calculated from the output script by taking the human-readable part (“hrp”) and the data of the output script (witness version and witness program) to calculate a checksum. The address is then assembled by concatenating:

* the hrp `bc` for Bitcoin mainnet
* the separator `1`
* the data encoded using bech32 (see table below)
* the checksum encoded using bech32

[![bech32 translation table via BIP173](https://i.sstatic.net/Ld59O.png)](https://i.sstatic.net/Ld59O.png)

Vice versa, a sender can decode the address they get from the receiver by checking the address string for validity, removing the checksum, and decoding the data part to extract the output script. Based on the version, they can check whether the witness program has the correct form (esp. length).

If you’re looking to implement bech32, I would suggest to check out one of the [eight reference implementations](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#reference-implementations) and the [test vectors](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#test-vectors) on the BIP. Note that addresses for native segwit version 1+ use the bech32m encoding defined in [BIP350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) instead of bech32 ([BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)). Although, the only difference is that bech32m modifies the checksum constant.


---

### Answer by username_2 on 2023-07-09. Score: 0

> **How can clients know the destination address for this P2WPKH transaction?**

Clients don't need to know the address.

Addresses are not used within the Bitcoin network protocol and are not present in transaction data.

Many explorers (perhaps almost all) and wallets (including Bitcoin core) invent things in an attempt to be helpful and present them as if they were present in transaction data when they were not. For example the output you used shows four different items under "scriptPubKey". The reality is that these are four different interpretations of only one data item. A locking script. I find this ornamentation confusing. This is why I wrote my own blockchain data parser.

Addresses can be constructed for, or from, some, but not all, standard types of locking script. That includes P2WPKH.

See

* [In what format does a block store the transaction data?](https://bitcoin.stackexchange.com/q/113631/13866)
* [Is there authoritative documentation on how to generate a P2WPKH address?](https://bitcoin.stackexchange.com/q/118839/13866) where  
  Vojtěch Strnad comments that the method of constructing an address is described in BIP141 and [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)

> **Comments:**
> **username_1**: The output quoted by the asker looks like [output of Bitcoin Core](https://bitcoincore.org/en/doc/24.0.0/rpc/rawtransactions/decoderawtransaction/)  
> **username_2**: @username_1: I have amended the answer to cover this.  

---

### Answer by username_3 on 2023-07-10. Score: 0

The address is a representation of the scriptPubKey code, which in this case is (ASM) `0 c25f1aed8e0e037f0411fbf042b96007e55cd89cc575adeff9a7af64f2d039eb`.

This format (0 followed by <32 bytes>) indicates that this is a segwit transaction, which means the address should be encoded in bech32 format.

So it just needs to follow protocol to find the address: <https://en.bitcoin.it/wiki/Bech32>


---

