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.
