In this commit, we publicly export the `word` field as it makes it
easier to programmatically interact with the package when attempting to
re-derive proper `cipherseed` instances. We also add a new `Index` field
as well to provide additional context for programmatic manipulating of
seeds.
We stopped requesting this from other nodes as it is very expensive as
the graph continues to grow. In this commit we will also stop
responding, as nodes are recommended to begin using the `gossip_queries`
and upcoming `extended_gossip_queries` to reconcile missing graph data.
A cleanup closure is not included when an error is returned, causing the
defer to execute and triggering the following panic:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x105da38]
goroutine 1 [running]:
github.com/lightningnetwork/lnd.Main(0x2083e40, 0xc0004f6db0)
/home/user/lnd/lnd.go:208 +0x2bfa
main.main()
/home/user/lnd/cmd/lnd/main.go:14 +0x26
If nodes return a channel policy related failure, they may get a second
chance. Our graph may not be up to date. Previously this logic was
contained in the payment session.
This commit moves that into global mission control and thereby removes
the last mission control state that was kept on the payment level.
Because mission control is not aware of the relation between payment
attempts and payments, the second chance logic is no longer based
tracking second chances given per payment.
Instead a time based approach is used. If a node reports a policy
failure that prevents forwarding to its peer, it will get a second
chance. But it will get it only if the previous second chance was
long enough ago.
Also those second chances are no longer dependent on whether an
associated channel update is valid. It will get the second chance
regardless, to prevent creating a dependency between mission control and
the graph. This would interfer with (future) replay of history, because
the graph may not be the same anymore at that point.
This flake was caused by the rpcserver receiving a CloseChannel request
before Alice's channel event subscription request, causing Alice to miss one
notification. As a result, we move Alice's subscription to the beginning of the
test.
Additionally, we add a check to ensure the opening notifications are
received in the right order.
This commit adds the pubkeyIndices map to the distanceHeap to avoid
duplicate entries on the heap. This happened in the earlier iteration
of the findPath algorithm and would cause the driving loop to
evaluate already evaluated entries when there was no need.
This commit modifies the nodeWithDist struct to use a route.Vertex
instead of a *channeldb.LightningNode. This change, coupled with
the new ForEachNodeChannel function, allows the findPath Djikstra's
algorithm to cut down on database lookups since we no longer need
to call the FetchOtherNode function.
* 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.
