Peers need to check each other's dust limit

Since HTLCs below this amount will not appear in the commitment tx, they
are effectively converted to miner fees. The peer could use this to grief
you by broadcasting its commitment once it contains a lot of dust HTLCs.

Fixes #696

02-peer-protocol.md

@@ -259,6 +259,7 @@ The receiving node MAY fail the channel if:
   - 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:
   - the `chain_hash` value is set to a hash of a chain that is unknown to the receiver.
@@ -279,7 +280,7 @@ The receiving node MUST NOT:
 
 #### Rationale
 
-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 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.
 
@@ -295,6 +296,10 @@ would be eliminated as dust.  The similar requirements in
 `accept_channel` ensure that both sides' `channel_reserve_satoshis`
 are above both `dust_limit_satoshis`.
 
+The receiver should not accept large `dust_limit_satoshis`, as this could be
+used in griefing attacks, where the peer publishes its commitment with a lot
+of dust htlcs, which effectively become miner fees.
+
 Details for how to handle a channel failure can be found in [BOLT 5:Failing a Channel](05-onchain.md#failing-a-channel).
 
 ### The `accept_channel` Message
@@ -353,7 +358,6 @@ The receiver:
   - 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