Minimum funds required in a channel in Lightning? I have noticed that, I cannot exhaust the funds in my channel to one side in lnd. I understand this makes sense so as to have some punishment in case of fraud, but I cannot find the reason for the particular value in lnd (or BOLT).

These are the steps I followed (to reproduce):

$&gt;lncli-alice listchannels
{
"channels": [
    {
        "active": true,
        "remote_pubkey": &lt;bob_pubkey&gt;,
        "channel_point": &lt;channel_point&gt;,
        "chan_id": &lt;chan_id&gt;,
        "capacity": "16777215",
        "local_balance": "370557",
        "remote_balance": "16406475",
        "commit_fee": "183",
        "commit_weight": "724",
        "fee_per_kw": "253",
        "unsettled_balance": "0",
        "total_satoshis_sent": "16506475",
        "total_satoshis_received": "100000",
        "num_updates": "300",
        "pending_htlcs": [
        ],
        "csv_delay": 2016,
        "private": false
    }
 ]
}


After adding an invoice from lncli-bob, and calling queryroutes to create the route to bob from lncli-alice with the amt values 202742 and 202743:

$&gt;cat route_channel_alice_to_bob_amt_202742.txt | lncli-alice sendtoroute --pay_hash=pay)hash -
{
"payment_error": "unable to route payment to destination: TemporaryChannelFailure[...]",
"payment_preimage": "",
"payment_route": null
}

$&gt;cat route_channel_alice_to_bob_amt_202743.txt | lncli-alice sendtoroute --pay_hash=&lt;pay_hash&gt; -
{
"payment_error": "",
"payment_preimage": &lt;payment_preimage&gt;,
"payment_route": {
[...]
 }
}


Given that I have 370557, I do not understand why a payment of 202743 results in insuficcient funds, while 202742 does not. I would like to get to know more about the nature and exact calculation of this minimum value.
Testing further this, I found an answer for it: with current settings for lnd, one cannot transfer an amount such that leaves one of the sides with less that 1% of the channel capacity. This is most likely to prevent that one side to try to commit to an old state, since the punishment would be low. 

For example, in the above case, if the channel capacity is 16777215, and the local_balance is 370557, then the maximum amount possible to transfer is 202742 because 370557-202742 ≃ 0.01*16777215 (it is not exactly 1%, probably due to fees that need to be accounted for).

I double tested this using a channel of capacity 7310000, and having as local_balance 4294965, and again my maximum possible value to transfer is 73143 ≃ 0.01*7310000 (again, not exactly 1% due to fees not accounted for in --amt).

As for the extra value, one would think it is fee_per_weight*172 + feerate*amt (fee per millionths transferred) in the case of the last hop, while they add up in previous hops. But this would mean a higher difference than 143 mSat, or 42mSat, as calculated in the examples above. I am not entirely sure how this difference not to be exactly 1% derives.  

It has to do with the overflow bandwidth (the bandwidth of the channel that is currently being used for other unfinished routes). But still this does not match the numbers exactly. However, just a difference of a hundred satoshis is nothing but a fraction of a cent, so it is not a huge value. Nevertheless, I can't put my finger on the exact calculation...