<blockquote>
  <p>Why is this output there?</p>
</blockquote>

<p>Because it is part of the <code>version</code> P2P message. <code>getpeerinfo</code> largely outputs the information provided by the <code>version</code> message.</p>

<blockquote>
  <p>Is it used anywhere? Does it have a use case?</p>
</blockquote>

<p>Currently, no. However it may have been included in the <code>version</code> message because Bitcoin was originally designed for things to go directly to IP addresses. There used to be a Pay-to-IP thing where this could have been useful.</p>

<blockquote>
  <p>Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?</p>
</blockquote>

<p>Because it is easier to implement and no one actually uses it.</p>

CC BY-SA 4.0
2018-10-03T17:31:33.013Z
2018-10-03T17:31:33.013Z
Ava Chow
<blockquote>
<p>Why is this output there?</p>
</blockquote>
<p>It is sent to the Bitcoin node by its peers in their <code>version</code> P2P messages.</p>
<blockquote>
<p>Is it used anywhere? Does it have a use case?</p>
</blockquote>
<p>Yes. Foremost, it is used in Bitcoin's P2P networking. When a node wishes to accept incoming Bitcoin network connections over the Internet but doesn't know its own IP address on the Internet, it can use the <code>addrLocal</code> reported by an outbound peer to discover what IP address the outbound peer sees this node's connection coming from. If this IP address is within valid Internet ranges, this node may then advertise this IP for future incoming connections. In Bitcoin Core, this discovery behavior is enabled or disabled by supplying the <code>-discover</code> option to bitcoind or bitcoin-qt.</p>
<p><code>addrLocal</code> can also be used by applications that receive the information via the getPeerInfo RPC procedure you mention. If an application is wanting to make its own decisions about what IP address to advertise for a node, such as for a website, it can include this peer-supplied data in its decision. An application might also wish to determine how a peer connected to a node when this node offers multiple routes for peers to connect (e.g. via NAT, reverse proxies, forward proxies, tunnels, anonymizers, etc.)</p>
<blockquote>
<p>Furthermore, they commented that &quot;Most SPV nodes set this to 127.0.0.1:8333&quot;, why would an SPV node do that?</p>
</blockquote>
<p>Either because the SPV node is actually running and connected locally or because the SPV node has lied. A use-case for any type of node lying might be the developer leaving in a placeholder value while they haven't finished implementing the network protocol's requirements fully, or if the connecting node wishes to obscure what route it took to connect to this node when there are multiple options available.</p>
<p>The &quot;most SPV nodes&quot; wording has largely been removed from documentation.</p>

CC BY-SA 4.0
2022-08-06T21:41:26.500Z
2022-08-06T21:41:26.500Z
Justin Turner Arthur
<p>According to the Bitcoin core developer reference, the RPC call <a href="https://bitcoin.org/en/developer-reference#getpeerinfo" rel="nofollow noreferrer">getPeerInfo</a> has in its output a field called "addrlocal" which holds our IP from the worldview of the peer.</p>

<p>Why is this output there? Is it used anywhere? Does it have a use case?</p>

<p>Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?</p>

<bitcoin-core><client><json-rpc>
Why is there an addrlocal field in the output of the RPC call getPeerInfo, and how SPVs handle it?
Shai Deshe
# Why is there an addrlocal field in the output of the RPC call getPeerInfo, and how SPVs handle it?

(Asked by: username_0 on 2018-10-03)

According to the Bitcoin core developer reference, the RPC call [getPeerInfo](https://bitcoin.org/en/developer-reference#getpeerinfo) has in its output a field called "addrlocal" which holds our IP from the worldview of the peer.

Why is this output there? Is it used anywhere? Does it have a use case?

Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?

**Tags:** bitcoin-core, client, json-rpc


---

## 2 answers

### Answer by username_1 on 2018-10-03. Score: 2 | Accepted answer

> Why is this output there?

Because it is part of the `version` P2P message. `getpeerinfo` largely outputs the information provided by the `version` message.

> Is it used anywhere? Does it have a use case?

Currently, no. However it may have been included in the `version` message because Bitcoin was originally designed for things to go directly to IP addresses. There used to be a Pay-to-IP thing where this could have been useful.

> Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?

Because it is easier to implement and no one actually uses it.


---

### Answer by username_2 on 2022-08-06. Score: 0

> Why is this output there?

It is sent to the Bitcoin node by its peers in their `version` P2P messages.

> Is it used anywhere? Does it have a use case?

Yes. Foremost, it is used in Bitcoin's P2P networking. When a node wishes to accept incoming Bitcoin network connections over the Internet but doesn't know its own IP address on the Internet, it can use the `addrLocal` reported by an outbound peer to discover what IP address the outbound peer sees this node's connection coming from. If this IP address is within valid Internet ranges, this node may then advertise this IP for future incoming connections. In Bitcoin Core, this discovery behavior is enabled or disabled by supplying the `-discover` option to bitcoind or bitcoin-qt.

`addrLocal` can also be used by applications that receive the information via the getPeerInfo RPC procedure you mention. If an application is wanting to make its own decisions about what IP address to advertise for a node, such as for a website, it can include this peer-supplied data in its decision. An application might also wish to determine how a peer connected to a node when this node offers multiple routes for peers to connect (e.g. via NAT, reverse proxies, forward proxies, tunnels, anonymizers, etc.)

> Furthermore, they commented that "Most SPV nodes set this to 127.0.0.1:8333", why would an SPV node do that?

Either because the SPV node is actually running and connected locally or because the SPV node has lied. A use-case for any type of node lying might be the developer leaving in a placeholder value while they haven't finished implementing the network protocol's requirements fully, or if the connecting node wishes to obscure what route it took to connect to this node when there are multiple options available.

The "most SPV nodes" wording has largely been removed from documentation.


---

