This is a preparation for enabling the REST interface on routerrpc.
It provides REST clients that don't support server-side streaming
via keep-alive connections to use the streaming endpoint in the
typical request/response pattern. The url just needs to contain
?no_inflight_updates=true and only the terminal response is sent
back before the connection is closed.
In this commit, we move to clamp down somewhat on the max invoice size
after the limit was removed as part of the mpp changes. In #4210, it was
reported that a value of -1, would underflow and end up as 18 million
BTC, which would trip checks w.r.t the max expressible value in mSAT.
In this commit, we clamp things down to 100k BTC, which should be more
than enough for anybody.
Fixes#4210.
This enforces the _actualized_ fee rate of the commitment transaction,
rather than the fee floor used for estimation. The new value of 250
sat/kw corresponds to 1 sat/byte, rather than 253 which is only rounded
up during estimation to account for the fact that BOLT 3 rounds down to
the nearest satoshi and that the vbyte fee estimation is lossy.
Previously we would incorrectly fail to sign the next commitment even
though the fee was technically high enough. Restarting with this commit
should solve the issue as long as the channel hasn't already gone to
chain.
The message in the response stream changed. Rename the calls themselves,
to prevent older applications from getting decode errors. Especially
troublesome is the case where the request is executed (send payment),
but the application can't read the outcome (payment sent or not?)
Modifies some of the older mailbox tests that were left untouched as of
PR #4174 to use the new mailbox test context. This ensures that the
config members of each mailbox's config are properly initialized. In
certain instances where travis is slow, this would cause test panics.
This commit reverts cb4cd49dc8d3b0255afe9ff29af9c46c2dbb2c98 to bring
back the insufficient local balance failure.
Distinguishing betweeen this failure and a regular "no route" failure
prevents meaningless htlcs from being sent out.
A peer's remote address isn't known to us if we accepted the connection
over Tor, instead we know the address the onion service used to dial to
lnd. If said peer also doesn't have any advertised addresses, then we
don't have enough information to attempt a reconnect, so we avoid doing
so. Allowing the reconnection to happen isn't necessarily an issue, but
not allowing it prevents the configured SOCKS proxy from dialing to
private addresses.
