In this commit, we avoid hitting a possible panic in the case that we
were unable to retrieve the link of a channel from the HTLC switch while
determining which channels should be used as routing hints for an
invoice.
In this commit, we add a `private` field to the `AddInvoice` RPC's
request to denote whether the invoice being created should include
routing hints for private channels to assist the payer in reaching the
destination.
Before this commit, if an invoice encoded multiple `r` fields, we would
decode them as one single route. We fix this by allowing an invoice to
store multiple routes.
In this commit, we modify our path finding algorithm to take an
additional set of edges that are currently not known to us that are
used to temporarily extend our graph with during a payment session.
These edges should assist the sender of a payment in successfully
constructing a path to the destination.
These edges should usually represent private channels, as they are not
publicly advertised to the network for routing.
In this commit, we introduce the ability for payment sessions to store
an additional set of edges that can be used to assist a payment in
successfully reaching its destination.
In this commit, we add a new field of routing hints to payments over the
Lightning Network. These routing hints can later be used within the path
finding algorithm in order to craft a path that will reach the
destination succesfully.
In this commit we update to the latest version of btcwallet which will
properly detect bitcoind rejections when attempting to retransmit
unmnined transaction on restart. Additionally, we'll now remove any
transaction that are rejected from the mempool at broadcast time.
Related to #1030.
In this commit, we fix a recently introduced bug which can result in a
panic when bitcoind nodes without a txindex active are started. The
issue was that we would still defence the transaction's blockhash, which
would be nil if we detected that the backend didn't have the txindex
active.
This reverts commit 0f90c950daaec7843e305f32d10e36411fb0b47f.
We actually still need to notify the BRAR of a force close, as
otherwise, it doesn't have a signal to exit due to a local force close
event.
According to install.md, the minimum version of Go supported at the
moment is 1.9, so update the Go version referenced in Contribution
Checklist to 1.9 as well.
Now that we have a fallback method for when the transaction index is not
enabled, its requirement to be enabled for a full node is no longer
needed, so we can safely remove this check.
Before this commit, we relied on the need of full nodes to enable the
transaction index. This allowed us to fetch historical details about
transactions in order to register and dispatch confirmation and spend
notifications.
This commit allows us to drop that requirement by providing a fallback
method to use when the transaction index is not enabled. This fallback
method relies on manually scanning blocks for the transactions
requested, starting from the earliest height the transactions could have
been included in, to the current height in the chain.
This commit extends the test to exercise a scanario that wasn't properly
covered, by registering for a confirmed spend notification for a
historical spend. We also extend the test to make sure it handles buried
spends properly.
This commit fixes a recently introduced bug in the btcdnotifier, where
we would skip all spend clients waiting for a confirmed spend in
txUpdates. The regular case where a spend is included in a new block was
correctly handled in onBlockConnected, but the txUpdates queue is also
used for confirmed spends during rescans, which we would miss. This
commit fixes that by checking if the tx update is confirmed or
unconfirmed, and acts accordingly.
This commit fixes a bug where all the HTLC rhash slices in a
ListChannelsResponse would be tied to the loop variable, making them all
take the hash of the last HTLC in the list. This commit fixes it by
making a copy of the slice.
In this commit, we fix an existing flake in the integration tests. If it
was the case that Alice didn't yet know of all the channels, then the
payment attempt below would fail at times, depending on other timing
factors in the test. We fix this flake by waiting for Alice to learn of
all channels before we proceed to the actual testing logic.
