This commit fixes a slight bug in the utxoNursery. Previously, if we
forced closed a channel that was solely funded by the other party
without pushing any satoshis, then the utxoNursery would attempt to
sweep a target output even though it didn’t actually exist. This would
result in the creation of a negative value’d output due to the hard
coded fees currently used in several areas.
To fix his, we now ignore any “output” with a value of zero, when
adding new outputs to the kindergarden bucket.
This commit implements the newly added RPC to decode payment requests
passed over the command line or directly via gRPC.
With this tool, users can now examine payment requests they see in the
wild for diagnostic or debugging purposes.
This commit is similar to the prior commit to channeldb: we no longer
assume that _both_ edges of a channel will always be advertised. Such
an assumption resulted in the inability for a node to sync graph state
since we were previously returning an error when _both_ edges weren’t
found within the graph database.
To remedy this bug, we now carefully ensure that if one edge doesn’t
exist, then we still sync the other.
This commit fixes a prior bug in the graph database due to an invalid
assumption that both channel edges would _always_ be advertised. This
assumption is invalid, as it’s up to a node’s policy if the advertise
their direction of the channel.
The fix for this assumption is straight forward: ErrEdgeNotFound is no
longer a critical error, instead a nil pointer will now be passed into
the passed callback function.
This commit adds a soft-limit for the minimum allowed channel size.
Without this limit a user may inadvertently create an invalid or
unspendable output due to the hard coded fees in a few areas of the
codebase.
This is a temporary measure, and will be removed once we add dynamic
fees into the mix.
This commit augments the server’s response to successful SendPayment
commands by also returning the full path taken in order to fulfill the
payment. With this information, the user now obtains more context about
their payment whcih can be useful when debugging, or just exploring the
capabilities of the daemon.
This commit fixes a prior bug in the wallet triggered by the creation
of a channel using the single funder workflow, but pushing exactly
*half* of the channel over to the other side. The prior logic to
determine who the initiator would result in a disagreement over who
created the channel initially. This wouldn’t manifest until the channel
was attempted to be closed cooperatively. As both side disagreed about
who created the channel they would apply the closing fee to different
outputs, thereby creating mismatched closing transaction. The signature
would fail to validate as the closer will create a different
transaction from that of the responder.
This commit fixes the issue by properly detecting who initially created
the channel.
This commit adds a new error type to the `lnwire` package:
`UnknownMessage`. With this error we can catch the particular case of a
an error during reading that encounters a new or unknown message. When
we encounter this message in the peer’s readHandler, we can now
gracefully handle it by just skipping to the next message rather than
closing out the section entirely.
This puts us a bit closer to the spec, but not exactly as it has an
additional constraint that we can only ignore a new message if it has
an odd type. In a future release, we’ll modify this code to match the
spec as written.
With this commit we now pin the version of lightning-onion we build
against at a particular build on the Sphinx package as the package will
be modified in order to accommodate for future changes in the spec.
This commit fixes a bug introduced by the past attempt to Make Logging
Great Again. Since we unset the curve parameters when reading/writing
the messages, if we have a lingering reference that’s active elsewhere
in the daemon, then we’ll modify that reference. To fix this, we now
explicitly set the Curve parameters in two areas.
A similar commit has been pushed to lightning-onion.
This commit fixes a slight bug in the interaction between the cli
program and the rpcsever itself. With this commit it’s now again
possible to create a channel with a peer that’s identified by its
peerID, instead of only the pubkey.
This commit moves the fetching of active channels from the
contractObserver goroutine up to the Start() method on the
breachArbiter. By doing this, we ensure that the user receives an error
(under the current set up) if the btcd node that lnd is connected to
doesn’t have their txindex enabled.
This commit modifies the closeObserver goroutine to ensure that a close
summary has been inserted into the database before signalling any
observers that a unilateral channel closure was detected. This fixes a
slight bug where a peer would force close a channel, but we wouldn’t
properly detect that and clean up the channel state if had a failed
cooperative channel closure.
This commit modifies the login of sent/recv’d wire messages in trace
mode in order utilize the more detailed, and automatically generated
logging statements using pure spew.Sdump.
In order to avoid the spammy messages due to spew printing the
btcec.S256() curve paramter within wire messages with public keys, we
introduce a new logging function to unset the curve paramter to it
isn’t printed in its entirety. To insure we don’t run into any panics
as a result of a nil pointer defense, we now copy the public keys
during the funding process so we don’t run into a panic due to
modifying a pointer to the same object.
This commit modifies the ListInvoice RPC to also return the encoded
payment request in the response. With this change it’ll be possible to
always obtain the encoded payment for any invoice, rather than only
being able to obtain it directly after the creation of an invoice.
This commit modifies the logic of the closeObserver slightly to not
incorrectly mark the broadcast of the commitment transaction triggered
by a cooperative channel closure as an unprompted broadcast.
This commit fixes a bug in the test data that was uncovered due to the
recent bug fix within the AddChannelEdge method within the ChannelGraph
struct of channeldb.
The storage and assertion of unique channel ID’s wasn’t correct due to
bug in the channeldb which caused the defect in the test data to go
unnoticed.
This commit adds support for pushing funds during the funding process
to the helper method in the integration testing framework.
Additionally, we also modify the simple testBasicChannelFunding test to
also push over an amount in order to test the functionality within the
daemon.
This commit modifies our key rotation slightly to match the test
vectors within the BOLT08 specifications. Before this commit, we were
rotating one message before the rest of the implementers. This
implementation divergence was possibly due to the section of the spec
describing the rotations being a bit ambiguous.
A future PR to the lightning-rfc repo will make the spec more explicit
to avoid situations like this in the future.
This commit modifies the ConnectPeer RPC call and partitions the
behavior of the call into two scenarios: the connection should be
persistent which causes the call to be non-blocking, and the connection
should only attempt to connect once — which causes the call to be
blocking and report any error back to the caller.
As a result, the pendingConnRequest map and the logic around it is no
longer needed.
This commit adds daemon level support for pushing funds as part of the
single funder channel workflow. This new feature allows the user to
open a channel and simultaneously make a channel at the same time which
can improve the UX when setting up a channel for the first time.
This commit removes the remote_funding field from the OpenChannel
message as dual funding channels aren’t yet supported at the wire level
within the spec (although the daemon is able to handle them properly).
In place we now add the ‘push_sat’ field which allows the initiator to
push over a certain amount to the responder as part of the initial
state.
This commit adds support to the wallet’s internal funding workflow for
pushing a certain amount of BTC to the responder’s side for a single
funder workflow as part of the first commitment.
This commit adds a new paramter to the initial channel creation:
‘PushSatoshis’. This new field allows the funder of a channel to push
over a certain amount to the responder as part of the initial channel
state. This ability creates a new streamlined UX of finalizing a
payment as a part of the channel creation.
This commit seems to fix a sporadic error within the integration tests
which would at times cause a panic when a payment as initiated.
This issue was with the way were deleting from the middle of the slice
of unvisited nodes within the graph. Assigning the last element to the
middle would at times cause a panic the last element may be nil. To fix
this, we now manually copy every item over by one, preserving the order
of the slice, and possibly fixing the panic once and for all.
With this commit we have gained a new interaction tests which excursus
all the possible multi-hop error cases aside from:
* sphinx packet corruption
The case can’t be adequately tested with the current integration
testing framework as we can’t arbitrary modify packets en route to
peers within the proto test network. In a future commit, the p2p test
framework whcih has been started by andrew.shvv will be used to ensure
proper handling of this error.
This commit adds a critical capability to the daemon: proper handling
of error cases that occur during the dispatch and forwarding of
multi-hop payments.
The following errors are now properly handled within the daemon:
* unknown payment hash
* unknown destination
* incorrect HTLC amount
* insufficient link capacity
In response to any of these errors, an lnwire.CanceHTLC message will be
back propagated from the spot of the error back to the source of the
payment. In the case of a locally initiated HTLC payment, the error
will be propagated back to the client which initiated the payment.
At this point, proper encrypted error replies as defined within the
spec are not yet implemented and will be fully implemented within a
follow up PR.
This commit fixes an unnoticed bug within the htlcSwitch. Previously
when a peer when offline, the interface+links for that particular peer
were removed from the HTLC switch so we wouldn’t dispatch immediate
HTLC’s in that direction. However, the onion index for that interface
wasn’t also cleared. This would result in a deadlock when a payment
were to be attempted to be forwarded to a peer who recently went
offline.
To fix this issue, we now properly purge the onionIndex of the entry
corresponding to the interface that has gone offline.
This commit modifies the logic around adding cancel entries to the
update log for the commitment state machine slightly by also including
the r-hash of the HTLC that’s been cancelled in the entry for the
cancellation. With this change, we can accurately track which HTLC is
being cancelled within outer sub-systems.
This commit adds a new HTLC error type: IncorrectValue. This error type
is to be used when an HTLC that’s extended to the final destination
does not match the expectation of the destination.
Pervasively we would include the length of the MAC in the length prefix
for cipher text packets. As a result, the MAC would eat into the total
payload size. To remedy this, we now exclude the MAC from the length
prefix for cipher text packets, and instead account for the length of
the MAC on the packet when reading messages.
This commit ensures that any extra nodes that were created as part of
the integration tests are shutdown at the end of the test after it
completes successfully. This should speed up the tests as we’ll no
longer have lingering nodes in the background of the test consuming
resources.
This commit adds an additional test case to the `testSingleHopInvoice`
test in order to exercise the proper parsing and dispatching of encoded
payment requests using the zpay32 encoding scheme.
With this test we ensure that the daemon properly encodes payreq’s upon
the creation of invoices, and also that the SendPayment RPC is able to
parse the payment request and properly complete a payment based off of
one.
This commit alters the new HTLC cancellation logic to instead allow the
canceller of an HTLC to cancel the HTLC by the payment hash rather than
the index of the HTLC.
This commit adds a new field to the CancelHTLC message which describes
the event that led to an HTLC being cancelled up stream.
A new enum has been added which describers the “why” concerning the
cancellation of the HTLC. Currently the encoding and back propagation
of the errors aren’t properly implemented as defined within the spec.
As a result the current error types provide to privacy as the error are
in plain-site rather doing being properly encrypted.
This commit adds the ability to send/recv HTLC cancellation to the
commitment state machine. Previously this feature had been
unimplemented within the state machine, with only adds/settles working.
With this change, there’s now now no concept of “timing” out HTLC’s,
only the cancellation of HTLC’s which may be triggered for various
reasons.
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.
The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
This commit implements so minor changes in formatting: character column
limits, error returning, scoped, errors. The aforementioned changes are
a bit of minor clean up after the merge of the latest PR in order to
ensure the new code in the file conforms to the code style in the rest
of the project.
As we’re switching to a more up to date btcd branch that properly
guards the activation of the soft-forks we rely on, we’ll also need to
ensure the two soft-forks have activated.
This commit alters the configuration parsing a bit along with the
documentation to expect the RPCHost configuration paramter to also have
the target port specified. If the port isn’t included, then the default
btcd RPC port for that chain is used.
Additionally, within the integration testing framework, when creating
the lnd nodes, we now use the configuration from the btcd harness to
set the proper RPC host.
This commit adds a much needed feature to the daemon, namely the
ability to force close a channel while the source daemon doesn’t have
an active connection to the counter party. Previously this wasn’t
possible as ALL channel closures were routed through the htlcSwitch
which is only able to trigger a channel closure if the peer is online.
To remedy this, if the closure type is “force” then, we now handle the
channel closure and related RPC streaming updates from the call handler
site of the RPC itself. As a result, there are now only two htlcSwitch
channel closure types: breach, and regular. The logic that’s now in the
rpcSever should likely be refactored into a distinct sub-system, but
getting the initial functionality in is important.
Finally, the channel breach integration test has been modified to skip
connection the peers before attempting the forceful channel closure of
a revoked state as the remote peer no longer needs to be online.
This commit adds a short sleep before a channel assertion in the
`testMaxPendingChannels` test. This sleep serves to give the nodes
enough time to propagate the new channel announcement over the
authenticated gossip system. Without this sleep, the call may be issued
in a state wherein only half of the channel announcement has fully
propagated.
This commit modifies the generated response to an “AddInvoice” RPC by
including an encoded payment request in the response. This change gives
callers a new atomic piece of information that they can present to the
payee, to allow completion of the payment in a seamless manner.
This commit adds a new package “zpay32”: which is used within the
daemon to encode/decode payment requests. A payment request currently
consists of: the public key of the payee, the payment hash to use, and
finally the amount to send over the network. The encoded payment
request consists of the mentioned fields concatenated to each other, a
cc32 checksum is added, then the blob is finally encoded using zbas32.
I call the resulting scheme “zpay32”.
A number of extensions may be explored in future commits including
adding a version byte, adding “hint” routing information,
cryptographically signed receipts and more,
This commit slightly refactors the logic for the new outgoing payment
related RPC’s to more closely match the style of the rest of the
codebase. Additionally the tests have been updated to reflect the
changes to the protos of the new RPC’s.
This commit modifies the error propagating behavior within the
HasChannelEdge struct. Rather than exiting the function early when a
single edge isn’t found, we instead continue to also possibly retrieve
the second directional edge.
With this change, we avoid a potential infinite gossiping loop in the
routing package that would result if we’d seen one edge but not the
other. In this case the timestamps returned for *both* edges would
always be zero, causing the daemon to always accept and rebroadcast the
announcement putting all other connected lnd’s into the same loop.
This commit modifies the new payment module within the database to
match the coding style of the rest of the package and the project as a
hole. Additionally, a few fields have been renamed, and the extra
timestamp added to the OutgoingPayment struct has been removed as
there’s already a CreationTime field within the Invoice struct that’s
embedded within the OutgoingPayment struct.
This commit fixes s bug in the breachArbiter which was introduced
during the change that added the live channel hand off from an active
peer. Rather than closing the settle channel of the _older_
breachObserver, the settle channel of the newer beachObserver was being
closed. This would result in a panic once the channel itself was
actually settled as the channel would be closed again.
To fix this bug, we now properly close the channel of the old settle
signal instead of the new one.
This commit partially rectifies a quick hack that was previously thrown
in to address an issue discovered due to possible state inconsistencies
between an active channel object and the daemon’s breachAbrbiter.
A prior commit has modified the interaction between the peer and the
breachArbiter to eliminate the state in consistency. Therefore, we no
longer need to access the database to ensure that we’re observing the
latest channel state in order to correctly make a decision about
whether a broadcast commitment transaction is a breach or not.
This commit modifies the interaction between the breachArbiter and the
peer struct such that the breachArbiter _always_ has the latest version
of a contract.
Prior to this commit once we connected out to a peer which we had an
active contract with and the breachArbiter was watching, we’d have two
copies of the channel in memory, instead of just a single one. This was
wasteful and caused some duplicated log messages due to two instances
of the channel being active.
This commit adds support for the newly added channel graph related
commands: describegraph, getchaninfo, getnodeinfo, queryroute, and
finally getnetworkinfo.
Olaoluwa Osuntokun