-
Notifications
You must be signed in to change notification settings - Fork 47
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Max Rantil <[email protected]>
- Loading branch information
Showing
2 changed files
with
62 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |