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 |
-
+| [43](./blip-0043.md)     | Alternative Addresses          | Max Rantil                  | Active |

blip-0043.md

@@ -0,0 +1,78 @@
+```
+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`:`addrs`]
+
+The first byte describes the address type and is followed by the appropriate number of bytes for that type.
+
+The following address descriptor types are defined:
+
+   * `1`: ipv4; data = `[4:ipv4_addr][2:port]` (length 6)
+   * `2`: ipv6; data = `[16:ipv6_addr][2:port]` (length 18)
+   * `3`: Deprecated (length 12). Used to contain Tor v2 onion services.
+   * `4`: Tor v3 onion service; data = `[35:onion_addr][2:port]` (length 37)
+       * version 3 ([prop224](https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt))
+         onion service addresses; Encodes:
+         `[32:32_byte_ed25519_pubkey] || [2:checksum] || [1:version]`, where
+         `checksum = sha3(".onion checksum" || pubkey || version)[:2]`.
+   * `5`: DNS hostname; data = `[1:hostname_len][hostname_len:hostname][2:port]` (length up to 258)
+       * `hostname` bytes MUST be ASCII characters.
+       * Non-ASCII characters MUST be encoded using Punycode:
+         https://en.wikipedia.org/wiki/Punycode
+
+### 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.