Drop non-segwit support in shutdown

This allows dust limit to go as low as 354 sats without creating relay
issues with default node policies.

We add a requirement that dust limit cannot be lower than 354 sats.
This ensures implementers don't have to figure this subtlety on their own.

02-peer-protocol.md

@@ -258,7 +258,6 @@ The receiving node MAY fail the channel if:
   - it considers `max_htlc_value_in_flight_msat` too small.
   - it considers `channel_reserve_satoshis` too large.
   - it considers `max_accepted_htlcs` too small.
-  - it considers `dust_limit_satoshis` too small and plans to rely on the sending node publishing its commitment transaction in the event of a data loss (see [message-retransmission](02-peer-protocol.md#message-retransmission)).
   - it considers `dust_limit_satoshis` too large.
 
 The receiving node MUST fail the channel if:
@@ -270,6 +269,7 @@ The receiving node MUST fail the channel if:
   - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`, `payment_basepoint`, or `delayed_payment_basepoint`
 are not valid secp256k1 pubkeys in compressed format.
   - `dust_limit_satoshis` is greater than `channel_reserve_satoshis`.
+  - `dust_limit_satoshis` is smaller than `354 satoshis` (see [BOLT 3](03-transactions.md#dust-limits)).
   - 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`. 
@@ -547,12 +547,9 @@ A sending node:
     - MUST send the same value in `scriptpubkey`.
   - MUST set `scriptpubkey` in one of the following forms:
 
-    1. `OP_DUP` `OP_HASH160` `20` 20-bytes `OP_EQUALVERIFY` `OP_CHECKSIG`
-   (pay to pubkey hash), OR
-    2. `OP_HASH160` `20` 20-bytes `OP_EQUAL` (pay to script hash), OR
-    3. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey hash), OR
-    4. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR
-    5. if (and only if) `option_shutdown_anysegwit` is negotiated:
+    1. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey hash), OR
+    2. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR
+    3. 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)
 
@@ -580,9 +577,11 @@ may immediately begin closing negotiation, so we ban further updates
 to the commitment transaction (in particular, `update_fee` would be
 possible otherwise).
 
-The `scriptpubkey` forms include only standard forms accepted by the
-Bitcoin network, which ensures the resulting transaction will
-propagate to miners.
+The `scriptpubkey` forms include only standard segwit forms accepted by
+the Bitcoin network, which ensures the resulting transaction will
+propagate to miners. However old nodes may send non-segwit scripts, which
+may be accepted for backwards-compatibility (with a caveat to force-close
+if this output doesn't meet dust relay requirements).
 
 The `option_upfront_shutdown_script` feature means that the node
 wanted to pre-commit to `shutdown_scriptpubkey` in case it was
@@ -678,6 +677,10 @@ The receiving node:
     - MUST propose a value "strictly between" the received `fee_satoshis`
     and its previously-sent `fee_satoshis`.
 
+The receiving node:
+  - if one of the outputs in the closing transaction is below the dust limit for its `scriptpubkey` (see [BOLT 3](03-transactions.md#dust-limits)):
+    - MUST fail the channel
+
 #### Rationale
 
 When `fee_range` is not provided, the "strictly between" requirement ensures
@@ -694,6 +697,12 @@ to have a maximum feerate. It may want a minimum feerate, however, to ensure
 that the transaction propagates. It can always use CPFP later to speed up
 confirmation if necessary, so that minimum should be low.
 
+It may happen that the closing transaction doesn't meet bitcoin's default relay
+policies (e.g. when using a non-segwit shutdown script for an output below 546
+satoshis, which is possible if `dust_limit_satoshis` is below 546 satoshis).
+No funds are at risk when that happens, but the channel must be force-closed as
+the closing transaction will likely never reach miners.
+
 ## Normal Operation
 
 Once both nodes have exchanged `funding_locked` (and optionally [`announcement_signatures`](07-routing-gossip.md#the-announcement_signatures-message)), the channel can be used to make payments via Hashed Time Locked Contracts.