Skip to content

bolt07: remove trailing tabs #679

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
rustyrussell merged 1 commit into from
Nov 20, 2019
Merged

bolt07: remove trailing tabs #679

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
53 changes: 26 additions & 27 deletions 07-routing-gossip.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -458,15 +458,15 @@ The origin node:
- otherwise:
- MUST set the `direction` bit of `channel_flags` to 1.
- if the `htlc_maximum_msat` field is present:
- MUST set the `option_channel_htlc_max` bit of `message_flags` to 1.
- MUST set `htlc_maximum_msat` to the maximum value it will send through this channel for a single HTLC.
- MUST set this to less than or equal to the channel capacity.
- MUST set this to less than or equal to `max_htlc_value_in_flight_msat`
it received from the peer.
- for channels with `chain_hash` identifying the Bitcoin blockchain:
- MUST set this to less than 2^32.
- MUST set the `option_channel_htlc_max` bit of `message_flags` to 1.
- MUST set `htlc_maximum_msat` to the maximum value it will send through this channel for a single HTLC.
- MUST set this to less than or equal to the channel capacity.
- MUST set this to less than or equal to `max_htlc_value_in_flight_msat`
it received from the peer.
- for channels with `chain_hash` identifying the Bitcoin blockchain:
- MUST set this to less than 2^32.
- otherwise:
- MUST set the `option_channel_htlc_max` bit of `message_flags` to 0.
- MUST set the `option_channel_htlc_max` bit of `message_flags` to 0.
- MUST set bits in `channel_flags` and `message_flags `that are not assigned a meaning to 0.
- MAY create and send a `channel_update` with the `disable` bit set to 1, to
signal a channel's temporary unavailability (e.g. due to a loss of
Expand Down Expand Up @@ -522,10 +522,10 @@ The receiving node:
- MUST consider `htlc_maximum_msat` not to be present.
- otherwise:
- if `htlc_maximum_msat` is not present or greater than channel capacity:
- MAY blacklist this `node_id`
- SHOULD ignore this channel during route considerations.
- otherwise:
- SHOULD consider the `htlc_maximum_msat` when routing.
- MAY blacklist this `node_id`
- SHOULD ignore this channel during route considerations.
- otherwise:
- SHOULD consider the `htlc_maximum_msat` when routing.

### Rationale

Expand Down Expand Up @@ -676,13 +676,13 @@ The receiver:
- MUST reply with the latest `node_announcement` for `node_id_1`
- if bit 4 of `query_flag` is set and it has received a `node_announcement` from `node_id_2`:
- MUST reply with the latest `node_announcement` for `node_id_2`
- SHOULD NOT wait for the next outgoing gossip flush to send these.
- SHOULD NOT wait for the next outgoing gossip flush to send these.
- SHOULD avoid sending duplicate `node_announcements` in response to a single `query_short_channel_ids`.
- MUST follow these responses with `reply_short_channel_ids_end`.
- if does not maintain up-to-date channel information for `chain_hash`:
- MUST set `complete` to 0.
- MUST set `complete` to 0.
- otherwise:
- SHOULD set `complete` to 1.
- SHOULD set `complete` to 1.

#### Rationale

Expand Down Expand Up @@ -733,7 +733,7 @@ Though it is possible, it would not be very useful to ask for checksums without
2. types:
1. type: 1 (`timestamps_tlv`)
2. data:
* [`u8`:`encoding_type`]
* [`u8`:`encoding_type`]
* [`...*byte`:`encoded_timestamps`]
1. type: 3 (`checksums_tlv`)
2. data:
Expand Down Expand Up @@ -779,8 +779,7 @@ The receiver of `query_channel_range`:
- if it has not sent all `reply_channel_range` to a previously received `query_channel_range` from this sender:
- MAY fail the connection.
- MUST respond with one or more `reply_channel_range` whose combined range
cover the requested `first_blocknum` to `first_blocknum` plus
`number_of_blocks` minus one.
cover the requested `first_blocknum` to `first_blocknum` plus `number_of_blocks` minus one.
- For each `reply_channel_range`:
- MUST set with `chain_hash` equal to that of `query_channel_range`,
- MUST encode a `short_channel_id` for every open channel it knows in blocks `first_blocknum` to `first_blocknum` plus `number_of_blocks` minus one.
Expand Down Expand Up @@ -830,17 +829,17 @@ The receiver:
- SHOULD send all gossip messages whose `timestamp` is greater or
equal to `first_timestamp`, and less than `first_timestamp` plus
`timestamp_range`.
- MAY wait for the next outgoing gossip flush to send these.
- MAY wait for the next outgoing gossip flush to send these.
- SHOULD restrict future gossip messages to those whose `timestamp`
is greater or equal to `first_timestamp`, and less than
`first_timestamp` plus `timestamp_range`.
- If a `channel_announcement` has no corresponding `channel_update`s:
- MUST NOT send the `channel_announcement`.
- MUST NOT send the `channel_announcement`.
- Otherwise:
- MUST consider the `timestamp` of the `channel_announcement` to be the `timestamp` of a corresponding `channel_update`.
- MUST consider whether to send the `channel_announcement` after receiving the first corresponding `channel_update`.
- MUST consider the `timestamp` of the `channel_announcement` to be the `timestamp` of a corresponding `channel_update`.
- MUST consider whether to send the `channel_announcement` after receiving the first corresponding `channel_update`.
- If a `channel_announcement` is sent:
- MUST send the `channel_announcement` prior to any corresponding `channel_update`s and `node_announcement`s.
- MUST send the `channel_announcement` prior to any corresponding `channel_update`s and `node_announcement`s.

#### Rationale

Expand Down Expand Up @@ -875,7 +874,7 @@ interactions with them.

A node:
- if the `gossip_queries` feature is negotiated:
- MUST NOT relay any gossip messages unless explicitly requested.
- MUST NOT relay any gossip messages unless explicitly requested.
- otherwise:
- if it requires a full copy of the peer's routing state:
- SHOULD set the `initial_routing_sync` flag to 1.
Expand Down Expand Up @@ -907,7 +906,7 @@ A receiving node:

A node:
- if the `gossip_queries` feature is negotiated:
- MUST not send gossip until it receives `gossip_timestamp_filter`.
- MUST not send gossip until it receives `gossip_timestamp_filter`.
- SHOULD flush outgoing gossip messages once every 60 seconds, independently of
the arrival times of the messages.
- Note: this results in staggered announcements that are unique (not
Expand Down Expand Up @@ -1072,7 +1071,7 @@ per [HTLC Fees](#htlc-fees):

fee_base_msat + ( amount_to_forward * fee_proportional_millionths / 1000000 )

200 + ( 4999999 * 2000 / 1000000 ) = 10199
200 + ( 4999999 * 2000 / 1000000 ) = 10199

Similarly, it would need to add B->C's `channel_update` `cltv_expiry` (20), C's
requested `min_final_cltv_expiry` (9), and the cost for the _shadow route_ (42).
Expand All @@ -1092,7 +1091,7 @@ A->D's `update_add_htlc` message would be:
* `amount_msat`: 5020398
* `cltv_expiry`: current-block-height + 40 + 9 + 42
* `onion_routing_packet`:
* `amt_to_forward` = 4999999
* `amt_to_forward` = 4999999
* `outgoing_cltv_value` = current-block-height + 9 + 42

And D->C's `update_add_htlc` would again be the same as B->C's direct payment
Expand Down