The new table format for the pay command started to use the
`Millisecond()` method on `time.Duration`. However, this method was only
added in Go 1.13, so this breaks the build for Go 1.12. We replace this
by manual division. `time.Duration` "natively" is in nanoseconds, so we
covert to milli seconds by dividing my `time.Millisecond`, which is
1,000,000.
In this commit, we eliminate an extraneous copy in the `QueryPayments`
method. Before this commit, we would copy each payment from the initial
FetchPayments call into a new slice. However, pointers to payments are
return from `FetchPayments`, so we can just maintain that same reference
rather than copying again when we want to limit our response.
If the server hasn't fully started yet, it's possible that the channel
event store hasn't either, so it won't be able to consume any requests
until then. To prevent blocking, we'll just omit the uptime related
fields for now.
There seems to be a misinterpretation of a variable between the
btcwallet and gozmq libraries. When establish a ZMQ connection, it
expects a timeout, which is used to set read deadlines and determine how
long we should wait before attempting a reconnection. Within btcwallet
and lnd however, this is is interpreted as a polling duration,
explaining the current value of 100ms. Under load, especially on
less-capable hardware, this leads to high resource usage as we get into
a constant reconnection loop. To remedy this, we use a timeout of 5s
instead, which is a much more reasonable value for read timeouts, and is
also what's used for LN peers.
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?)
