In this commit, the relevant RPC’s have been modified to properly
parse, and pass through the new fee control related parameters for each
of the RPC’s.
For a calls to ListChannels we now only set the
ActiveChannel.Active=true if the link is found by the
htlcswitch. This is done to be able to make it possible
to tell if a newly opened channel has been added to
the htlcswitch, such that we can synchronize on this
during tests before we attempt to close the channel.
This helps catch issues in the RPC tests faster by putting a timeout
on all SendPayment requests. Otherwise, if a payment stalled, the test
would run until the test suite timeout, 10 minutes. Also simplifies
some code with a helper function and using SendPaymentSync where
possible.
In this commit we modify the primary InvoiceRegistry interface within
the package to instead return a direct value for LookupInvoice rather
than a pointer. This fixes an existing race condition wherein a caller
could modify or read the value of the returned invoice.
This commit changes the rpcserver to rely on the new zpay32
package, and support the new payment request options available
in the BOLT-11 invoice format.
This commit modifies the relevant RPC’s to enforce the max payment size
as defined in BOLT-0002. With this commit the largest payment possible
is now 2^32 mSAT, or 4,294,967 satoshis.
This commit adds a new reqQuit channel within SendPayment. The inner
goroutine will use this channel to detect if the request itself has
exited or not. Without this method, we’d possible leak a goroutine if a
client never closed the payment stream.
This commit modifies NewWitnessAddress to return nested p2wkh address.
We do this as this RPC call was put in place to be used within GUI’s to
allow users to deposit funds into their LN wallet. By using nested
p2wkh, we ensure that the generate address that can be used to directly
create channels.
This commit fixes an existing bug that would cause a force closed
channel to stay pending forever. In this instance, if one force closes
a channel while they have a dust output, and restart before the channel
is fully closed, then it wouldn’t have been closed automatically
(within the database) by the autopilot agent.
This commit fixes an issue where if a party force closing a channel,
doesn’t have a non-dust balance, nor any outgoing HTLC’s, then the
channel would never be marked as fully closed within the database.
We ensure that this case is addressed, by inserting a checking to
determine if we have any funds to sweep, marking the channel fully
closed on initial commitment transaction confirmation if not.
This commit adds a bit of a guard to a set of RPC calls. If an RPC call
needs to interact with the server but it hasn’t yet been started. Then
we’ll exit early in order to avoid blocking the call until the server
itself has started.
A recent change to the initialization order of sub-systems within lnd
results in a state where the daemon will wait for the wallet itself to
finish syncing _before_ the server is started. This was interpreted as
a bug by some users, so we’ll make the state of the server more
explicit by returning an error.
This commit ensures that we always clean up the resources that are
created when a new instance of a lnwallet.LightningChannel is
instantiated. The is necessary due to the sigPool that’s now present as
an internal goroutine.
This commit overhauls the way that lnd is created with the goal of
ensuring the chain backends are fully synced up before the daemon
itself starts. The rpcServer has been slightly decoupled from the
server itself s.t we can start the rpcServer independently of the
server. This is required as we’ll now wait (unless we’re in simnet
mode) for the chain to fully sync up before we even _start_ any of the
server’s goroutines.
Previously the integers would either underflow or the floating point
division would result in odd numbers if a node knew of zero channels
within the network graph. We now fix this situation by checking to see
if any channels exist before computing the network stats.
Fixes#211.
In order to not close the payment stream on payment error the additional
field have been added in payment response. Now error from stream Recv()
function means that something has happend inside the client and we unable
to process any payment farther, and error inside the payment response
means, that something wrong has happend with payment itself.
