Here we return the balance deltas from evaluateHTLCView rather than
passing in references to variables that will be modified. It is a
far cleaner and compositional approach which allows readers of this
code to more effectively reason about the code without having to
keep the whole codebase in their head.
This commit observes that processAddEntry and processRemoveEntry
are only invoked at a single call-site. Here we inline them at their
call-sites, which will unlock further simplifications of the code
that will allow us to remove pointer mutations in favor of explicit
expression oriented programming.
We also delete the tests associated with these functions, the overall
functionality is implicitly tested by the TestEvaluateHTLCView tests.
We had four for-loops in evaluateHTLCView that were exact mirror
images of each other. By making use of the new ChannelParty and
Dual facilities introduced in prior commits, we consolidate these
into two for-loops.
This commit simplifies how we compute the commitment fee rate based
off of the live updates. Prior to this commit we processed all of
the FeeUpdate paymentDescriptors of both ChannelParty's. Now we only
process the last FeeUpdate of the OpeningParty
This commit moves the collection of updates behind a Dual structure.
This allows us in a later commit to index into it via a ChannelParty
parameter which will simplify the loops in evaluateHTLCView.
This commit removes another raw boolean value and replaces it with
a more clear type/name. This will also assist us when we later try
and consolidate the logic of evaluateHTLCView into a single
coherent computation.
In line with previous commits we are progressively removing the
mutateState argument from this call stack for a more principled
software design approach.
NOTE FOR REVIEWERS:
We take a naive approach to updating the tests here and simply
take the functionality we are removing from evaluateHTLCView and
run it directly after the function in the test suite.
It's possible that we should instead remove this from the test
suite altogether but I opted to take a more conservative approach
with respect to reducing the scope of tests. If you have opinions
here, please make them known.
In this commit we observe that the previous commit reduced the role
of this function to a single assignment statement with numerous newly
irrelevant parameters. This commit makes the choice of inlining it at
the two call-sites within evaluateHTLCView and removing the funciton
definition entirely. This also allows us to drop a huge portion of
newly irrelevant test code.
This commit redoes the API and semantics of processFeeUpdate to make
it consistent with the semantics of it's sister functions. This is
part of an ongoing series of commits to remove mutateState arguments
pervasively from the codebase.
As with the previous commit this makes state mutation the caller's
responsibility. This temporarily increases code duplication at the
call-sites, but this will unlock other refactor opportunities.
This commit begins the process of moving towards a more principled
means of state tracking. We eliminate the mutateState argument from
processAddEntry and processRemoveEntry and move the responsibility
of mutating said state to the call-sites.
The current call-sites of these functions still have their *own*
mutateState argument which will be eliminated during upcoming commits.
However, following the principle of micro-commits I opted to break
these changes up to make review simpler.
The purpose of this commit is to begin the process of packing
symmetric fields into the newly introduced Dual structure. The
reason for this is that the Dual structure has a handy indexing
method where we can supply a ChannelParty and get back a value.
This will cut down on the amount of branching code in the main
lines of the codebase logic, making it easier to follow what is
going on.
This commit adds an immutable Filter method to the linked List API.
This is useful because there are several instances wherein we iterate
through the linked List and only process a subset of it in some way
or another.
The objective of this commit is to make paymentDescriptor a private
data structure so we can quarantine it to the lnwallet package.
To accomplish this we had to prevent it from leaking out via the
arguments or return values of the public functions in lnwallet.
This naturally had consequences for the htlcswitch package as we
choose other mechanisms for tracking the data that paymentDescriptor
was responsible for.
Astoundingly, this was highly successful and allowed us to remove
a ton of redundant code. The diff for this commit represents a
substantial reduction in total lines of code as well as extraneous
arguments and return values from key functions.
This also sets the stage for future commits where we actually will
be attempting to rid lnwallet of paymentDescriptor completely.
This is part of a systematic removal of PaymentDescriptor from the public
API of the lnwallet package. This marks the last change needed before we
make the PaymentDescriptor structure private.
Here we add a function that is capable of recovering LogUpdates from
paymentDescriptors and we refactor the lnwallet code to use this
rather than doing JIT inline construction of the LogUpdates.
In this commit we track the ChannelID on the PaymentDescriptor.
This will be useful in upcoming commits that need to be able to
reconstruct lnwire.Message values from PaymentDescriptors as the
Messages that are exchanged to update channel state all include
the ChannelID.
In this commit we introduce a convenience method to LightningChannel
to allow us to quickly grab the channel id. This will be important
in upcoming commits where we need to remember the ChannelID to
reconstruct update messages.
This commit squashes the below operations for a net result where
we have an expanded capability of assessing pending updates. This
is made possible by packing the components into Duals in the prior
commits. We squash the operations to simplify review.
htlcswitch+lnwallet: rename PendingLocalUpdateCount
lnwallet: complete pending update queries API for LightningChannel
lnwallet+htlcswitch: consolidate NumPendingUpdates using ChannelParty
This commit makes the observation that we can cleanly define the
NumPendingUpdates function using a single expression by taking
advantage of the relevant fields being properly packed into Duals.
This is yet another commit that packs a symmetric structure into
a Dual. This is the last one needed for the time being to consolidate
Num{X}UpdatesPendingOn{Y} functions into a single one.
This commit, like the last one packs the update logs into a symmetric
Dual structure. This will allow us to index into them more concisely
in higher order logic.
This commit packs the LightningChannel's localCommitmentChain and
remoteCommitmentChain into a Dual structure for better symmetric
access. This will be leveraged by an upcoming commit where we want
to more concisely express how we compute the number of pending
updates.
This commit introduces a new API to return information on which party opened
the channel using the new ChannelParty type. It does not change the underlying
structure of how we store this information.
This commit breaks the ChannelConstraints structure into two
sub-structures that reflect the fundamental differences in how
these parameters are used. On its face it may not seem necessary,
however the distinction introduced here is relevant for how we
will be implementing the Dynamic Commitments proposal.
This commit introduces a ChannelParty type to LND. It is useful for
consolidating all references to the duality between the local and
remote nodes. This is currently handled by having named struct rows
or named boolean parameters, named either "local" or "remote". This
change alleviates the programmer from having to decide which node
should be bound to `true` or `false`. In an upcoming commit we will
change callsites to use this.
In this commit we opt to make the internal response channel fully
private and instead expose methods for doing resolution. This
prevents internal implementation details from leaking a little bit
better than the previous iteration.
It is common throughout the codebase to send data to a remote
goroutine for processing. Typically, along with the data we are
processing, we also send a one-shot channel where we intend to
listen for the response. This type encapsulates that pattern.
This commit fixes the heuristic we use for identifying the party
that broadcast a Simple Taproot Channel commitment transaction.
Prior to this change we checked if the last script element was an
OP_DROP. However, both the local and remote commitment outputs
have an OP_DROP at the end.
The new approach checks the resolver's SignDescriptor and compares
that key to the keys in the channel's local ChannelConfig. If the
key is the delay key, we know that it is our commitment transaction.
This commit fixes an issue where we did not properly detect and
therefore record the coop close transaction if it used the newer
RBF coop close v2 scheme. This only affects coop closes of
taproot channels today.
This commit fixes#8535 by changing how we assess toSelfAmount inside
the chainWatcher.
In certain cases users may wish to close out channel funds to external
delivery addresses set either during open or close.
Prior to this change we only consider addresses that our wallet is
aware of.
This change now identifies outputs as to_self outputs if the delivery
script matches OR if our wallet is aware of the address. In certain
edge cases it can be possible for there to be more than one output
that matches these criteria and in that case we will return the sum
of those values.
This commit introduces a RecordProducer implementation for Record
that serves as the identity function. This makes it easier for us
to mix Primitive and Dynamic records in the same RecordProducer
collections.
Keagan McClelland