user-1: I had tried few things when reviewed this PR: https://github.com/bitcoin/bitcoin/pull/22013
While reviewing PR https://github.com/bitcoin/bitcoin/pull/22651, I was expecting 1 peer to be saved in peers.dat using the below steps:

Run Node 1:

bitcoind -port=18333 -rpcport=18222 -datadir="/home/user/node1" -regtest=1 -listen=1 -server=1 -debug=net -rpcuser=user1 -rpcpassword=password1 -torcontrol='127.0.0.1:9051' -proxy='127.0.0.1:9050' -onlynet=onion


Run Node 2:

bitcoind -port=18777 -rpcport=18666 -datadir="/home/user/node2" -regtest=1 -listen=1 -server=1 -debug=net -rpcuser=user2 -rpcpassword=password2 -addnode='127.0.0.1:18333' -torcontrol='127.0.0.1:9051' -proxy='127.0.0.1:9050' -onlynet=onion


Stop Node 1 and 2:

bitcoin-cli -rpcport=18222 -rpcuser=user1 -rpcpassword=password1 stop
bitcoin-cli -rpcport=18666 -rpcuser=user2 -rpcpassword=password2 stop


Restart Node 2 with different config (onlynet=i2p and no proxy):

bitcoind -port=18777 -rpcport=18666 -datadir="/home/user/node2" -regtest=1 -listen=1 -server=1 -debug=net -rpcuser=user2 -rpcpassword=password2 -i2psam=127.0.0.1:7656 -onlynet=i2p

But nothing was saved in peers.dat according to logs. So I had to use addpeeraddress for the test which I guess does the same thing. So if node 1 is added as outbound connection in node 2, shouldn't this be saved in peers.dat? How does it work in case of testnet or mainnet?

user208: Bitcoin Core has two mostly-separate mechanisms for creating outbound connections:

The manual mechanism, controlled by configuration settings addnode, connect, and the addnode RPC to change the addnode list at runtime. It can be used by the user to directly establish connections to peers of their choice, including ones on IP addresses that aren't publicly reachable (incl. localhost and your local network).
The automatic mechanism, where Bitcoin Core maintains a database of publicly reachable IP addresses of peers. This database is fed by seed nodes, by what its peers rumor, and by the addpeeraddress RPC. This database is large (can contain several 100000s of IP addresses), and used to establish a small (8-10) number of random connections. It is also used to answer queries by other peers (the getaddr protocol message). This database is saved to disk every 15 minutes, in the file peers.dat.

The connect configuration option (or -connect command line) enables the manual connection mechanism, and disables the automatic one. The addnode option enables the manual one, while leaving the automatic one intact (they both have independent maximum connection counts). The seednode option creates a manual connection to a certain node, asks it for peer IPs, feeds those into the automatic address database, and then disconnects.
So what is happening here is that you're using -addnode to establish a manual connection. That peer IP does not end up in peers.dat, because that file belongs to the automatic connection system. It also wouldn't work: the 127.0.0.1 address is not a public one that could even be rumored to other peers - they wouldn't be able to connect to it.

-1: <p>I had tried few things when reviewed this PR: <a href="https://github.com/bitcoin/bitcoin/pull/22013" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/pull/22013</a></p>
<p>While reviewing PR <a href="https://github.com/bitcoin/bitcoin/pull/22651" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/pull/22651</a>, I was expecting 1 peer to be saved in peers.dat using the below steps:</p>
<ol>
<li>Run Node 1:</li>
</ol>
<pre><code>bitcoind -port=18333 -rpcport=18222 -datadir=&quot;/home/user/node1&quot; -regtest=1 -listen=1 -server=1 -debug=net -rpcuser=user1 -rpcpassword=password1 -torcontrol='127.0.0.1:9051' -proxy='127.0.0.1:9050' -onlynet=onion
</code></pre>
<ol start="2">
<li>Run Node 2:</li>
</ol>
<pre><code>bitcoind -port=18777 -rpcport=18666 -datadir=&quot;/home/user/node2&quot; -regtest=1 -listen=1 -server=1 -debug=net -rpcuser=user2 -rpcpassword=password2 -addnode='127.0.0.1:18333' -torcontrol='127.0.0.1:9051' -proxy='127.0.0.1:9050' -onlynet=onion
</code></pre>
<ol start="3">
<li>Stop Node 1 and 2:</li>
</ol>
<pre><code>bitcoin-cli -rpcport=18222 -rpcuser=user1 -rpcpassword=password1 stop
bitcoin-cli -rpcport=18666 -rpcuser=user2 -rpcpassword=password2 stop
</code></pre>
<ol start="4">
<li>Restart Node 2 with different config (<code>onlynet=i2p</code> and no <code>proxy</code>):</li>
</ol>
<pre><code>bitcoind -port=18777 -rpcport=18666 -datadir=&quot;/home/user/node2&quot; -regtest=1 -listen=1 -server=1 -debug=net -rpcuser=user2 -rpcpassword=password2 -i2psam=127.0.0.1:7656 -onlynet=i2p
</code></pre>
<p>But nothing was saved in peers.dat according to logs. So I had to use <code>addpeeraddress</code> for the test which I guess does the same thing. So if node 1 is added as outbound connection in node 2, shouldn't this be saved in peers.dat? How does it work in case of testnet or mainnet?</p>
 208: <p>Bitcoin Core has two mostly-separate mechanisms for creating outbound connections:</p>
<ul>
<li>The <strong>manual</strong> mechanism, controlled by configuration settings <code>addnode</code>, <code>connect</code>, and the <code>addnode</code> RPC to change the addnode list at runtime. It can be used by the user to directly establish connections to peers of their choice, including ones on IP addresses that aren't publicly reachable (incl. localhost and your local network).</li>
<li>The <strong>automatic</strong> mechanism, where Bitcoin Core maintains a database of <em>publicly</em> reachable IP addresses of peers. This database is fed by seed nodes, by what its peers rumor, and by the <code>addpeeraddress</code> RPC. This database is large (can contain several 100000s of IP addresses), and used to establish a small (8-10) number of random connections. It is also used to answer queries by other peers (the <code>getaddr</code> protocol message). This database is saved to disk every 15 minutes, in the file <code>peers.dat</code>.</li>
</ul>
<p>The <code>connect</code> configuration option (or <code>-connect</code> command line) enables the manual connection mechanism, and disables the automatic one. The <code>addnode</code> option enables the manual one, while leaving the automatic one intact (they both have independent maximum connection counts). The <code>seednode</code> option creates a <em>manual</em> connection to a certain node, asks it for peer IPs, feeds those into the <em>automatic</em> address database, and then disconnects.</p>
<p>So what is happening here is that you're using <code>-addnode</code> to establish a manual connection. That peer IP does not end up in <code>peers.dat</code>, because that file belongs to the automatic connection system. It also wouldn't work: the 127.0.0.1 address is not a public one that could even be rumored to other peers - they wouldn't be able to connect to it.</p>
