blip-0043: Alternative Addresses

Signed-off-by: Max Rantil <[email protected]>

Author: maxrantil

README.md

@@ -28,4 +28,4 @@ For more detail on the process, please read [bLIP-0001](./blip-0001.md) and
 | [17](./blip-0017.md)     | Hosted Channels                | Anton Kumaigorodskiy        | Active |
 | [25](./blip-0025.md)     | Forward less than onion value  | Valentine Wallace           | Active |
 | [32](./blip-0032.md)     | Onion Message DNS Resolution   | Matt Corallo                | Active |
-
+| [32](./blip-0043.md)     | Alternative Addresses          | Max Rantil                  | Active |

blip-0043.md

@@ -0,0 +1,61 @@
+```
+bLIP: 43
+Title: Alternative Addresses for Peer Connections
+Status: Active
+Author: Max Rantil <[email protected]>
+Created: 2024-08-31
+License: CC0
+```
+
+## Abstract
+
+The `alt_addr` message introduces a mechanism for nodes to specify private alternative connection addresses for peers. These addresses facilitate reconnections between nodes with an existing relationship, bypassing the public gossip protocol. This allows peers with an established channel or history to use alternative addresses for improved privacy, reliability, or latency.
+
+## Copyright
+
+This bLIP is licensed under the CC0 license.
+
+## Motivation
+
+The primary motivations for introducing alternative addresses are:
+
+- Enhanced privacy: By allowing peers to use private addresses not disclosed in the public network, the risk of traffic analysis is reduced.
+- Improved reliability: Alternative addresses can provide fallback options if the primary address becomes unreachable.
+- Potential latency improvements: Private addresses might offer more direct or optimized network paths between peers.
+- Greater control: Nodes can selectively share alternative addresses with trusted peers, maintaining public presence while offering improved connectivity to specific partners.
+
+## Specification
+
+### The `alt_addr` Message
+
+1. **type**: 209 (`peer_alt_addr`)
+2. **data**:
+   - [`channel_id`:`channel_id`]
+   - [`u8`:`addr_len`]
+   - [`addr_len*byte`:`addr`]
+
+### Requirements
+
+#### Sending Node
+
+- **SHOULD** send `alt_addr` when a new connection address is necessary for enhanced privacy or network performance.
+- **MAY** send an empty `addr` to clear any previously stored alternative addresses.
+- **MUST** store a record of the peers to whom it has sent its `alt_addr` for future verification.
+- **MUST** verify that an incoming connection attempt using `alt_addr` is from the specific peer to whom it has previously provided that exact address.
+- **MUST** reject connection attempts using `alt_addr` if it has not sent that specific `alt_addr` to the connecting peer.
+
+#### Receiving Node
+
+- **MUST** store the `alt_addr` in persistent storage upon successful validation.
+- **MUST** use the stored `alt_addr` when initiating a connection to the peer that provided it.
+- **MAY** continue using the original address until `alt_addr` is fully validated.
+
+## Rationale
+
+By allowing nodes to use private, alternative connection addresses, this proposal enables a more controlled and secure network environment, where peers can selectively manage who has access to their alternative addresses without exposing these addresses to the wider public network.
+
+This feature also complements other address management features such as `alt-bind-addr` and `alt-announce-addr`, providing nodes with additional flexibility in how they present and manage their network addresses.
+
+## Backwards Compatibility
+
+This proposal does not affect backward compatibility as it introduces an optional message that nodes can choose to implement without impacting the existing protocol.