<p>In short, the answer to your question depends on what you mean by &quot;address&quot;. Historically, there are two different concepts with that name which I'll refer to as <strong>payment destinations</strong> and <strong>public key identifiers</strong>:</p>
<ul>
<li>If you want <em>payment destinations</em>, these are already reported in the Bitcoin Core RPC output in the &quot;address&quot; field.</li>
<li>If you want the dated concept of <em>public key identifiers</em> as some block explorers still use, my hope is to convince you that this is terrible practice that you shouldn't try to imitate or persist at all.</li>
</ul>
<p>These aren't well-established names, nor are they concepts I want to introduce a name for. They're just what I use in this answer to distinguish the two.</p>
<hr />
<p>For background: Bitcoin transactions pay to <em>scriptPubKeys</em>, these are scripts that encode the conditions under which the sent coins can be spent. When a receiver R expects a sender S to pay them, they need some way of communicating to S ('s software) what scriptPubKey they expect S to construct so that S can access them.</p>
<p>Early in Bitcoin's history (before 2012) there were only two common types of scriptPubKeys, pay-to-pubkey (P2PK; where the scriptPubKey directly stores the public key of the recipient) and pay-to-pubkey-hash (P2PKH; where the scriptPubKey only stores a hash of the public key of the recipient). However, only a human-readable notation was introduced for P2PKH. P2PK was still in use, e.g. in mining software where no script needed to be communicated to any other party (it was just miners paying themselves effectively), but any &quot;payment&quot; use that involves one party asking to be paid by another party used P2PKH.</p>
<p>However, despite there not existing a way to <em>instruct</em> someone to pay using P2PK (=payment destination), people still needed a way to <em>describe</em> who/what a payment was for (=public key identifier). For listing who a P2PK output was for, the choice was obvious: just use the address for the corresponding P2PKH payment destination.</p>
<p>Clearly, a payment to a P2PK scriptPubKey with key <em>P</em> and a payment to a P2PKH scriptPubKey with key hash equal to the hash of <em>P</em> are spendable by the same person, so as a way to determine who a payment is for (=public key identification), this approach works. However, it does create a confusion of the form that someone might see a P2PK output, compute its corresponding P2PKH address, and then create another payment to that same address (=payment destination), and perhaps expect to see the same scriptPubKey appear.</p>
<p>Now, P2PK and P2PKH scripts are not the only types of scripts that Bitcoin supports (even from the very beginning). Another possible script is bare multisig: a scriptPubKey that contains multiple people's public keys directly, so everyone can see who it is for. This saw some limited use, and some infrastructure was introduced to make this work, including reporting these types of outputs as having <strong>multiple</strong> addresses in the public key identification meaning: one address for each of the public keys involved. Bitcoin Core's RPC output in fact worked this way for a while; there was no &quot;address&quot; field, but an &quot;addresses&quot; field, which could contain multiple elements. For bare multisig scriptPubKeys, it'd list one address for each public key. For P2PK and P2PKH scriptPubKeys, it'd just list one address (the one corresponding to the public key's P2PKH payment destination).</p>
<p>However, no address (in the payment destination sense) type was ever defined for bare multisig, so there was no way to instruct anyone to create such payments. Instead, in 2012, following the P2SH softfork, a very different payment destination address format was introduced: one where the receiver only reveals a <em>hash of a script</em> to the sender, and the individual public key(s) are not revealed to the network at sending time. <strong>The public key identification interpretation of addresses fails completely here</strong>. We have a new payment destination address type from which <em>nothing</em> about the participating public key(s) can be inferred at all.</p>
<p>And this concept caught on: P2SH (and its successors) actually ended up widely adopted, and bare multisig pretty much died. There were good reasons for this:</p>
<ul>
<li>more private due to not needing to tell the sender the public keys about all the participants in the multisig scheme (which is none of the senders' business)</li>
<li>cheaper for the sender (as they don't need to encode all those public keys on chain in their transaction), moving the cost of using complex logic to the receiver, who is the party that decided to use the complexity</li>
<li>much more convenient (a single payment destination string, rather than some possible complex structure containing multiple public keys)</li>
</ul>
<p>After P2SH, even newer script extensions were added, with corresponding address (=payment destination) encodings. The table below hopefully summarizes them:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>scriptPubKey type</th>
<th>Introduced</th>
<th>Use as payment destination</th>
<th>Use as public key identifier</th>
</tr>
</thead>
<tbody>
<tr>
<td>P2PKH</td>
<td>2009</td>
<td>Legacy base58check format</td>
<td>Yes, contains public key hash</td>
</tr>
<tr>
<td>Bare multisig</td>
<td>2009</td>
<td>-</td>
<td>Sort-of, with multiple &quot;addresses&quot; per output</td>
</tr>
<tr>
<td>P2PK</td>
<td>2009</td>
<td>-</td>
<td>Yes, public key hash can be computed from public key.</td>
</tr>
<tr>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">P2SH</a></td>
<td>2012</td>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki" rel="nofollow noreferrer">BIP13</a> base58check format</td>
<td>-</td>
</tr>
<tr>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">P2WPKH</a></td>
<td>2017</td>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a> bech32 format</td>
<td>Yes in theory, contains public key hash, but not commonly done.</td>
</tr>
<tr>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki" rel="nofollow noreferrer">P2WSH</a></td>
<td>2017</td>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a> bech32 format</td>
<td>-</td>
</tr>
<tr>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">P2TR</a></td>
<td>2020</td>
<td><a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP350</a> bech32m format</td>
<td>-</td>
</tr>
</tbody>
</table>
</div>
<p>So overall:</p>
<ul>
<li>Bitcoin transaction outputs contain scriptPubKeys, which can be anything, and are not restricted to any particular set of standard scripts.</li>
<li><em>Some</em> types of scriptPubKeys have an associated address format that can be used to instruct parties to pay to that scriptPubKey.</li>
<li><em>Some</em> types of scriptPubKey allow determining which public key (hash) the payment is for, but that's increasingly not the case for modern scripts.</li>
<li>Historically, the P2PKH address format was used as a way to represent &quot;who&quot; a scriptPubKey is for, as opposed to encoding a specific scriptPubKey (which involved representing P2PK using the P2PKH addresss format, and bare multisig even as multiple P2PKH addresses). This doesn't make sense anymore: the introduction of P2SH and its successors show that in general, one cannot identify <em>who</em> from a scriptPubKeys, and doing this just reinforces a misunderstanding.</li>
</ul>

CC BY-SA 4.0
2023-03-01T22:59:18.913Z
This is a thing of beauty. Thank you so much. Most of them make sense now, but I am still not sure how block explorers generate addresses for all kind of transactions then. Even though they are using an old notion of "address" (payment destination), they are able to accumulate balance with unique addresses for all kinds of transaction, right? I guess I want to understand how can people assign unique address to account by just looking at the chain data, like block explorers are doing.
xor
CC BY-SA 4.0
2023-03-16T14:07:39.487Z
I apologize if this is a stupid question or if you already explained it in the above post, but I need to clarify my understanding.

Now I think I understand what you meant by "payment destination" and "public key identifier" since the transaction is paying to "script", and sometimes the requirement to unlock that script is more complexed than represented with one public key. However, I need to find a way to represent a unique representation for payment destination.
xor
CC BY-SA 4.0
2023-03-16T14:12:34.543Z
@xor If there is no well-defined address for a scriptPubKey (in the payment destination sense), you're out of luck. If you want to be unambiguous, you could just hex encode the scriptPubKey or so, but there is no way that's both unambiguous and well-established. Certain block explorers just don't show anything at all if there is no address (including for P2PK outputs, e.g. https://blockstream.info/nojs/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098?expand).
Pieter Wuille
CC BY-SA 4.0
2023-03-16T14:14:51.860Z
If my understanding is correct, all of the scriptPubKey types that can be used as "payment destination" has an "address" field when retrieved with JSON-RPC. Is my understanding correct? Secondly, if I want to derive a payment destination for the "P2PK" type, if I just hash the public key and use legacy base58check format, will I get the same "address" as the "P2PKH" when the public key is the same? Finally, even though the transaction is paid to the same person in "P2PKH" and "P2WPKH" (meaning that a private key owner can spend both outputs), address fields will have different values, right?
xor
CC BY-SA 4.0
2023-03-16T14:18:39.167Z
If an an address exists for a scriptPubKey in the payment destination sense (as in: sending to that address will result in the same scriptPubKey), then the JSON-RPC interface will report that address. P2PK scriptPubKeys don't have such an address. You *can* in theory take the public key in a P2PK output and hash it, and encode that as a P2PKH address, but that's only meaningful if your goal is identifying public keys, because sending to that P2PKH address will not send to the same scriptPubKey, and possibly even burn funds. Further, for e.g. P2SH/P2WSH/P2TR no such hack is possible.
Pieter Wuille
CC BY-SA 4.0
2023-03-16T14:19:27.610Z
And I very seriously hope you're not going to turn P2PK outputs into P2PKH addresses. It's a nonsensical historical practice that confuses what address mean.
Pieter Wuille
CC BY-SA 4.0
2023-03-16T14:23:47.727Z
My usage of the term "payment destination" and "public key identifier" are about what **you** want the address to mean. If the point is to show something that can be sent to, simply nothing exists for P2PK or bare multisig. If the point is identify which public keys are involved, simply nothing exist for P2SH, P2WSH, or P2TR. You should ask yourself what you're trying to achieve with your "unique representation".
Pieter Wuille
CC BY-SA 4.0
2023-03-16T14:38:24.777Z
I see. I will think more about what is more meaningful representation. Maybe using hexcode of scriptPubKey is most unamgiuous option as you mentioned.
xor
CC BY-SA 4.0
2023-03-01T22:35:14.347Z
2023-03-02T20:47:11.373Z
2023-03-02T20:47:11.373Z
Pieter Wuille
<p>What would be the easiest way to retrieve addresses that are used in specific transaction? For instance, if you look at following transaction which is retrieved by <code>getblock</code> of JSON RPC with argument of verbosity 2 (<a href="https://developer.bitcoin.org/reference/rpc/getblock.html" rel="nofollow noreferrer">https://developer.bitcoin.org/reference/rpc/getblock.html</a>),</p>
<pre><code>....
&quot;tx&quot;:[
      {
         .....
         &quot;vin&quot;:[
            {
               &quot;coinbase&quot;:....,
               &quot;sequence&quot;: ...
            }
         ],
         &quot;vout&quot;:[
            {
               &quot;value&quot;:...,
               &quot;n&quot;:...,
               &quot;scriptPubKey&quot;:{
                  &quot;asm&quot;:...,
                  &quot;desc&quot;:...,
                  &quot;hex&quot;:...,
                  &quot;type&quot;:...
               }
            }
]
</code></pre>
<p>How can I know receiver's address by looking at &quot;scriptPubKey&quot;? One of the challenges was there were different types of scriptPubKey so that it was kind of hard to parse them. Does anyone know best way to retrieve public address from any kind of scriptPubKey, so that the result will be matched with the addresses that are used by block explorers?</p>
<p>P.S. I think some of the newer transactions actually contain &quot;Address&quot; field inside the scriptPubKey, but older transactions do not. I want to have a generalized method that can handle any kind of transactions.</p>

CC BY-SA 4.0
2023-03-01T03:37:48.773Z
Do you mean a way to decode scriptPubKeys yourself from hex data to addresses, or a way to get it from the Bitcoin Core RPC output? Because if an output *has* an address, the RPC output will list it. But addresses only exist for scriptPubKeys that match certain patterns; others just don't have one.
Pieter Wuille
CC BY-SA 4.0
2023-03-01T20:56:04.700Z
I was referring to a way to decode scriptPubKeys to addresses. For example, if you retrieve block height 13367 from RPC, it won't give you address explicitly even though the type is pubkey. However, if you use blockchain.info API, it contains address: https://blockchain.info/rawblock/000000008be5151fa84c4eeec998e61cbcfdaf8123d610381d7e3c8c25af57d2

I am wondering how I can do this without API's help.
xor
CC BY-SA 4.0
2023-03-01T20:58:30.627Z
Also, do you mind if you can explain what you meant by address does not exist for certain types of transactions?
xor
CC BY-SA 4.0
2023-03-01T20:58:37.227Z
That's because blockchain.info is using an outdated notion of "address". Pay-to-pubkey outputs don't have addresses corresponding to them, and never had any (it's not possible to pay to such outputs by paying to that address). However, historically, at some point they were lumped together with P2PKH (pay to pubkey hash) outputs for the same public key (which do have addresses). This is currently considered a historical mistake, as it was confusing addresses (a way to specify who to pay) with identities (which public key is involved). Since the introduction of multisig, these are distinct.
Pieter Wuille
CC BY-SA 4.0
2023-03-01T21:02:52.453Z
Addresses don't exist at the Bitcoin protocol level; only scripts exists. Some scripts are very common, so human-readable ways of communicating them were introduced, known as addresses. Nothing in the protocol however restricts people from creating payments to scripts which don't have a corresponding address. One prominent example is pay-to-pubkey (P2PK)... no address was ever defined for such outputs, but they were at some point common on chain, so explorers lumped them together with another type of script (which does have an address) for the same key.
Pieter Wuille
CC BY-SA 4.0
2023-03-01T21:15:26.857Z
That was a lot so I needed some time to digest. Thanks for the explanation. If my understanding is correct, "address" is just a concept we made to identify account in more efficient way. By looking at script data retrieved from RPC, is it possible to derive some sort of address, or any kind of unique identity of the sender and receiver? I am assuming there should be a way to derive public key from transaction data, but I would prefer to store them more efficiently since public key is long.
xor
CC BY-SA 4.0
2023-03-01T21:16:06.120Z
Also, how is blockchain.info is deriving "address" even for transactions to multisignature wallet or other special types of transactions?
xor
CC BY-SA 4.0
2023-03-01T21:21:02.597Z
LIke if I get public key hash from any type of transaction, and perform base58check encoding, would that represent "address"? To be clear, I want to come up with efficient way to store unique identity of each "account".
xor
<bitcoin-core><transactions><address><script><public-key>
Calculating addresses from Bitcoin transaction data
xor
# Calculating addresses from Bitcoin transaction data

(Asked by: username_0 on 2023-03-01)

What would be the easiest way to retrieve addresses that are used in specific transaction? For instance, if you look at following transaction which is retrieved by `getblock` of JSON RPC with argument of verbosity 2 (<https://developer.bitcoin.org/reference/rpc/getblock.html>),

```
....
"tx":[
      {
         .....
         "vin":[
            {
               "coinbase":....,
               "sequence": ...
            }
         ],
         "vout":[
            {
               "value":...,
               "n":...,
               "scriptPubKey":{
                  "asm":...,
                  "desc":...,
                  "hex":...,
                  "type":...
               }
            }
]

```

How can I know receiver's address by looking at "scriptPubKey"? One of the challenges was there were different types of scriptPubKey so that it was kind of hard to parse them. Does anyone know best way to retrieve public address from any kind of scriptPubKey, so that the result will be matched with the addresses that are used by block explorers?

P.S. I think some of the newer transactions actually contain "Address" field inside the scriptPubKey, but older transactions do not. I want to have a generalized method that can handle any kind of transactions.

**Tags:** bitcoin-core, transactions, address, script, public-key

> **Comments:**
> **username_1**: Do you mean a way to decode scriptPubKeys yourself from hex data to addresses, or a way to get it from the Bitcoin Core RPC output? Because if an output *has* an address, the RPC output will list it. But addresses only exist for scriptPubKeys that match certain patterns; others just don't have one.  
> **username_0**: I was referring to a way to decode scriptPubKeys to addresses. For example, if you retrieve block height 13367 from RPC, it won't give you address explicitly even though the type is pubkey. However, if you use blockchain.info API, it contains address: https://blockchain.info/rawblock/000000008be5151fa84c4eeec998e61cbcfdaf8123d610381d7e3c8c25af57d2  I am wondering how I can do this without API's help.  
> **username_0**: Also, do you mind if you can explain what you meant by address does not exist for certain types of transactions?  
> **username_1**: That's because blockchain.info is using an outdated notion of "address". Pay-to-pubkey outputs don't have addresses corresponding to them, and never had any (it's not possible to pay to such outputs by paying to that address). However, historically, at some point they were lumped together with P2PKH (pay to pubkey hash) outputs for the same public key (which do have addresses). This is currently considered a historical mistake, as it was confusing addresses (a way to specify who to pay) with identities (which public key is involved). Since the introduction of multisig, these are distinct.  
> **username_1**: Addresses don't exist at the Bitcoin protocol level; only scripts exists. Some scripts are very common, so human-readable ways of communicating them were introduced, known as addresses. Nothing in the protocol however restricts people from creating payments to scripts which don't have a corresponding address. One prominent example is pay-to-pubkey (P2PK)... no address was ever defined for such outputs, but they were at some point common on chain, so explorers lumped them together with another type of script (which does have an address) for the same key.  
> **username_0**: That was a lot so I needed some time to digest. Thanks for the explanation. If my understanding is correct, "address" is just a concept we made to identify account in more efficient way. By looking at script data retrieved from RPC, is it possible to derive some sort of address, or any kind of unique identity of the sender and receiver? I am assuming there should be a way to derive public key from transaction data, but I would prefer to store them more efficiently since public key is long.  
> **username_0**: Also, how is blockchain.info is deriving "address" even for transactions to multisignature wallet or other special types of transactions?  
> **username_0**: LIke if I get public key hash from any type of transaction, and perform base58check encoding, would that represent "address"? To be clear, I want to come up with efficient way to store unique identity of each "account".  

---

## 1 answers

### Answer by username_1 on 2023-03-01. Score: 4

In short, the answer to your question depends on what you mean by "address". Historically, there are two different concepts with that name which I'll refer to as **payment destinations** and **public key identifiers**:

* If you want *payment destinations*, these are already reported in the Bitcoin Core RPC output in the "address" field.
* If you want the dated concept of *public key identifiers* as some block explorers still use, my hope is to convince you that this is terrible practice that you shouldn't try to imitate or persist at all.

These aren't well-established names, nor are they concepts I want to introduce a name for. They're just what I use in this answer to distinguish the two.

---

For background: Bitcoin transactions pay to *scriptPubKeys*, these are scripts that encode the conditions under which the sent coins can be spent. When a receiver R expects a sender S to pay them, they need some way of communicating to S ('s software) what scriptPubKey they expect S to construct so that S can access them.

Early in Bitcoin's history (before 2012) there were only two common types of scriptPubKeys, pay-to-pubkey (P2PK; where the scriptPubKey directly stores the public key of the recipient) and pay-to-pubkey-hash (P2PKH; where the scriptPubKey only stores a hash of the public key of the recipient). However, only a human-readable notation was introduced for P2PKH. P2PK was still in use, e.g. in mining software where no script needed to be communicated to any other party (it was just miners paying themselves effectively), but any "payment" use that involves one party asking to be paid by another party used P2PKH.

However, despite there not existing a way to *instruct* someone to pay using P2PK (=payment destination), people still needed a way to *describe* who/what a payment was for (=public key identifier). For listing who a P2PK output was for, the choice was obvious: just use the address for the corresponding P2PKH payment destination.

Clearly, a payment to a P2PK scriptPubKey with key *P* and a payment to a P2PKH scriptPubKey with key hash equal to the hash of *P* are spendable by the same person, so as a way to determine who a payment is for (=public key identification), this approach works. However, it does create a confusion of the form that someone might see a P2PK output, compute its corresponding P2PKH address, and then create another payment to that same address (=payment destination), and perhaps expect to see the same scriptPubKey appear.

Now, P2PK and P2PKH scripts are not the only types of scripts that Bitcoin supports (even from the very beginning). Another possible script is bare multisig: a scriptPubKey that contains multiple people's public keys directly, so everyone can see who it is for. This saw some limited use, and some infrastructure was introduced to make this work, including reporting these types of outputs as having **multiple** addresses in the public key identification meaning: one address for each of the public keys involved. Bitcoin Core's RPC output in fact worked this way for a while; there was no "address" field, but an "addresses" field, which could contain multiple elements. For bare multisig scriptPubKeys, it'd list one address for each public key. For P2PK and P2PKH scriptPubKeys, it'd just list one address (the one corresponding to the public key's P2PKH payment destination).

However, no address (in the payment destination sense) type was ever defined for bare multisig, so there was no way to instruct anyone to create such payments. Instead, in 2012, following the P2SH softfork, a very different payment destination address format was introduced: one where the receiver only reveals a *hash of a script* to the sender, and the individual public key(s) are not revealed to the network at sending time. **The public key identification interpretation of addresses fails completely here**. We have a new payment destination address type from which *nothing* about the participating public key(s) can be inferred at all.

And this concept caught on: P2SH (and its successors) actually ended up widely adopted, and bare multisig pretty much died. There were good reasons for this:

* more private due to not needing to tell the sender the public keys about all the participants in the multisig scheme (which is none of the senders' business)
* cheaper for the sender (as they don't need to encode all those public keys on chain in their transaction), moving the cost of using complex logic to the receiver, who is the party that decided to use the complexity
* much more convenient (a single payment destination string, rather than some possible complex structure containing multiple public keys)

After P2SH, even newer script extensions were added, with corresponding address (=payment destination) encodings. The table below hopefully summarizes them:

| scriptPubKey type | Introduced | Use as payment destination | Use as public key identifier |
| --- | --- | --- | --- |
| P2PKH | 2009 | Legacy base58check format | Yes, contains public key hash |
| Bare multisig | 2009 | - | Sort-of, with multiple "addresses" per output |
| P2PK | 2009 | - | Yes, public key hash can be computed from public key. |
| [P2SH](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) | 2012 | [BIP13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki) base58check format | - |
| [P2WPKH](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) | 2017 | [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) bech32 format | Yes in theory, contains public key hash, but not commonly done. |
| [P2WSH](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) | 2017 | [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) bech32 format | - |
| [P2TR](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) | 2020 | [BIP350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) bech32m format | - |

So overall:

* Bitcoin transaction outputs contain scriptPubKeys, which can be anything, and are not restricted to any particular set of standard scripts.
* *Some* types of scriptPubKeys have an associated address format that can be used to instruct parties to pay to that scriptPubKey.
* *Some* types of scriptPubKey allow determining which public key (hash) the payment is for, but that's increasingly not the case for modern scripts.
* Historically, the P2PKH address format was used as a way to represent "who" a scriptPubKey is for, as opposed to encoding a specific scriptPubKey (which involved representing P2PK using the P2PKH addresss format, and bare multisig even as multiple P2PKH addresses). This doesn't make sense anymore: the introduction of P2SH and its successors show that in general, one cannot identify *who* from a scriptPubKeys, and doing this just reinforces a misunderstanding.

> **Comments:**
> **username_0**: This is a thing of beauty. Thank you so much. Most of them make sense now, but I am still not sure how block explorers generate addresses for all kind of transactions then. Even though they are using an old notion of "address" (payment destination), they are able to accumulate balance with unique addresses for all kinds of transaction, right? I guess I want to understand how can people assign unique address to account by just looking at the chain data, like block explorers are doing.  
> **username_0**: I apologize if this is a stupid question or if you already explained it in the above post, but I need to clarify my understanding.  Now I think I understand what you meant by "payment destination" and "public key identifier" since the transaction is paying to "script", and sometimes the requirement to unlock that script is more complexed than represented with one public key. However, I need to find a way to represent a unique representation for payment destination.  
> **username_1**: @username_0 If there is no well-defined address for a scriptPubKey (in the payment destination sense), you're out of luck. If you want to be unambiguous, you could just hex encode the scriptPubKey or so, but there is no way that's both unambiguous and well-established. Certain block explorers just don't show anything at all if there is no address (including for P2PK outputs, e.g. https://blockstream.info/nojs/tx/0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098?expand).  
> **username_0**: If my understanding is correct, all of the scriptPubKey types that can be used as "payment destination" has an "address" field when retrieved with JSON-RPC. Is my understanding correct? Secondly, if I want to derive a payment destination for the "P2PK" type, if I just hash the public key and use legacy base58check format, will I get the same "address" as the "P2PKH" when the public key is the same? Finally, even though the transaction is paid to the same person in "P2PKH" and "P2WPKH" (meaning that a private key owner can spend both outputs), address fields will have different values, right?  
> **username_1**: If an an address exists for a scriptPubKey in the payment destination sense (as in: sending to that address will result in the same scriptPubKey), then the JSON-RPC interface will report that address. P2PK scriptPubKeys don't have such an address. You *can* in theory take the public key in a P2PK output and hash it, and encode that as a P2PKH address, but that's only meaningful if your goal is identifying public keys, because sending to that P2PKH address will not send to the same scriptPubKey, and possibly even burn funds. Further, for e.g. P2SH/P2WSH/P2TR no such hack is possible.  
> **username_1**: And I very seriously hope you're not going to turn P2PK outputs into P2PKH addresses. It's a nonsensical historical practice that confuses what address mean.  
> **username_1**: My usage of the term "payment destination" and "public key identifier" are about what **you** want the address to mean. If the point is to show something that can be sent to, simply nothing exists for P2PK or bare multisig. If the point is identify which public keys are involved, simply nothing exist for P2SH, P2WSH, or P2TR. You should ask yourself what you're trying to achieve with your "unique representation".  
> **username_0**: I see. I will think more about what is more meaningful representation. Maybe using hexcode of scriptPubKey is most unamgiuous option as you mentioned.  

---

