BOLT 9: add features wumbo and wumborama#590
Conversation
|
How about renaming:
It is a bit less fun but also more self explaining. We can still keep the wumbo nickname :-). |
|
|
||
| [ FIXME: Describe dangerous feature bit for larger channel amounts. ] | ||
| The `option_i_wumbo_you_wumbo` allows peers to signal that they will accept | ||
| `funding_satoshis` greater than 2^24. |
There was a problem hiding this comment.
also mention option_wumborama here?
| - MUST set feature bits as defined in [BOLT #9](09-features.md). | ||
| - MUST set any undefined feature bits to 0. | ||
| - SHOULD use the minimum lengths required to represent the feature fields. | ||
| - MUST set local feature `option_i_wumbo_you_wumbo` if `option_wumborama` is set in global features. |
There was a problem hiding this comment.
this seems like an odd place to add this requirement. this restriction applies to the wumbo bit featureset, not to the global/localfeatures requirements. i'd move this to the Requirements section in features.
| - MUST ensure `temporary_channel_id` is unique from any other channel ID with the same peer. | ||
| - MUST set `funding_satoshis` to less than 2^24 satoshi. | ||
| - if both nodes advertised `option_i_wumbo_you_wumbo`: | ||
| - MAY set `funding_satoshis` greater than 2^24 satoshi. |
There was a problem hiding this comment.
| - MAY set `funding_satoshis` greater than 2^24 satoshi. | |
| - MAY set `funding_satoshis` greater than or equal to 2^24 satoshi. |
| - `dust_limit_satoshis` is greater than `channel_reserve_satoshis`. | ||
| - the funder's amount for the initial commitment transaction is not sufficient for full [fee payment](03-transactions.md#fee-payment). | ||
| - both `to_local` and `to_remote` amounts for the initial commitment transaction are less than or equal to `channel_reserve_satoshis` (see [BOLT 3](03-transactions.md#commitment-transaction-outputs)). | ||
| - `funding_satoshis` is greater than 2^24 and the receiver does not support `option_i_wumbo_you_wumbo`. |
There was a problem hiding this comment.
| - `funding_satoshis` is greater than 2^24 and the receiver does not support `option_i_wumbo_you_wumbo`. | |
| - `funding_satoshis` is greater than or equal to 2^24 and the receiver does not support `option_i_wumbo_you_wumbo`. |
| It can be lifted at any point in time, or adjusted for other currencies, since it is solely enforced by the endpoints of a channel. | ||
| Specifically, [the routing gossip protocol](07-routing-gossip.md) does not discard channels that have a larger capacity. | ||
| The requirement for `funding_satoshis` to be less than 2^24 satoshi was a temporary self-imposed limit while implementations were not yet considered stable. | ||
| , it can be lifted by advertising `option_i_wumbo_you_wumbo`. |
There was a problem hiding this comment.
Technically option_wumborama would have been used to advertise that you will support option_i_wumbo_you_wumbo, anyway I'm going to change this PR to use a single option (since there was some agreement at the last meeting)
|
There's some overlap with this and #571 |
|
Closing as this is replaced by #596 |
This proposal formalizes the discussion happened on the mailing list about lifting the channel size limit. Two features are defined here:
option_i_wumbo_you_wumbomeans I'm willing to accept channel larger than 2^24 (local feature)option_wumboramameans I offer and I'm willing to acceptoption_i_wumbo_you_wumbofrom anyone (global feature)Peers MUST set
option_i_wumbo_you_wumboin the local features of theinitmessage if they set theoption_wumboramain the global features, the proposal reuses the bits defined in #571