Estimate Fee says output is dust too often

[stridentbean]

Background

I'm trying to estimate fees and create a UI that has a slow/med/fast switch for sending funds. However, I'm running into an issue with an edge case. Say, I only want to send 10k sats, but my wallet has 269377 sats. If I want a conf target of 1000 blocks, everything works great. However, if I want a conf target of 1 block. The rpc spits out an "output is dust" error. This leads me to understand that the estimate fee rpc takes the fee out of the original 10k sats and if the fee is to high, output is dust.

Problem is, my whole wallet has 269377 sats, so I should still be able to send 10k, no matter the fee. I'm wondering two things.

1. Was this design intentional? What is the benefit?
2. If it was intentional, is there an easy trick I could use to get a better estimate where the fee isn't included.

Extra notes
lncli estimatefee '{"367GH1G58Vu87ZcLda3TRWdwN5atce3eda":1000}' --conf_target 100 succeeds even with a smaller output.

lncli estimatefee '{"367GH1G58Vu87ZcLda3TRWdwN5atce3eda":269377}' --conf_target 100 fails with
[lncli] rpc error: code = Unknown desc = insufficient funds available to construct transaction

Your environment

• version of lnd
  lncli version 0.6.1-beta commit=v0.6.1-beta
• which operating system (uname -a on *Nix)
  Linux lnd 4.14.70-v7+ Fixing some README typos #2 SMP Wed Sep 19 07:49:26 UTC 2018 armv7l Linux
• version of btcd, bitcoind, or other backend
  Bitcoin Core (bitcoind) RPC client version v0.17.1
• any other relevant environment details
  bitcoind and lnd are running in docker containers
  raspberry pi 3b+

Steps to reproduce

Load some btc into a new mainnet node. Make sure there is only one utxo.

Expected behaviour

lncli estimatefee '{"367GH1G58Vu87ZcLda3TRWdwN5atce3eda":10000}' --conf_target 1 Should return successfully.

Actual behaviour

lncli estimatefee '{"367GH1G58Vu87ZcLda3TRWdwN5atce3eda":10000}' --conf_target 1
Returns error [lncli] rpc error: code = Unknown desc = transaction output is dust

[Roasbeef]

Found the culprit, we're using the actual effective fee rate rather than the relay fee to compute dust within the EstimateFee call. This explains also explains why varying the conf target affects what it determines to be dust.