In order to help external components to query the custom records of a
channel we need to expose the remote peer pub key. We could look-up
custom records based on the funding outpoint, but that relation is
established when receiving the ChannelReady message. The external
components may query the AuxChanState before that message is received,
so let's make sure the peer pub key is also available.
We introduce this new interface with the purpose of injecting and
handling custom records on the init message, and also notifying
external components when receiving the ChannelReady or
ChannelReestablish message.
In this commit, we replace all instances of spew.Sdump in the lnwallet
package and its subpackages with lnutils.SpewLogClosure. This change
ensures that expensive debug dump operations are only performed when the
log level actually requires them.
Use the new feature of Go 1.24, fix linter warnings.
This change was produced by:
- running golangci-lint run --fix
- sed 's/context.Background/t.Context/' -i `git grep -l context.Background | grep test.go`
- manually fixing broken tests
- itest, lntest: use ht.Context() where ht or hn is available
- in HarnessNode.Stop() we keep using context.Background(), because it is
called from a cleanup handler in which t.Context() is canceled already.
To make sure we don't cause force-closures because of commit sig
mismatches, we add a test case to verify that the retransmitted HTLC
matches the original HTLC.
We update the lightning channel state machine in some key areas. If the
noop TLV is set in the update_add_htlc custom records then we change the
entry type to noop. When settling the HTLC if the type is noop we credit
the satoshi amount back to the sender.
We add a new update type to the payment descriptor to describe this new
type of htlc. This type of HTLC will only end up being set if explicitly
signalled by external software.
Fixes another flake in the unit-race test: Sometimes we miss startup
events if there's a high CPU load (in CI for example).
To avoid that, we register our subscriber before starting the state
machine.
These tests previously only worked because we didn't properly wait for
all transitions to come in. We fix them by correctly asserting the
expected number of state transitions.
This fixes the actual flake: We didn't wait for next iterations to _not_
come in, so depending on timing, we could read another transition in a
second run.
But making sure we expect all transitions at the same time and then make
sure no further transitions come in makes this not depend on time.
The param previously was unused so this was likely an oversight or
copy/paste error.
This does not change any behavior, as the method was always called with
the constant previously used. But it makes things more explicit.
In this commit, we fix a flake in the
`TestRbfCloseClosingNegotiationLocal/send_offer_rbf_wrong_local_script`
test.
This flake can happen if the test shuts down _before_ the state machine
is actually able to process the sent event. In this case, the
expectations are triggered, and we find that the error isn't sent.
To resolve this, we create a new wrapper function that'll use a sync
channel send to assert that the error has been sent before we exit the
test.
An address imported using ImportTapscript doesn't provide a private key
so it can't satisfy waddrmgr.ManagedPubKeyAddress interface. So we don't
return an error for imported addresses.
Fix https://github.com/lightninglabs/loop/issues/923
In this commit, we fix a flake in the rbf loop sub-test for the
TestRbfCloseClosingNegotiationLocal test case.
The fix here is that when we go from ClosePending for an RBF iteration
loop, we first transition to LocalCloseStart. However we only do this
extra transition if we're doing an iteration (starting from ClosePending).
To fix this, we add a new bool that tracks if this is an iteration or
not. We can then also eliminate the extra assertion at the end, as we'll
terminate in `ClosePending` which is checked by
`assertLocalClosePending()` in `assertSingleRbfIteration`.
Fixes https://github.com/lightningnetwork/lnd/issues/9526.
In this commit, we fix a flake in the
`TestRbfChannelFlushingTransitions/early_offer` test. The fix is simple:
this is actually an "iteration", as we have a self transition to the
ChannelNegotiation state first. We also don't need to send the
remoteOffer, so we set `sendInit` to false. The offer still needs to be
passed in to ensure that the assertions work however.
We'll properly handle a protocol error due to user input by halting, and
sending the error back to the user.
When a user goes to issue a new update, based on which state we're in,
we'll either kick off the shutdown, or attempt a new offer. This matches
the new spec update where we'll only send `Shutdown` once per
connection.
In this commit, we update the RBF state machine to handle early offer
cases. This can happen if after we send out shutdown (to kick things
off), the remote party sends their offer early. This can also happen if
their outgoing shutdown (to ACK ours) was delayed for w/e reason, and we
get their offer first.
The alternative was to modify the state machine itself, but we feel that
handling this early case is better in line with the Robustness principle.
In this commit, we implement a special case for OP_RETURN scripts
outlined in the spec. If a party decides that its output will be too
small even after the dust check, then they can opt to set it to zero by sending an `OP_RETURN` as their script.
In this commit, we implement the latest version of the RBF loop as
described in the spec. We remove the self loop back based on sending or
receiving shutdown. Instead, from the ClosePending state, we can trigger
a new loop by sending SendOfferEvent (we bump), or OfferReceivedEvent
(they bump).
We also update the rbf state machine w/ the new close addr logic. This
log ensures that the remote party always sends our current address, and
that if they send a new address, we'll update our view of it, and
counter sign the correct transaction.
We also add a CloseErr state. With this new state, we can ensure that
we're able to properly report errors back to the RPC client, and also
optionally force a reconnection or send a warning to the remote party.
