Earlier GetCFilter could return a nil-error along with a nil-filter in
cases where we failed to fetch the filter. We would just ignore the
block causing us to miss potential crucial information.
Now that GetCFilter will return an error in cases where the fetch
failed, the filter will never be nil (even for blocks with only coinbase
transactions), and we'll instead return an error.
We also increase the number of retries for the filter from the default 2
to 5.
This sets the `jstype` option to `JS_STRING` for all `chan_id` fields
in the proto rpc definition. `chan_id` is a 64 bit integer, which is
not natively supported by javascript's floating-point `number` with
only 52 bit precision. Nevertheless, by default protobuf will use the
`number` type for 64 bit integer fields in javascript, which can cause
loss of precision problems with `chan_id`. Explicitly setting the type
for javascript as a string will prevent these issues, and should not
interfere with its use as an identifier.
Because the BestBlock method of ChainIO is not exposed through any
RPC we want to get rid of it so we can use the sweeper outside of
lnd too. Since the chain notifier now also delivers the current best
block we don't need the BestBlock method any more.
The previous limit of 1008 proved to be low, given that almost 50% of
the network still advertises CLTV deltas of 144 blocks, possibly
resulting in routes with many hops failing.
With the introduction of the max CLTV limit parameter, nodes are able to
reject HTLCs that exceed it. This should also be applied to path
finding, otherwise HTLCs crafted by the same node that exceed it never
left the switch. This wasn't a big deal since the previous max CLTV
limit was ~5000 blocks. Once it was lowered to 1008, the issue became
more apparent. Therefore, all of our path finding attempts now have a
restriction of said limit in in order to properly carry out HTLCs to the
network.
We might hit a connection refused error in cases where the peer connects
to us exactly as we try to connect to it. We retry the connection within
a wait predicat, as it should be the case that the other peer
establishes the connection, and the two peers actually connects.
These result in an error with the current release script as is. Those
that want to run `lnd` on their iPhone/iPad can instead use the
`gomobile` bindings.
Notably, solaris/amd64 and illumos/amd64 were added in go1.13. The
others were have been supported previously but were not build targets.
After go1.13, nacl/* will no longer be supported and plan9/* is still
considered experiemental. As a result they are omitted.
In this commit, we fix a bug that would prevent users that had
unresolved contracts at the time of update from starting their nodes.
Before we added the conf commit set, the information needed to
supplement the resolvers was found in the chain action map. As a result,
if the conf commit set is nil, then we also need to check this legacy
data to ensure that we can supplement the resolvers to the best of our
ability based on the available data.
Fixes#3549.
In this commit, we create a new `build/release` package which houses the
build instructions and scripts that we need to do deterministic builds
across Windows, Linux, and MacOS.
With this new system, it's now possible for all `lnd` developers, as
well as users to verify the posted build binaries. This wasn't possible
in prior release as only in Go 1.13 did deterministic builds becomes
easier/possible. See the new `README.md` for further details.
Without this, it was possible for a combination of our balance and max
fee allocation to result in a fee rate below the fee floor causing the
remote party to reject the update and close the channel.
In this commit, we use the recently added `chanvalidate` package to
verify channels once they have been confirmed in the funding manager. We
expose a new method on the `LightningWallet` struct: `ValidateChannels`
which calls the new shared 1st party verification code.
After the channel is fully confirmed in the funding manager, we'll now
use this newly exposed method to handle all validation. As a result, we
can remove the existing validation code in the funding manager, and rely
on the new code in isolation.
