We create a deep copy of the channel state as we want to later expose
the data structure to the rpc, which already has helper methods to
marshal this representation to the rpc representation.
This commit fixes a critical race condition in MarkChanFullyClosed and
pruneLinkNode where link nodes could be incorrectly deleted despite
having pending or open channels.
The race occurred because the check for open channels and the link node
deletion happened in separate database transactions:
Thread A: TX1 checks open channels → [] (empty)
Thread A: TX1 commits
Thread B: Opens new channel with same peer
Thread A: TX2 deletes link node (using stale data)
Result: Link node deleted despite pending channel existing
This creates a TOCTOU (time-of-check to time-of-use) vulnerability where
database state changes between reading the channel count and deleting
the node.
Fix for MarkChanFullyClosed:
- Move link node deletion into the same transaction as the channel
closing check, making the check-and-delete operation atomic
Fix for pruneLinkNode:
- Add double-check within the write transaction to verify no channels
were opened since the caller's initial check
- Maintains performance by keeping early return for common case
- Prevents deletion if channels exist at delete time
This ensures the invariant: "link node exists iff channels exist"
is never violated, preventing database corruption and potential
connection issues.
Add the MarkConfirmationHeight method to the OpenChannel struct
to record the block height at which the funding transaction was
first confirmed. Also, introduce the ConfirmationHeight field
to persist this information in the database.
Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
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.
This commit moves most of the code into its own package. It is
the smallest code move possible without moving import cycles and
keeping the changes to the code base as small as possible during
refactor.
This method is not only used by the payment logic so we need to
move it to a generalized place because in the following commits
we move payment related code into its own package.
We introduce a new package paymentsDB and start by moving the
payment specifc errors from the channeldb package to the
paymentsDB package. We also fix linter issues which showed up
due to changing this code part.
We add a context for the query method because the query method
is part of the paymentDB interface and for the SQL case
we will need the context for this method because the native
SQL drivers demand one. So we add it for the kv implementation
here as well so we can then make use of the new interface type.
We move all kv particular code which was in the payments.go file
to the kv related file. Code which will be backend independant
will remain in the payments.go file although only the kv backend
is currently supported.
In the following commits we will gradually unify the current
payment db operations into an interface to later down the road
support both backends (sql+kv).
Replace all usages of the "github.com/go-errors/errors" and
"github.com/pkg/errors" packages with the standard lib's "errors"
package. This ensures that error wrapping and `errors.Is` checks will
work as expected.
This commit adds incoming and outgoing channel ids filter to forwarding history request to filter events received/forwarded from/to a particular channel
This commit simplifies the code of the ForwardingLog.Query method by
removing a confusing for-loop. The for-loop makes it seem as though
multiple events could be encoded under a single timestamp. But from the
time that this forwarding log was introduced, it was never possible to
encode multiple events under the same timestamp and so this loop will
never execute successfully more than once per timestamp and can thus be
removed. This paves the way such that future expansions of the method
can be added easily.
See the initial commit that introduced this code [here](https://github.com/lightningnetwork/lnd/commit/f2cd668bcfb423fb212e78282c786dea166e0168).
In this commit you can see that from the start it was never possible to
have more than one event in a single timestamp since any previous event
in that timestamp would be overwritten. Then see [this commit](https://github.com/lightningnetwork/lnd/pull/4475/commits/97c73706b55fb5520d2f3001dfa13dc1da986972)
where even more protection was added to ensure that each event had a
unique timestamp.
bitromortac