mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 7: add maximum capacity field.

Browse Source 
This helps lite nodes a little, but also gives a way of advertising a
lesser capacity than implied onchain.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2018-08-07 10:12:47 +09:30 committed by Christian Decker
parent 0891374d47
commit b6ae60d241
1 changed files with 31 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
07-routing-gossip.md
View File

@ -372,6 +372,7 @@ of *relaying* payments, not *sending* payments. When making a payment
* [`8`:`htlc_minimum_msat`]
* [`4`:`fee_base_msat`]
* [`4`:`fee_proportional_millionths`]
* [`8`:`htlc_maximum_msat`] (option_channel_htlc_max)
The `channel_flags` bitfield is used to indicate the direction of the channel: it
identifies the node that this update originated from and signals various options
@ -383,6 +384,13 @@ individual bits:
| 0 | `direction` | Direction this update refers to. |
| 1 | `disable` | Disable the channel. |
The `message_flags` bitfield is used to indicate the presence of optional
fields in the `channel_update` message:
| Bit Position | Name | Field |
| ------------- | ------------------------- | -------------------------------- |
| 0 | `option_channel_htlc_max` | `htlc_maximum_msat` |
The `node_id` for the signature verification is taken from the corresponding
`channel_announcement`: `node_id_1` if the least-significant bit of flags is 0
or `node_id_2` otherwise.
@ -406,7 +414,15 @@ The origin node:
- MUST set the `direction` bit of `channel_flags` to 0.
- otherwise:
- MUST set the `direction` bit of `channel_flags` to 1.
- MUST set bits that are not assigned a meaning to 0.
- 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.
- otherwise:
- 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
connectivity) OR permanent unavailability (e.g. prior to an on-chain
@ -453,6 +469,14 @@ The final node:
- otherwise:
- SHOULD queue the message for rebroadcasting.
- MAY choose NOT to for messages longer than the minimum expected length.
- if the `option_channel_htlc_max` bit of `message_flags` is 0:
- 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 discard this channel.
- otherwise:
- SHOULD consider the `htlc_maximum_msat` when routing.
### Rationale
@ -462,6 +486,12 @@ makes sense to have it be a UNIX timestamp (i.e. seconds since UTC
1970-01-01). This cannot be a hard requirement, however, given the possible case
of two `channel_update`s within a single second.
The explicit `option_channel_htlc_max` flag to indicate the presence
of `htlc_maximum_msat` (rather than having `htlc_maximum_msat` implied
by the message length) allows us to extend the `channel_update`
with different fields in future.
## Initial Sync
Note that the `initial_routing_sync` feature is overridden (and should