In this commit, we fix a slight regression that happened when the
sendtoroute RPC call was implemented. As a result of the refactoring,
the debughtlc mode silently broke. In this commit, we fix this by
checking against the zero hash, rather than the length of the payment
hash, as since we use a fixed sized byte slice, it will always be zero.
- Extend SendRequest and QueryRoutesRequest protos
- newRoute function takes fee limit and cuts off routes that exceed it
- queryRoutes, payInvoice and sendPayment commands take the feeLimit inputs and pass them down to newRoute
- When no feeLimit is included, don't enforce any feeLimits at all (by setting feeLimit to maxValue)
In this commit, we modify the logic for the two primary payment related
RPCs to reduce duplication, indentation, and consolidate logic. As a
result, we'll now accept rpcPaymentIntents, turn those into regular
paymentIntents (convert from proto) before finally dispatching via
unified function.
In this commit, we now allow connections to onion addresses due to
recently adding support to properly parse them.
Co-Authored-By: Eugene <crypt-iq@users.noreply.github.com>
In this commit, we fix an existing panic bug related to the recently
added routing hints feature. If it's the case that the remote node
didn't send us their edge, then when we go to compare the public keys to
see if they match, we may attempt to deref an nil pointer.
In order to fix this, we'll instead check the edgeInfo, which is
guaranteed to also exist if the channel was found in the database. As a
defensive step, before we go to actually aces the struct, we'll check
that's it's non-nil and proceed if it is nil.
In this commit, we modify the SignMessage+VerifyMessage slightly in
order to bind the message we're signing to our specific context. We do
this by pre-pending the ascii text "Lightning Signed Message:" to the
msg before we run it through dsha256. Adding this prefix binds the
message to our context in order to avoid accidentally signing a sighash
or the like.
In this commit, we avoid hitting a possible panic in the case that we
were unable to retrieve the link of a channel from the HTLC switch while
determining which channels should be used as routing hints for an
invoice.
This reverts commit 0f90c950daaec7843e305f32d10e36411fb0b47f.
We actually still need to notify the BRAR of a force close, as
otherwise, it doesn't have a signal to exit due to a local force close
event.
This commit fixes a bug where all the HTLC rhash slices in a
ListChannelsResponse would be tied to the loop variable, making them all
take the hash of the last HTLC in the list. This commit fixes it by
making a copy of the slice.
In this commit, we update the testUpdateChannelPolicy to exercise the
recent set of changes within the switch. If one applies this test to a
fresh branch (without those new changes) it should fail. This is due to
the fact that before, Bob would attempt to apply the constraints of the
incoming link (which we updated) instead of the outgoing link. With the
recent set of changes, the test now properly passes.
In this commit, we follow up to the prior commit by ensuring we won't
accept a co-op close request for a chennel with active HTLCs. When
creating a chanCloser for the first time, we'll check the set of HTLC's
and reject a request (by sending a wire error) if the target channel
still as active HTLC's.
In this commit, we fix a bug that at times could cause any dangling
HTLC's to be sent to miner's fees if a user attempted to close out a
channel cooperatively that still had pending HTLC's. We'll first prevent
this at the RPC level by rejecting any attempts to trigger a co-op
channel closure while a channel still have dangling HTLC's.
