Skip to content

BOLT 1: add networks to init message. #682

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
t-bast merged 2 commits into from
Feb 18, 2020
Merged

BOLT 1: add networks to init message. #682

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
35f1f47
BOLT 1: add networks to init message.
rustyrussell Oct 3, 2019
ade28ab
Merge branch 'master' into init-contains-networks
t-bast Feb 18, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions 01-messaging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -236,8 +236,17 @@ The `features` field MUST be padded to bytes with 0s.
* [`gflen*byte`:`globalfeatures`]
* [`u16`:`flen`]
* [`flen*byte`:`features`]
* [`init_tlvs`:`tlvs`]
Copy link
Collaborator

@cfromknecht cfromknecht Oct 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

qq on how we define this (i'm not super familiar with the parsing code): intuitively i would think that this would be

  * [`tlvs`: `init_tlvs`]

where tlvs is the type, and init_tlvs is the name. the current way is flipped from what I would expect, maybe i'm just not thinking about it correctly?

Copy link
Collaborator Author

@rustyrussell rustyrussell Oct 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type is actually defined below... Confusing I know, but it's a consequence of incrementally implementing parsing.

We could just imply TLV from now on, with msg foo having a foo_tlv implicitly?

Copy link
Collaborator

@cfromknecht cfromknecht Oct 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

either works for me, was just curious what the guidelines are :)


1. tlvs: `init_tlvs`
2. types:
1. type: 1 (`networks`)
2. data:
* [`...*chain_hash`:`chains`]


The optional `networks` indicates the chains the node is interested in.

#### Requirements

The sending node:
Expand All @@ -246,6 +255,7 @@ The sending node:
- MUST set any undefined feature bits to 0.
- SHOULD NOT set features greater than 13 in `globalfeatures`.
- SHOULD use the minimum length required to represent the `features` field.
- SHOULD set `networks` to all chains it will gossip or open channels for.

The receiving node:
- MUST wait to receive `init` before sending any other messages.
Expand All @@ -255,6 +265,8 @@ The receiving node:
- MUST ignore the bit.
- upon receiving unknown _even_ feature bits that are non-zero:
- MUST fail the connection.
- upon receiving `networks` containing no common chains
Copy link
Collaborator

@cfromknecht cfromknecht Oct 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is the prescribed action if some chains intersect but not all? would think receivers should restrict all messages they send to this intersection?

Copy link
Collaborator Author

@rustyrussell rustyrussell Oct 9, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, like @Roasbeef I haven't thought too hard about multi-chain implementation.

Hmm, I think that addition (SHOULD) would be positive, yes.

- MAY fail the connection.

#### Rationale

Expand All @@ -266,6 +278,11 @@ This semantic allows both future incompatible changes and future backward compat
Nodes wait for receipt of the other's features to simplify error
diagnosis when features are incompatible.

Since all networks share the same port, but most implementations only
support a single network, the `networks` fields avoids nodes
erroneously believing they will receive updates about their preferred
network, or that they can open channels.

### The `error` Message

For simplicity of diagnosis, it's often useful to tell a peer that something is incorrect.
Expand Down
2 changes: 2 additions & 0 deletions 07-routing-gossip.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -906,6 +906,8 @@ A node:
the arrival times of the messages.
- Note: this results in staggered announcements that are unique (not
duplicated).
- SHOULD NOT forward gossip messages to peers who sent `networks` in `init`
and did not specify the `chain_hash` of this gossip message.
- MAY re-announce its channels regularly.
- Note: this is discouraged, in order to keep the resource requirements low.
- upon connection establishment:
Expand Down