BOLT 2: define channel_type, make negotiation explicit.

This is extracted from channel_upgrade (#868), but used for opening
negotiation as suggested by @Roasbeef on the last spec meeting.

It's a trivial change, fully backwards compatible, but now each channel
has a channel_type, which defines its behavior, rather than an ad-hoc
set of "sticky" feature bits.  It also means both peers can *support* a
feature without endorsing it.

Signed-off-by: Rusty Russell <[email protected]>

Author: rustyrussell

02-peer-protocol.md

@@ -130,6 +130,9 @@ the funding transaction and both versions of the commitment transaction.
     1. type: 0 (`upfront_shutdown_script`)
     2. data:
         * [`...*byte`:`shutdown_scriptpubkey`]
+    1. type: 1 (`channel_type`)
+    2. data:
+        * [`...*byte`:`type`]
 
 The `chain_hash` value denotes the exact blockchain that the opened channel will
 reside within. This is usually the genesis hash of the respective blockchain.
@@ -197,6 +200,19 @@ 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. 
 
+#### Defined Channel Types
+
+Channel types are an explicit enumeration: for convenience of future
+definitions they reuse even feature bits, but they are not an
+arbitrary combination (they represent the persistent features which
+affect the channel operation).
+
+The currently defined types are:
+  - no features (no bits set)
+  - `option_static_remotekey` (bit 12)
+  - `option_anchor_outputs` and `option_static_remotekey` (bits 20 and 12)
+  - `option_anchors_zero_fee_htlc_tx` and `option_static_remotekey` (bits 22 and 12)
+
 #### Requirements
 
 The sending node:
@@ -217,6 +233,10 @@ The sending node:
     - MAY include `upfront_shutdown_script`.
   - if it includes `open_channel_tlvs`:
     - MUST include `upfront_shutdown_script`.
+  - if it includes `channel_type`:
+    - MUST set it to a defined type representing the type it wants.
+    - MUST use the smallest bitmap possible to represent the channel type.
+    - SHOULD NOT set it to a type containing a feature which was not negotiated.
 
 The sending node SHOULD:
   - set `to_self_delay` sufficient to ensure the sender can irreversibly spend a commitment transaction output, in case of misbehavior by the receiver.
@@ -252,6 +272,7 @@ are not valid secp256k1 pubkeys in compressed format.
   - 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`. 
+  - It supports `channel_type`, `channel_type` was set, and the `type` is not suitable.
 
 The receiving node MUST NOT:
   - consider funds received, using `push_msat`, to be received until the funding transaction has reached sufficient depth.
@@ -305,6 +326,9 @@ funding transaction and both versions of the commitment transaction.
     1. type: 0 (`upfront_shutdown_script`)
     2. data:
         * [`...*byte`:`shutdown_scriptpubkey`]
+    1. type: 1 (`channel_type`)
+    2. data:
+        * [`...*byte`:`type`]
 
 #### Requirements
 
@@ -316,14 +340,20 @@ The sender:
 avoid double-spending of the funding transaction.
   - MUST set `channel_reserve_satoshis` greater than or equal to `dust_limit_satoshis` from the `open_channel` message.
   - MUST set `dust_limit_satoshis` less than or equal to `channel_reserve_satoshis` from the `open_channel` message.
+  - if it sets `channel_type`:
+    - MUST set it to the `channel_type` from `open_channel`
 
 The receiver:
   - if `minimum_depth` is unreasonably large:
     - MAY reject the channel.
   - if `channel_reserve_satoshis` is less than `dust_limit_satoshis` within the `open_channel` message:
-	- MUST reject the channel.
+    - MUST reject the channel.
   - if `channel_reserve_satoshis` from the `open_channel` message is less than `dust_limit_satoshis`:
-	- MUST reject the channel.
+    - MUST reject the channel.
+  - if `channel_type` is set, and `channel_type` was set in `open_channel`, and they are not equal types:
+    - MUST reject the channel.
+
+
 Other fields have the same requirements as their counterparts in `open_channel`.
 
 ### The `funding_created` Message
@@ -382,14 +412,18 @@ This message introduces the `channel_id` to identify the channel. It's derived f
 #### Requirements
 
 Both peers:
-  - if `option_static_remotekey`, `option_anchor_outputs` or
-    `option_anchors_zero_fee_htlc_tx` was negotiated:
-    - `option_static_remotekey`, `option_anchor_outputs` or
-      `option_anchors_zero_fee_htlc_tx` applies to all commitment transactions
+  - if `channel_type` was present in both `open_channel` and `accept_channel`:
+    - This is the `channel_type` (they must be equal, required above)
   - otherwise:
-    - `option_static_remotekey`, `option_anchor_outputs` or
-      `option_anchors_zero_fee_htlc_tx` does not apply to any commitment
-      transactions
+    - if `option_anchors_zero_fee_htlc_tx` was negotiated:
+      - the `channel_type` is `option_anchors_zero_fee_htlc_tx` and `option_static_remotekey` (bits 22 and 12)
+    - otherwise, if `option_anchor_outputs` was negotiated:
+      - the `channel_type` is `option_anchor_outputs` and `option_static_remotekey` (bits 20 and 12)
+    - otherwise, if `option_static_remotekey` was negotiated:
+      - the `channel_type` is `option_static_remotekey` (bit 12)
+    - otherwise:
+      - the `channel_type` is empty
+  - MUST use that `channel_type` for all commitment transactions.
 
 The sender MUST set:
   - `channel_id` by exclusive-OR of the `funding_txid` and the `funding_output_index` from the `funding_created` message.
@@ -503,7 +537,7 @@ A sending node:
     - MUST NOT send a `shutdown`.
   - MUST NOT send an `update_add_htlc` after a `shutdown`.
   - if no HTLCs remain in either commitment transaction:
-	- MUST NOT send any `update` message after a `shutdown`.
+    - MUST NOT send any `update` message after a `shutdown`.
   - SHOULD fail to route any HTLC added after it has sent `shutdown`.
   - if it sent a non-zero-length `shutdown_scriptpubkey` in `open_channel` or `accept_channel`:
     - MUST send the same value in `scriptpubkey`.
@@ -516,7 +550,7 @@ A sending node:
     4. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR
     5. if (and only if) `option_shutdown_anysegwit` is negotiated:
       * `OP_1` through `OP_16` inclusive, followed by a single push of 2 to 40 bytes
-	    (witness program versions 1 through 16)
+        (witness program versions 1 through 16)
 
 A receiving node:
   - if it hasn't received a `funding_signed` (if it is a funder) or a `funding_created` (if it is a fundee):