WIP: add a new message to communicate a private alternative connection address

[maxrantil]

This is a DRAFT for early feedback on the process.

This PR introduces a new configuration parameter, alt_addr, which allows specifying an alternative address for peer connections.

• Initial Connection: Upon connecting to a peer, if an alt_addr is specified, this address is communicated to the peer.
• Reconnection: During reconnection attempts, the alt_addr is used to establish the connection.

Current Limitations

• Outgoing Connections: Currently, the connection_out process utilizes the alt_addr effectively.
• Incoming Connections: The primary goal moving forward is to enhance the connection_in process to also utilize the alt_addr. Does anybody have any suggestions here? I Have been stuck with this all week.

Future Work

This PR represents a Minimum Viable Product for the alternative address feature. There are several key areas identified for future enhancement:

• Comprehensive Address Handling: Extend the handling of alt_addr to cover more edge cases and scenarios, ensuring seamless operation across various network conditions.
• Testing: Conduct thorough testing to validate the functionality of alt_addr.
• Bolt proposal

Request for Feedback

I am seeking feedback on the following:

• Incoming Connection Utilization: Any insights or suggestions on how to best implement the use of alt_addr for incoming connections (connection_in) would be greatly appreciated.
• General Feedback: Any additional feedback or suggestions to improve this feature and its implementation.

Thank you for your time and assistance. Your feedback will be invaluable in refining this feature and ensuring its robustness in production environments.

Example usage and logs demonstrating the current implementation are provided below for reference:

1. First add he parameter to the startup_regtest.sh script:

	for i in $(seq "$node_count"); do
		socket=$(( 7070 + i * 101))
		mkdir -p "$LIGHTNING_DIR/l$i"
		# Node config
		cat <<- EOF > "$LIGHTNING_DIR/l$i/config"
		network=$network
		log-level=debug
		log-file=$LIGHTNING_DIR/l$i/log
		addr=localhost:$socket
		alt-addr=127.21.21.21:$socket   <------------ HERE
		...
		...
		...

2. then run it:

➜ start_ln        
Bitcoin Core starting
awaiting bitcoind...
Loading "default" bitcoind wallet.
[3] 19996
[4] 20000
Commands: 
        l1-cli, l1-log,
        l2-cli, l2-log,
        bt-cli, stop_ln, fund_nodes
Warning: option `ssl_version` is deprecated and it is ignored. Use ssl_context instead.
timed out parsing log /tmp/l1/log


✦2 ➜ fund_nodes
bitcoind balance: 14175.84252873
Waiting for lightning node funds... found.
Funding channel <-> node 1 to node 2. Waiting for confirmation... done.
 

✦2 ➜ l2-cli listpeers
{
   "peers": [
      {
         "id": "0236588deb0ad0fbef001daf4950fd5395c6a5bbef488d27ade375cf658df1e5f6",
         "connected": true,
         "num_channels": 1,
         "netaddr": [
            "127.0.0.1:47288"
         ],
         "alt_addr": "127.21.21.21:7171",
         "features": "080000000000000000000000000008a0882a8a59a1"
      }
   ]
}


✦2 ➜ l1-cli listpeers
{
   "peers": [
      {
         "id": "035f91acadbe3be2a1ff426f0d1cc4fd34f69ec7b74d9f9e225f81266806274a8b",
         "connected": true,
         "num_channels": 1,
         "netaddr": [
            "127.0.0.1:7272"
         ],
         "alt_addr": "127.21.21.21:7272",
         "features": "080000000000000000000000000008a0882a8a59a1"
      }
   ]
}


✦2 ➜ stop_ln         
Lost connection to the RPC socket.Lost connection to the RPC socket.Lost connection to the RPC socket.Lost connection to the RPC socket.Lost connection to the RPC socket.Lost connection to the RPC socket.removed '/tmp/l1/lightningd-regtest.pid'
[3]  - terminated  $EATMYDATA "$LIGHTNINGD" "--network=$network"   "--database-upgrade=true"
Lost connection to the RPC socket.Lost connection to the RPC socket.Lost connection to the RPC socket.Lost connection to the RPC socket.removed '/tmp/l2/lightningd-regtest.pid'
Lost connection to the RPC socket.Lost connection to the RPC socket.[4]  + terminated  $EATMYDATA "$LIGHTNINGD" "--network=$network"   "--database-upgrade=true"
removed '/home/mqx/.bitcoin/regtest/bitcoind.pid'


➜ start_ln
Bitcoin Core starting
awaiting bitcoind...
Loading "default" bitcoind wallet.
[3] 22318
[4] 22322
Commands: 
        l1-cli, l1-log,
        l2-cli, l2-log,
        bt-cli, stop_ln, fund_nodes
Warning: option `ssl_version` is deprecated and it is ignored. Use ssl_context instead.
timed out parsing log /tmp/l1/log


✦2 ➜ l1-cli listpeers
{
   "peers": [
      {
         "id": "035f91acadbe3be2a1ff426f0d1cc4fd34f69ec7b74d9f9e225f81266806274a8b",
         "connected": true,
         "num_channels": 1,
         "netaddr": [
            "127.21.21.21:7272"
         ],
         "alt_addr": "127.21.21.21:7272",
         "features": "080000000000000000000000000008a0882a8a59a1"
      }
   ]
}


✦2 ➜ l2-cli listpeers
{
   "peers": [
      {
         "id": "0236588deb0ad0fbef001daf4950fd5395c6a5bbef488d27ade375cf658df1e5f6",
         "connected": true,
         "num_channels": 1,
         "netaddr": [
            "127.0.0.1:52122"
         ],
         "alt_addr": "127.21.21.21:7171",
         "features": "080000000000000000000000000008a0882a8a59a1"
      }
   ]
}

Thank you for considering this PR. I look forward to your feedback and suggestions.

[cdecker]

Thanks @maxrantil for the proposal. I read through the description, and I'm not sure I understand the rationale for this change. Is this intended as a way to say "hey, if we get disconnected, this is how you can reach me again", or is the intention something else?

Just thought I'd ask this before looking at the code itself, wanting to start with the right mental model.

[maxrantil]

Hi @cdecker , as you might know, this project is part of Summer of Bitcoin and this is the project description:

The lightning network has regimes of public and private data. Public channels and nodes are announced with gossip, while channel activity is private between peers. A nodes connection address is disseminated with the public node announcement message, which is well suited for two peers initiating a connection for the first time. Peers with an established channel or history, may prefer to connect via an alternate address for privacy, reliability, or latency concerns. This project will add a new message to communicate a private alternative connection address, and then use that address when reconnecting to a peer who has provided it.

I think this answers your question, right?

[cdecker]

Oh, cool, yeah I hadn't made the connection right away. Thanks for sharing the description, it's much clearer now ☺️