Context

Eclair currently disallows dust_limit_satoshis below 546 satoshis.
This ensures all transactions will be relayed by Bitcoin Core node running the default policies.

It looks like other implementations currently don't enforce this (and allow arbitrary low dust_limit_satoshis - feel free to correct me if I'm wrong here), which means that mutual close transactions may fail to relay (if one of the outputs is above the negotiated dust_limit_satoshis but below Bitcoin Core's dust threshold), which forces node operators to force-close instead.

I have listed the various dust limits Bitcoin Core enforces in #894, here is the summary:

• pay to pubkey hash (p2pkh): 546 satoshis
• pay to script hash (p2sh): 540 satoshis
• pay to witness pubkey hash (p2wpkh): 294 satoshis
• pay to witness script hash (p2wsh): 330 satoshis
• unknown segwit versions: 354 satoshis

We'd like to be able to allow lower values of dust_limit_satoshis (as low as 354 satoshis), but this is only possible if we can ensure that the scriptpubkey sent in shutdown uses segwit.

Unfortunately we're seeing active usage of non-segwit scripts in shutdown on our node, so it could be nice to have a way of enforcing this while preserving backwards-compatibility.

Option 1: feature bit and new requirements

The clean, backwards-compatible way of doing this would be to add a new feature bit that says "I will never send you non-segwit scripts in mutual close". If both peers have set this feature bit, you can allow dust_limit_satoshis down to 354 satoshis, and if they give you a non-segwit script in shutdown it's a spec violation and you can force-close (and ban this peer because they incorrectly implemented this feature).

Option 2: yolo and thanks for all the dust

The second option is a bit more hacky:

• We change the spec to say that only segwit scripts can be sent in shutdown (trivial change, we just remove some lines)
• We change implementations: when you have a non-segwit script in a mutual close tx, you evaluate whether it's ok because it's above 546 sats, otherwise you force-close.

The advantage is that it's a trivial spec change, and you only end up force-closing for cases where you would have to force-close anyway if we changed nothing (because the tx wouldn't relay).

Zooming out and evaluating the risks

Before everyone chimes in on what solution they'd prefer, I think it's worth emphasizing that this edge case is extremely rare.
The channel reserve ensures that both outputs are almost always way above dust thresholds.

The only case where the channel reserve isn't enforced is when a channel has just been created (and the balance is 0 on one side). In order to get into the problematic edge case, the fundee would need to have received only slightly more than the faulty dust_limit_satoshis but less than the dust threshold defined by Bitcoin Core. If it ever received more (enough to go above the channel reserve), he won't be able to go back to a low-enough output to enter this edge case.

I'll wait for some feedback on each implementation's preferred solution before submitting a PR.
@TheBlueMatt @ariard @rustyrussell @Roasbeef @Crypt-iQ