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.
On restarts, notifyBlockEpochs would intermittently attempt to send new
block epoch notifications to clients that had already been shut down,
causing a “send on closed channel” error. This change exits
notifyBlockEpochs upon shutdown so as to prevent this.
