[bug]: can't send sats FAILURE_REASON_INSUFFICIENT_BALANCE with 0 fee?

[ShadwDrgn]

Background

I'm trying to send my friend 1900 sats. I have an open channel with him. There are 2000 sats on my side of the channel.
The calculated fees for the invoice he gave me are "0 + 0 sat" so i defifnitely have the funds. Why am I getting insufficient balance failures?

Payment hash: ba298228811a13a0262047aec3b94437938943491eb22baea0ad4660f15edeb8
Description: SUPER ENCRYPTION
Amount (in satoshis): 1900
Fee limit (in satoshis): 95
Destination: 02738eab929e3b9585ef70bce4266f881995ad14da0f379cdd6fbc00db122ae3dc
Confirm payment (yes/no): yes
+------------+--------------+--------------+--------------+-----+----------+----------+-------+
| HTLC_STATE | ATTEMPT_TIME | RESOLVE_TIME | RECEIVER_AMT | FEE | TIMELOCK | CHAN_OUT | ROUTE |
+------------+--------------+--------------+--------------+-----+----------+----------+-------+
+------------+--------------+--------------+--------------+-----+----------+----------+-------+
Amount + fee: 0 + 0 sat
Payment hash: ba298228811a13a0262047aec3b94437938943491eb22baea0ad4660f15edeb8
Payment status: FAILED, reason: FAILURE_REASON_INSUFFICIENT_BALANCE

Your environment

v0.15.4-beta
linux (docker)
bitcoind: v23.0.0

• any other relevant environment details

Steps to reproduce

have someone send you an invoice for 1900 of the 2000 remaining local sats in your channel
try to send the payment with sendpayment
???
profit

Expected behaviour

sats successfully send because 0 + 0 + 1900 is less than 2000 available balance
also shouldn't amount + fee be 1900 + 95 instead of the 0 + 0 it shows? Note that 1900 + 95 is STILL less than 2000 so should have sent.

Actual behaviour

FAILURE_REASON_INSUFFICIENT_BALANCE

[alexbosworth]

how about the reserve?

[amtexugo]

Hi bro, I m with the same problem. Which folder is file to config this?

[ShadwDrgn]

        "local_constraints": {                                     
            "csv_delay": 144,                                  
            "chan_reserve_sat": "1210",                            
            "dust_limit_sat": "354",                             
            "max_pending_amt_msat": "119790000",                   
            "min_htlc_msat": "1",                                         
            "max_accepted_htlcs": 483                               
        },                                                        
        "remote_constraints": {                                          
            "csv_delay": 144,                                     
            "chan_reserve_sat": "1210",                        
            "dust_limit_sat": "354",
            "max_pending_amt_msat": "119790000",
            "min_htlc_msat": "1",
            "max_accepted_htlcs": 483

reserve seems to be 1210, but we ALSO tried doing 790 sats which would have left enough for reserve (unless i'm misunderstanding reserve) and it said inssufficient funds as well

Is there documentation on how to determine the actual spendable amount of sats each person has on their side of the channel? Perhaps I'm just misunderstanding how to read the json above.

[amtexugo]

Hi bro, I m with the same problem. Which folder is file to config this?

[Roasbeef]

In addition to the reserve, you need be able to pay for the HTLC (that creates the pending payment) in the first place as you're the initiator. The amount required here depends on the fee rate of the commitment transaction itself. So in addition to the reserve, enough needs to be remaining to pay for the fee to broadcast the commitment transaction.

If you send a smaller amount (below that dust_limit_sat value), then an "physical" HTLC is never created on the commitment transaction. So you'd be able to bypass the required extra fee, but would still run into the reserve issue.

[ShadwDrgn]

Thanks. is there a way to calculate the total I can send safely (above dust limit) based on the listchannels or any other commands output assuming their are no routing nodes because it's directly to someone i have a channel with?

The fees in every prior transaction we sent ended up being 0. the channel balance never changed after any of our successful transactions. Our fee settings were like base fee 1 and fee rate 0.0001% I think. Sadly the channel is closed now so i can't look much up. I ahve the listchannel output but not a fee json object output of any kind.

[Roasbeef]

The calculation is a bit fuzzy, since you need to know things like the raw weight/size of an HTLC transaction. We do have logic to compute this value (we use it to reject HTLCs like this to avoid getting the channel in a bad state), but it isn't yet exposed over the RPC interface. Ideally we have something like sendable_balance or w/e exposed on the RPC interface.

The fees in every prior transaction we sent ended up being 0. t

So this is an off chain fee. In my comment above, I'm referring to an on chain fee. Put simply, an HTLC increases (the pending payment) the size of a commitment transaction, the initiator needs to be able to pay for the extra size to target a set fee rate (say 1 sat/byte).

[saubyk]

Moving this issue to a discussion