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,8 +577,8 @@ 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
+The `scriptpubkey` forms include only standard segwit forms accepted by
+the Bitcoin network, which ensures the resulting transaction will
 propagate to miners.
 
 The `option_upfront_shutdown_script` feature means that the node
@@ -678,6 +675,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