This commit modifies the way we currently interpret errors when sending
payments via the SendToSwitch method. We split the errors into two
broad sections: critical errors which cause us to abandon the payment
dispatch all together, and errors which are transient meaning we should
continue trying to remainder of the returned routes.
Note that we haven’t yet properly implemented all the necessary
measures such as filtering edges that are detected as being temporarily
inactive, etc.
This change should correct erroneous behavior such as continuing to try
all available routes in the face of an invalid payment hash error and
the like.
This commit modifies the way we do path caching. Rather than only
caching within SendPayment, we now cache routes within FindRoutes. This
is more natural as SendPayment eventually calls FindRoute. As a result
of this commit, queries to FindRoute are now properly cached, speeding
up applications which are focused on graph visualization or querying
rather than sending payments.
This commit fixes a bug to wrap up the recently merged PR to properly
handle duplicate FundingLocked retransmissions and also ensure that we
reliably re-send the FundingLocked message if we’re unable to the first
time around.
In this commit, we skip processing a channel that does not yet have a
set remote revocation as otherwise, if we attempt to trigger a state
update, then we’ll be attempting to manipulate a nil commitment point.
Therefore, we’ll rely on the fundingManager to properly send the
channel all relevant subsystems.
This commit adds a select statement for sending on the fundingManager's
arbiterChan and the peer's newChannels channel. This makes sure we won't
be blocked sending on these channels in case of a shutdown.
This commit cleans the fundingManager tests by extracting
most of the common code from the different test cases into
assert methods, making the test cases easier to follow
and distinguish.
It also adds a new test for the case where the peer goes
offline, and the fundingManager must wait for it to come
online before it can send the fundingLocked message and
continue the funding flow.
The fundingManager will register with the server to get notified
when the targetted peer comes online, in case of a failed send
of the fundingLocked message. This is necessary because if the
peer is not connected yet (or was disconnected while we were
waiting for the funding tx to confirm), we cannot continue the
the opening process before the peer successfully has received
the fundingLocked.
This commit adds a listener queue for each peer, that can be used
to queue listeners that will be notified when the targetted peer
eventually comes online.
In the case where the channelLink get started and the number of
updates on this channel is zero, this means no paymenys has been
done using this channel. This might mean that the fundingLocked
never was sent successfully, so we resend to make sure this
channel gets opened correctly.
This commit adds a channel barrier on fundingManager startup for
channels where the opening process is not finished. This fixes
a bug where we after restarting the fundingManager would receive
the fundingLocked message, and crash when trying to close the
non-existing barrier.
In case we received a fundingLocked message after our own opening
process was finished, we would crash with the same error. We
therefore check if the channel barrier exists before we try to
close it.
It also adds functionality to fundingManager that makes it
ignore a fundingLocked message it receives for a channel where
this is already received. This is necessary when we in case of
a reconnection resend the fundingLocked since we cannot be sure
the remote has received it.
The fundingmanager tests are also updated to check that the
fundingLocked messages are sent and handled correcly, and also
exercise the scanarios described above.
The latest combined build fixes some issues with re-orgs, and also
ensure that all transaction sent using the neutrino back-end within
btcwallet are inserted into the unconfirmed transaction bucket on disk.
This ensure that they’ll be reliably be re-broadcast.
This commit fixes an existing bug where we attempted to re-use the same
commitTweak value when creating an HTLC resolution. Instead, we now
create the commit tweak value factoring the key that is to be used for
signing.
In this commit, we extend the help message for `newaddress`
to indicate which address types can be used when directly
funding channels. Additionally, we add some additional text
to the insufficient funding error to detail that we don't have
enough witness outputs.
This commit expands the existing TestForceClose test case to add an
HTLC (outgoing) to Alice’s commitment transaction before force closing.
We then ensure that both the pre-signed timeout transaction _and_ the
sign descriptor to sweep the second-level output are fully valid.
This commit fixes an existing bug within extractHtlcResolutions. The
prior code would use an index to assign the returned
OutgoingHtlcResolutions into a single slice. However, this is invalid
as there are two cases where an HTLC might be skipped: if it’s an
incoming HTLC, or if the HLTC itself is dust from the PoV of the
commitment chain.
To fix this, we now instead use append to add items to the slice. This
ensure that we don’t have any “empty” items in between fully populated
items.
This commit extracts the ending dust adherence test case from the
existing TestForceClose test case into a distinct test case. With this
modification, we now ensure that the two new tests are focused and test
a single scenario at at time.
This commit adds a conditional send on quit to all methods used by
outside sub-systems to the funding manager. This ensures, that in the
case the funding manager is exiting, the caller won’t block
indefinitely.
The new BOLT-11 compliant zpay32 package offers a few new
available options when creating invoices. This commit adds
those options to lncli, such that callers can specify these
when creating payment requests.
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 renames the invoice field Expiry to expiry, and changes
the type from time.Time to time.Duration. Getting the value of the
field will now have to be done using the getter Expiry(), which
will also return the default invoice expiry (3600s) if it is not set
explicitly by the the invoice.
This commit adds fields that are supported by the BOLT-11 invoice
format to the Invoice and PayReq protos. These fields are
timestamp, expiry, fallback address, description and
description hash.
This commit fixes a bug wherein we would use the incorrect csvDelay
when crafting HTLC resolutions after a unilateral channel closure.
Previously, we would always use the csvDelay of the local party, as in
the force close case that’s the correct value. However, a unilateral
channel closure instead requires the _remote_ delay.
This commit fixes an existing bug when crafting the HTLC resolution in
the face of a commitment broadcast. Previously, we we’re using the
localKey which is incorrect, as directly below we properly use the
delayKey when crafting the secondLevelHtlcScript to sign.
This commit adds a new field: MaturityDelay, to the
UnilateralCloseSummary struct. This new field will be required, in an
upcoming update as it’s needed in order to properly sweep the
second-level HTLC outputs after MaturityDelay blocks has passed since
confirmation.
This commit fixes a minor bug (that doesn’t affect anything atm) when
crafting the SignDesc for sweeping breached outputs. Previously, we
would take the p2wkh script and then p2wsh-ify that, placing that into
the SignDesc. This is incorrect as the p2wkh script is “injected” into
the sighash when signing, and thus doesn’t need another encoding layer.
This commit refactors the breach arbiter such that it ignores
commitment values below the remote party's dust limit when trying
to sweep funds after a channel breach. The wallet is now
permitted to pass nil sign descriptors for commitment outputs,
which are then ignored by the arbiter.
All non-dust outputs are accumulated into a single slice of
outputs inside the breach arbiter to simplify the internals.
Doing so permitted a work flow that reduces the total number
of allocations made while processing breaches.
The SpendableOutputs is also expanded to include public methods
to access the witness type and sign descriptors, which was useful
in refactoring the craft justice transaction logic.
