Single-option large channel proposal

01-messaging.md

@@ -215,26 +215,26 @@ The following convenience types are also defined:
 
 Once authentication is complete, the first message reveals the features supported or required by this node, even if this is a reconnection.
 
-[BOLT #9](09-features.md) specifies lists of global and local features. Each feature is generally represented in `globalfeatures` or `localfeatures` by 2 bits. The least-significant bit is numbered 0, which is _even_, and the next most significant bit is numbered 1, which is _odd_.
+[BOLT #9](09-features.md) specifies lists of features. Each feature is generally represented by 2 bits. The least-significant bit is numbered 0, which is _even_, and the next most significant bit is numbered 1, which is _odd_.
 
-Both fields `globalfeatures` and `localfeatures` MUST be padded to bytes with 0s.
+The `features` field MUST be padded to bytes with 0s.
 
 1. type: 16 (`init`)
 2. data:
-   * [`u16`:`gflen`]
-   * [`gflen*byte`:`globalfeatures`]
-   * [`u16`:`lflen`]
-   * [`lflen*byte`:`localfeatures`]
+   * [`u16`:`ignorelen`]
+   * [`ignorelen*byte`:`ignore`]
+   * [`u16`:`flen`]
+   * [`flen*byte`:`features`]
 
-The 2-byte `gflen` and `lflen` fields indicate the number of bytes in the immediately following field.
 
 #### Requirements
 
 The sending node:
   - MUST send `init` as the first Lightning message for any connection.
+  - MUST set `ignorelen` to zero.
   - 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.
+  - SHOULD use the minimum length required to represent the `features` field.
 
 The receiving node:
   - MUST wait to receive `init` before sending any other messages.
@@ -246,15 +246,13 @@ The receiving node:
 
 #### Rationale
 
+There used to be two feature bitfields here, but the first is now ignored.
+
 This semantic allows both future incompatible changes and future backward compatible changes. Bits should generally be assigned in pairs, in order that optional features may later become compulsory.
 
 Nodes wait for receipt of the other's features to simplify error
 diagnosis when features are incompatible.
 
-The feature masks are split into local features (which only affect the
-protocol between these two nodes) and global features (which can affect
-HTLCs and are thus also advertised to other nodes).
-
 ### The `error` Message
 
 For simplicity of diagnosis, it's often useful to tell a peer that something is incorrect.

02-peer-protocol.md

@@ -187,14 +187,20 @@ The `shutdown_scriptpubkey` allows the sending node to commit to where
 funds will go on mutual close, which the remote node should enforce
 even if a node is compromised later.
 
-[ FIXME: Describe dangerous feature bit for larger channel amounts. ]
+The `option_support_large_channel` is a feature used to let everyone 
+know this node will accept `funding_satoshis` greater than or equal to 2^24.
+Since it's broadcast in the `node_announcement` message other nodes can use it to identify peers 
+willing to accept large channel even before exchanging the `init` message with them. 
 
 #### Requirements
 
 The sending node:
   - MUST ensure the `chain_hash` value identifies the chain it wishes to open the channel within.
   - 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_support_large_channel`:
+    - MAY set `funding_satoshis` greater than or equal to 2^24 satoshi.
+  - otherwise:
+    - MUST set `funding_satoshis` to less than 2^24 satoshi.
   - MUST set `push_msat` to equal or less than 1000 * `funding_satoshis`.
   - MUST set `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, and `delayed_payment_basepoint` to valid DER-encoded, compressed, secp256k1 pubkeys.
   - MUST set `first_per_commitment_point` to the per-commitment point to be used for the initial commitment transaction, derived as specified in [BOLT #3](03-transactions.md#per-commitment-secret-requirements).
@@ -238,15 +244,14 @@ are not valid DER-encoded compressed secp256k1 pubkeys.
   - `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 or equal to 2^24 and the receiver does not support `option_support_large_channel`. 
 
 The receiving node MUST NOT:
   - consider funds received, using `push_msat`, to be received until the funding transaction has reached sufficient depth.
 
 #### Rationale
 
-The requirement for `funding_satoshi` to be less than 2^24 satoshi is a temporary self-imposed limit while implementations are not yet considered stable.
-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_support_large_channel`. 
 
 The *channel reserve* is specified by the peer's `channel_reserve_satoshis`: 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially, this reserve may not be met, as only one side has funds; but the protocol ensures that there is always progress toward meeting this reserve, and once met, it is maintained.
 
@@ -264,12 +269,6 @@ are above both `dust_limit_satoshis`.
 
 Details for how to handle a channel failure can be found in [BOLT 5:Failing a Channel](05-onchain.md#failing-a-channel).
 
-#### Future
-
-It would be easy to have a local feature bit which indicated that a
-receiving node was prepared to fund a channel, which would reverse this
-protocol.
-
 ### The `accept_channel` Message
 
 This message contains information about a node and indicates its

07-routing-gossip.md

@@ -180,16 +180,15 @@ The origin node:
   - MUST set `bitcoin_signature_1` and `bitcoin_signature_2` to valid
   signatures of the hash `h` (using `bitcoin_key_1` and `bitcoin_key_2`'s
   respective secrets).
-  - SHOULD set `len` to the minimum length required to hold the `features` bits
+  - MUST set `features` based on what features were negotiated for this channel, according to [BOLT #9](09-features.md#assigned-features-flags)
+  - MUST set `len` to the minimum length required to hold the `features` bits
   it sets.
 
 The receiving node:
   - MUST verify the integrity AND authenticity of the message by verifying the
   signatures.
   - if there is an unknown even bit in the `features` field:
-    - MUST NOT parse the remainder of the message.
-    - MUST NOT add the channel to its local network view.
-    - SHOULD NOT forward the announcement.
+    - MUST NOT attempt to route messages through the channel.
   - if the `short_channel_id`'s output does NOT correspond to a P2WSH (using
     `bitcoin_key_1` and `bitcoin_key_2`, as specified in
     [BOLT #3](03-transactions.md#funding-transaction-output)) OR the output is
@@ -243,8 +242,6 @@ New channel features are possible in the future: backwards compatible (or
 optional) features will have _odd_ feature bits, while incompatible features
 will have _even_ feature bits
 (["It's OK to be odd!"](00-introduction.md#glossary-and-terminology-guide)).
-Incompatible features will result in the announcement not being forwarded by
-nodes that do not understand them.
 
 ## The `node_announcement` Message
 
@@ -311,6 +308,7 @@ The origin node:
   to 0.
   - SHOULD ensure `ipv4_addr` AND `ipv6_addr` are routable addresses.
   - MUST NOT include more than one `address descriptor` of the same type.
+  - MUST set `features` according to [BOLT #9](09-features.md#assigned-features-flags)
   - SHOULD set `flen` to the minimum length required to hold the `features`
   bits it sets.
 
@@ -324,11 +322,7 @@ any future fields appended to the end):
     - SHOULD fail the connection.
     - MUST NOT process the message further.
   - if `features` field contains _unknown even bits_:
-    - MUST NOT parse the remainder of the message.
-    - MAY discard the message altogether.
     - SHOULD NOT connect to the node.
-  - MAY forward `node_announcement`s that contain an _unknown_ `features` _bit_,
-  regardless of if it has parsed the announcement or not.
   - SHOULD ignore the first `address descriptor` that does NOT match the types
   defined above.
   - if `addrlen` is insufficient to hold the address descriptors of the
@@ -352,8 +346,9 @@ any future fields appended to the end):
 
 New node features are possible in the future: backwards compatible (or
 optional) ones will have _odd_ `feature` _bits_, incompatible ones will have
-_even_ `feature` _bits_. These may be propagated by nodes even if they
-cannot process the announcements themselves.
+_even_ `feature` _bits_. These will be propagated normally; incompatible
+feature bits here refer to the nodes, not the `node_announcement` message
+itself.
 
 New address types may be added in the future; as address descriptors have
 to be ordered in ascending order, unknown ones can be safely ignored.

09-features.md

@@ -1,43 +1,55 @@
 # BOLT #9: Assigned Feature Flags
 
-This document tracks the assignment of `localfeatures` and `globalfeatures`
-flags in the `init` message ([BOLT #1](01-messaging.md)) along with the
-`features` flag fields in the `channel_announcement` and `node_announcement`
-messages ([BOLT #7](07-routing-gossip.md)).
-The flags are tracked separately, since new flags will likely be added over time.
-
-The `features` flags in the routing messages are a subset of the
-`globalfeatures` flags, as `localfeatures`, by definition, are only of interest
-to direct peers.
+This document tracks the assignment of `features` flags in the `init`
+message ([BOLT #1](01-messaging.md)), as well as `features` fields in
+the `channel_announcement` and `node_announcement` messages ([BOLT
+#7](07-routing-gossip.md)).  The flags are tracked separately, since
+new flags will likely be added over time.
 
 Flags are numbered from the least-significant bit, at bit 0 (i.e. 0x1,
 an _even_ bit). They are generally assigned in pairs so that features
 can be introduced as optional (_odd_ bits) and later upgraded to be compulsory
 (_even_ bits), which will be refused by outdated nodes:
 see [BOLT #1: The `init` Message](01-messaging.md#the-init-message).
 
-## Assigned `localfeatures` flags
-
-These flags may only be used in the `init` message:
 
-| Bits  | Name                             | Description                                                               | Link                         |
-|-------|----------------------------------|---------------------------------------------------------------------------|------------------------------|
-| 0/1   | `option_data_loss_protect`       | Requires or supports extra `channel_reestablish` fields                   | [BOLT #2][bolt02-retransmit] |
-| 3     | `initial_routing_sync`           | Indicates that the sending node needs a complete routing information dump | [BOLT #7][bolt07-sync]       |
-| 4/5   | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel                   | [BOLT #2][bolt02-open]       |
-| 6/7   | `gossip_queries`                 | More sophisticated gossip control                                         | [BOLT #7][bolt07-query]      |
-| 10/11 | `gossip_queries_ex`              | Gossip queries can include additional information                         | [BOLT #7][bolt07-query]      |
+## Assigned `features` flags
 
-## Assigned `globalfeatures` flags
+Some features don't make sense on a per-channels or per-node basis, so
+each feature defines how it is presented in those contexts.  Some
+features may be required for opening a channel, but not a requirement
+for use of the channel, so the presentation of those features depends
+on the feature itself.
 
-The following `globalfeatures` bits are currently assigned by this specification:
+The Context column decodes as follows:
+* `I`: presented in the `init` message.
+* `N`: presented in the `node_announcement` messages
+* `C`: presented in the `channel_announcement` message.
+* `C-`: presented in the `channel_announcement` message, but always odd (optional).
+* `C+`: presented in the `channel_announcement` message, but always even (required).
 
-| Bits | Name              | Description                                                        | Link                                  |
-|------|-------------------|--------------------------------------------------------------------|---------------------------------------|
-| 8/9  | `var_onion_optin` | This node requires/supports variable-length routing onion payloads | [Routing Onion Specification][bolt04] |
+| Bits  | Name                             | Description                                               | Context  | Link                                  |
+|-------|----------------------------------|-----------------------------------------------------------|----------|---------------------------------------|
+| 0/1   | `option_data_loss_protect`       | Requires or supports extra `channel_reestablish` fields   | IN       | [BOLT #2][bolt02-retransmit]          |
+| 3     | `initial_routing_sync`           | Sending node needs a complete routing information dump    | I        | [BOLT #7][bolt07-sync]                |
+| 4/5   | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel   | IN       | [BOLT #2][bolt02-open]                |
+| 6/7   | `gossip_queries`                 | More sophisticated gossip control                         | IN       | [BOLT #7][bolt07-query]               |
+| 8/9   | `var_onion_optin`                | Requires/supports variable-length routing onion payloads  | IN       | [Routing Onion Specification][bolt04] |
+| 10/11 | `gossip_queries_ex`              | Gossip queries can include additional information         | IN       | [BOLT #7][bolt07-query]               |
+| 14/15 | `option_support_large_channel`   | Can create large channels                                 | INC+     | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
 
 ## Requirements
 
+The origin node:
+  * If it supports a feature above, SHOULD set the corresponding odd
+    bit in all feature fields indicated by the Context column unless
+	indicated that it must set the even feature bit instead.
+  * If it requires a feature above, MUST set the corresponding even
+    feature bit in all feature fields indicated by the Context column,
+    unless indicated that it must set the odd feature bit instead.
+  * MUST NOT set feature bits it does not support.
+  * MUST NOT set feature bits in fields not specified by the table above.
+
 The requirements for receiving specific bits are defined in the linked sections in the table above.
 The requirements for feature bits that are not defined
 above can be found in [BOLT #1: The `init` Message](01-messaging.md#the-init-message).