* We address an issue where we would unnecessarily time out bitcoind ZMQ
connections if there are no messages to be read. This would cause
connections to be torn down, which would then trigger the reconnection
logic and prevent us from detecting this issue.
* A new sanity check within the wallet is done to prevent adding
unconfirmed transactions that the wallet has already recognized as
confirmed.
Methods on failure message types used to be defined on value receivers.
This allowed assignment of a failure message to ForwardingError both as
a value and as a pointer. This is error-prone, especially when using a
type switch.
In this commit the failure message methods are changed so that they
target pointer receivers.
Two instances where a value was assigned instead of a reference are
fixed.
lnrpc/rpc.proto: updates RoutingPolicy last_update number
rpcserver: adding LastUpdate field to marshalDbEdge
This commit adds a LastUpdate field to each RoutingPolicy, it will show
the time each RoutingPolicy was updated.
lnrpc: regenerating proto files
In this commit two fields were added to the Channl RPC result in both
open and pending states.
The fields: local_chan_reserve, remote_chan_reserve represents the
reservation the nodes are rquired to keep in both sides of the channel.
This is usefull when calculating the "real" inbound and outbound
liquidity in an accurate way.
This allows us to not depend on external hosts for third-party
dependencies other than the standard hosts: github.com,
google.golang.org, and gopkg.in.
This commit fixes a but where restarting LND at the same process causes
It to fail.
The problem resides in the fact that an array of permissions is
initialized as a package variable and when creating the
RPCServer all subserver permissions are appended while checking for
duplicates.
On subsequent restart this array is left over from the previous run and
being populated again with the same permissions causing a duplicate
error.
The solution is simple, just to extract out the initial permissions to
a separate function and call it from the context is is needed.
In this commit, we create the initial CODEOWNERS file for `lnd`. This
file is a new-ish feature of Github that allows the maintains of a
project to define the individuals who are deemed to be experts of a
particular section of the codebase. Automated review assignment systems
can then use this file to generate required reviewers for a section of
the project. The CODEOWNERS file isn't meant to be a strict guideline,
but instead can be used to ease the burden of finding reviewers for a
particular section of the codebase.
It's also possible to enforce that the CODEOWNERS for a particular
file/package sign-off on relevant changes, thereby blocking review
unless they're involved. However, for now we'll simply use it to guide
the review assignment project, leaving creating blocking review
constraints until a later point if deemed useful.
In this commit, we fix an existing bug that would cause us to be unable
to derive the very first key in a key family if the wallet hadn't
already derived it in the past. This can happen if a user keeps their
same `channel.db`, but restores their wallet resulting in fresh
`wallet.db` state.
This is an existing issue due to the fact that we don't properly
distinguish between an empty key locator, and the very first key in a
`KeyFamily`: `(0, 0)`. Atm, `KeyLoactor{0, 0}.IsEmpty() == True`,
causing us to be unable to retrieve this key in certain cases since we
fall through and attempt address based derivation.
In order to remedy this, we add a new special case (until we upgrade
`KeyLoactor` formats, but needed for legacy reasons) to _try_ a regular
`KeyLoactor` based derivation if we fail to derive via address, and this
is an "empty" key loc. This has been tested in the field and shown to
work, with the one downside that in this "hot swap restoration" case,
we'll hit the database twice to derive the key.
