Incorrect fee display + excessively aggressive fee for uncooperative close

[kseiksa]

I had ~3000 bits in this wallet. Two channels unexpectedly went into "CLOSING (uncooperative)", without any user action. I now have 2644 bits.

I see that I have two incoming onchain transactions, from the channel closures - where I received much less than the balance I I thought I had in the channels that were closed. Looking for an explanation as to where my remaining ~350 bits have vanished to, I check the mining fee on those two transactions:

The UI claims "0 bits" for both, which leaves me with the impression my money has simply vanished.

But of course a block explorer tells a different story:

• https://live.blockcypher.com/btc/tx/e266fa3b83cc37e27c04e15f6e198088022b0580135eeeb34ee4ec486940e92f/

• https://live.blockcypher.com/btc/tx/d9ef10ec0a4f2af1babcaa70b4af97d0ca53a762c619314225e4e81f8d07068e/

[kseiksa]

So each transaction paid ~168 bits in fees.

This is a poor user experience for several reasons:

1. the UI misreports this fee as "0 bits", which is confusing (and presumably a bug).

2. the promise of LN is that your funds are always safe, yet spending a significant fraction of a channel's balance, eg. ~20%, on mining fees feels like a loss of funds to the user. It feels like money just evaporated from the wallet. (I realise this is less of an issue with higher value channels, but you want the onboarding experience for new users to be optimal - and most new users will start out playing with $20.)

3. I was able to open the channel for a much lower fee. I remember the UI claiming "3 bits" when I selected the "slow" option - which wasn't slow at all. As a user you imagine the fees to close the channel will be similar, not ~two orders of magnitude greater.

4. On a channel that has received payments, it's understandable that closing uncooperatively entails some urgency - failing to settle the channel on time can result in loss of funds, and most users will understand that this justifies the use of a high fee. But for a channel that has only sent payments, I don't understand the risk - surely all previous channel states (and even a timeout refund of the initial funding TX) are all strictly more favourable to the user than the correct (final) state.

If we can't lose money by being slow (indeed, our security model assumes the wallet might be offline for extended periods of time, right?) ... then why not use a more economic fee? Indeed, why automatically close an uncooperative channel at all? It would be better to let the user close it manually, and to prompt them for the fee to use - the same experience as opening the channel.