Test init networks TLV

.aspell.en.pws

@@ -367,7 +367,12 @@ fips
 rfc
 varint
 CompactSize
+multipath
+mpp
 tlvs
 snprintf
 GitHub
 IRC
+bitmasks
+CSPRNG
+lexicographically

01-messaging.md

@@ -51,12 +51,13 @@ A receiving node:
   - upon receiving a message of _even_, unknown type:
     - MUST fail the channels.
 
-The messages are grouped logically into four groups, ordered by the most significant bit that is set:
+The messages are grouped logically into five groups, ordered by the most significant bit that is set:
 
   - Setup & Control (types `0`-`31`): messages related to connection setup, control, supported features, and error reporting (described below)
   - Channel (types `32`-`127`): messages used to setup and tear down micropayment channels (described in [BOLT #2](02-peer-protocol.md))
   - Commitment (types `128`-`255`): messages related to updating the current commitment transaction, which includes adding, revoking, and settling HTLCs as well as updating fees and exchanging signatures (described in [BOLT #2](02-peer-protocol.md))
   - Routing (types `256`-`511`): messages containing node and channel announcements, as well as any active route exploration (described in [BOLT #7](07-routing-gossip.md))
+  - Custom (types `32768`-`65535`): experimental and application-specific messages
 
 The size of the message is required by the transport layer to fit into a 2-byte unsigned int; therefore, the maximum possible size is 65535 bytes.
 
@@ -66,6 +67,13 @@ A node:
     - MUST fail the channels.
   - that negotiates an option in this specification:
     - MUST include all the fields annotated with that option.
+  - When defining custom messages:
+    - SHOULD pick a random `type` to avoid collision with other custom types.
+    - SHOULD pick a `type` that doesn't conflict with other experiments listed in [this issue](https://github.com/lightningnetwork/lightning-rfc/issues/716).
+    - SHOULD pick an odd `type` identifiers when regular nodes should ignore the
+      additional data.
+    - SHOULD pick an even `type` identifiers when regular nodes should reject
+      the message and close the connection.
 
 ### Rationale
 
@@ -100,7 +108,7 @@ A `tlv_record` represents a single field, encoded in the form:
 A `varint` is a variable-length, unsigned integer encoding using the
 [BigSize](#appendix-a-bigsize-test-vectors) format, which resembles the bitcoin
 CompactSize encoding but uses big-endian for multi-byte values rather than
-little-endian. 
+little-endian.
 
 A `tlv_stream` is a series of (possibly zero) `tlv_record`s, represented as the
 concatenation of the encoded `tlv_record`s. When used to extend existing
@@ -214,7 +222,7 @@ integers can be omitted:
 The following convenience types are also defined:
 
 * `chain_hash`: a 32-byte chain identifier (see [BOLT #0](00-introduction.md#glossary-and-terminology-guide))
-* `channel_id`: a 32-byte channel_id (see [BOLT #2](02-peer-protocol.md#definition-of-channel-id)
+* `channel_id`: a 32-byte channel_id (see [BOLT #2](02-peer-protocol.md#definition-of-channel-id))
 * `sha256`: a 32-byte SHA2-256 hash
 * `signature`: a 64-byte bitcoin Elliptic Curve signature
 * `point`: a 33-byte Elliptic Curve point (compressed encoding as per [SEC 1 standard](http://www.secg.org/sec1-v2.pdf#subsubsection.2.3.3))
@@ -226,45 +234,66 @@ 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_.  For historical reasons, features are divided into global and local feature bitmasks.
 
-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`:`flen`]
+   * [`flen*byte`:`features`]
+   * [`init_tlvs`:`tlvs`]
 
-The 2-byte `gflen` and `lflen` fields indicate the number of bytes in the immediately following field.
+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:
   - MUST send `init` as the first Lightning message for any connection.
   - 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 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.
+  - MUST combine (logical OR) the two feature bitmaps into one logical `features` map.
   - MUST respond to known feature bits as specified in [BOLT #9](09-features.md).
   - upon receiving unknown _odd_ feature bits that are non-zero:
     - 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
+    - MAY fail the connection.
+  - if the feature vector does not set all known, transitive dependencies:
+    - MUST fail the connection.
+  - upon receiving `networks` containing no common chains
+    - MAY fail the connection.
 
 #### Rationale
 
+There used to be two feature bitfields here, but for backwards compatibility they're now
+combined into one.
+
 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).
+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
 
@@ -875,7 +904,7 @@ failure:
 
 ## References
 
-1. <a id="reference-2">http://www.unicode.org/charts/PDF/U2600.pdf</a>
+1. <a id="reference-1">http://www.unicode.org/charts/PDF/U2600.pdf</a>
 
 ## Authors
 

02-peer-protocol.md

@@ -6,7 +6,7 @@ operation, and closing.
 # Table of Contents
 
   * [Channel](#channel)
-    * [Definition of `channel_id`](#definition-of-channel-id)
+    * [Definition of `channel_id`](#definition-of-channel_id)
     * [Channel Establishment](#channel-establishment)
       * [The `open_channel` Message](#the-open_channel-message)
       * [The `accept_channel` Message](#the-accept_channel-message)
@@ -187,16 +187,22 @@ 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 `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, and `delayed_payment_basepoint` to valid secp256k1 pubkeys in compressed format.
   - 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).
   - MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis`.
   - MUST set undefined bits in `channel_flags` to 0.
@@ -234,19 +240,18 @@ The receiving node MUST fail the channel if:
   - `max_accepted_htlcs` is greater than 483.
   - it considers `feerate_per_kw` too small for timely processing or unreasonably large.
   - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, or `delayed_payment_basepoint`
-are not valid DER-encoded compressed secp256k1 pubkeys.
+are not valid secp256k1 pubkeys in compressed format.
   - `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
@@ -425,11 +424,6 @@ funds are at risk. If the fundee were to remember the channel forever, this
 would create a Denial of Service risk; therefore, forgetting it is recommended
 (even if the promise of `push_msat` is significant).
 
-#### Future
-
-An SPV proof could be added and block hashes could be routed in separate
-messages.
-
 ## Channel Close
 
 Nodes can negotiate a mutual close of the connection, which unlike a

03-transactions.md

@@ -62,7 +62,7 @@ Most transaction outputs used here are pay-to-witness-script-hash<sup>[BIP141](h
 
 `2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG`
 
-* Where `pubkey1` is the numerically lesser of the two DER-encoded `funding_pubkey` and where `pubkey2` is the numerically greater of the two.
+* Where `pubkey1` is the lexicographically lesser of the two `funding_pubkey` in compressed format, and where `pubkey2` is the lexicographically greater of the two.
 
 ## Commitment Transaction
 
@@ -575,7 +575,7 @@ A double-check, that all previous secrets derive correctly, is needed;
 if this check fails, the secrets were not generated from the same seed:
 
     insert_secret(secret, I):
-        B = where_to_put_secret(secret, I)
+        B = where_to_put_secret(I)
 
         # This tracks the index of the secret in each bucket across the traversal.
         for b in 0 to B: