BOLT 9: Remove option_anchor_outputs, in favor of option_anchors_zero…

…_fee_htlc_tx.

It's supported only by pre-23.05 core-lightning nodes built with
EXPERIMENTAL_FEATURES.

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

02-peer-protocol.md

@@ -742,7 +742,6 @@ affect the channel operation).
 
 The currently defined basic types are:
   - `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)
 
 Each basic type has the following variations allowed:
@@ -971,8 +970,6 @@ Both peers:
   - otherwise:
     - 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:
       - the `channel_type` is `option_static_remotekey` (bit 12)
   - MUST use that `channel_type` for all commitment transactions.
@@ -991,17 +988,16 @@ The recipient:
 
 #### Rationale
 
-We decide on `option_static_remotekey`, `option_anchor_outputs` or
+We decide on
 `option_anchors_zero_fee_htlc_tx` at this point when we first have to generate
 the commitment transaction. The feature bits that were communicated in the
 `init` message exchange for the current connection determine the channel
 commitment format for the total lifetime of the channel. Even if a later
 reconnection does not negotiate this parameter, this channel will continue to
-use `option_static_remotekey`, `option_anchor_outputs` or
+use `option_static_remotekey` or
 `option_anchors_zero_fee_htlc_tx`; we don't support "downgrading".
 
 `option_anchors_zero_fee_htlc_tx` is considered superior to
-`option_anchor_outputs`, which again is considered superior to
 `option_static_remotekey`, and the superior one is favored if more than one
 is negotiated.
 

03-transactions.md

@@ -430,13 +430,13 @@ The fee for an HTLC-timeout transaction:
   - If `option_anchors_zero_fee_htlc_tx` applies:
     1. MUST be 0.
   - Otherwise, MUST be calculated to match:
-    1. Multiply `feerate_per_kw` by 663 (666 if `option_anchor_outputs` applies) and divide by 1000 (rounding down).
+    1. Multiply `feerate_per_kw` by 663 and divide by 1000 (rounding down).
 
 The fee for an HTLC-success transaction:
   - If `option_anchors_zero_fee_htlc_tx` applies:
     1. MUST be 0.
   - Otherwise, MUST be calculated to match:
-    1. Multiply `feerate_per_kw` by 703 (706 if `option_anchor_outputs` applies) and divide by 1000 (rounding down).
+    1. Multiply `feerate_per_kw` by 703 and divide by 1000 (rounding down).
 
 The base fee for a commitment transaction:
   - MUST be calculated to match:

05-onchain.md

@@ -606,20 +606,11 @@ to arrive at a reasonable fee.
 
 A node which broadcasts an HTLC-success or HTLC-timeout transaction for a
 commitment transaction:
-  1. if `option_anchor_outputs` applies:
-    - SHOULD combine it with inputs contributing sufficient fee to ensure
-      timely inclusion in a block.
-    - MAY combine it with other transactions.
-  2. if `option_anchors_zero_fee_htlc_tx` applies:
+  1. if `option_anchors_zero_fee_htlc_tx` applies:
     - MUST combine it with inputs contributing sufficient fee to ensure timely
       inclusion in a block.
     - MAY combine it with other transactions.
 
-Note that `option_anchors_zero_fee_htlc_tx` has a stronger requirement for
-adding inputs to the final transactions than `option_anchor_outputs`, since the
-HTLC-success and HTLC-timeout transactions won't propagate without additional
-inputs added.
-
 # General Requirements
 
 A node:

09-features.md

@@ -42,8 +42,7 @@ The Context column decodes as follows:
 | 14/15 | `payment_secret`                  | Node supports `payment_secret` field                      | IN9      | `var_onion_optin`         | [Routing Onion Specification][bolt04]                                 |
 | 16/17 | `basic_mpp`                       | Node can receive basic multi-part payments                | IN9      | `payment_secret`          | [BOLT #4][bolt04-mpp]                                                 |
 | 18/19 | `option_support_large_channel`    | Can create large channels                                 | IN       |                           | [BOLT #2](02-peer-protocol.md#the-open_channel-message)               |
-| 20/21 | `option_anchor_outputs`           | Anchor outputs                                            | IN       | `option_static_remotekey` | [BOLT #3](03-transactions.md)                                         |
-| 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions    | IN       | `option_static_remotekey` | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] |
+| 22/23 | `option_anchors_zero_fee_htlc_tx` | Anchor commitment type with zero fee HTLC transactions    | IN       |                           | [BOLT #3][bolt03-htlc-tx], [lightning-dev][ml-sighash-single-harmful] |
 | 24/25 | `option_route_blinding`           | Node supports blinded paths                               | IN9      | `var_onion_optin`         | [BOLT #4](bolt04-route-blinding)                                      |
 | 26/27 | `option_shutdown_anysegwit`       | Future segwit versions allowed in `shutdown`              | IN       |                           | [BOLT #2][bolt02-shutdown]                                            |
 | 28/29 | `option_dual_fund`                | Use v2 of channel open, enables dual funding              | IN       |                           | [BOLT #2](02-peer-protocol.md)                                        |
@@ -55,7 +54,7 @@ The Context column decodes as follows:
 
 ## Definitions
 
-We define `option_anchors` as `option_anchor_outputs || option_anchors_zero_fee_htlc_tx`.
+We define `option_anchors` as `option_anchors_zero_fee_htlc_tx`.
 
 ## Requirements