This commit fixes a bug wherein we would use the incorrect csvDelay
when crafting HTLC resolutions after a unilateral channel closure.
Previously, we would always use the csvDelay of the local party, as in
the force close case that’s the correct value. However, a unilateral
channel closure instead requires the _remote_ delay.
This commit fixes an existing bug when crafting the HTLC resolution in
the face of a commitment broadcast. Previously, we we’re using the
localKey which is incorrect, as directly below we properly use the
delayKey when crafting the secondLevelHtlcScript to sign.
This commit adds a new field: MaturityDelay, to the
UnilateralCloseSummary struct. This new field will be required, in an
upcoming update as it’s needed in order to properly sweep the
second-level HTLC outputs after MaturityDelay blocks has passed since
confirmation.
This commit fixes a minor bug (that doesn’t affect anything atm) when
crafting the SignDesc for sweeping breached outputs. Previously, we
would take the p2wkh script and then p2wsh-ify that, placing that into
the SignDesc. This is incorrect as the p2wkh script is “injected” into
the sighash when signing, and thus doesn’t need another encoding layer.
This commit refactors the breach arbiter such that it ignores
commitment values below the remote party's dust limit when trying
to sweep funds after a channel breach. The wallet is now
permitted to pass nil sign descriptors for commitment outputs,
which are then ignored by the arbiter.
All non-dust outputs are accumulated into a single slice of
outputs inside the breach arbiter to simplify the internals.
Doing so permitted a work flow that reduces the total number
of allocations made while processing breaches.
The SpendableOutputs is also expanded to include public methods
to access the witness type and sign descriptors, which was useful
in refactoring the craft justice transaction logic.
This commit fixes a bug related to swallowing an error that should go
to the switch in the case of an insufficient balance error when
attempting to add a new HTLC to the channel state machine. In this
case, an error would never be returned back to the client/switch, and
the internal processing within the channelLink would loop forever,
attempting to add an HTLC that can’t be added due to insufficient
balance to state machine itself.
We fix this issue by only treating the lnwallet.ErrMaxHTLCNumber as the
only error that prompts adding an HTLC to the overflow queue rather
than sending the error directly back to the switch.
This commit fixes a possible deadlock within the packetQueue that could
be caused by the following circular waiting dependency:
packetCoordinator woken up, grabs lock, queue isn’t empty, attempts to
send packet to link (lock still held) -> channelLink has commitment
overflow, attempts to add new item to packet queue, in AddPkt grabs
Lock -> circular wait.
We avoid this scenario by *not* holding the lock within the
packetCoordinator when we attempt to send a new packet to the switch.
Instead, we release the lock before the second select statement in the
main processing loop.
This commit adds a new test case for the default implementation of the
ChannelLink to ensure that the bandwidth is updated properly in the
face of commitment transaction overflows, and the subsequent draining
of said overflown commitment transaction.
This commit adds a new test for the current default ChannelLink
implementation to ensure that the bandwidth updates for a link are
externally consistent from the PoV of callers after a modifying action.
In this commit, we’ve moved away from the internal queryHandler within
the packetQueue entirely. We now use an internal queueLen variable
internally to allow callers to sample the queue’s size, and also for
synchronization purposes internally.
This commit also introduces a chan struct{} (freeSlots) that is used
internally as a semaphore. The current value of freeSlots reflects the
number of available slots within the commitment transaction. Within the
link, after an HTLC has been removed/modified, then a “slot” is freed
up. The main packetConsumer then interprets these messages as a signal
to attempt to free up a new slot within the queue itself by dumping off
to the commitment transaction.
This commit removes the internal queryHandler within the packetQueue
itself in order to make way for an upcoming commit which uses atomic
variables to report the length of the queue to outside callers.
Additionally, due to the recent change within the channeling, we no
longer need to report the total value of all pending HTLC’s to the
outside world.
This commit modifies the way the bandwidth of a given channel link is
tracked, and reported externally. The prior approach pushed most of the
logic for tracking channel bandwidth into the link itself, and relied
on a report from the queue in order to determine the total available
bandwidth. This approach at times could inadvertently introduce
deadlocks when working on new features as since the query was handled
internally, it required the link to be _active_ and non-blocked in
order to respond to.
We’ve now abandoned this approach in favor of lifting the bandwidth
accounting to the highest possible abstraction layer within the link
itself. We now maintain a availableBandwidth integer that’s used
atomically within the link in response to: us adding+settling an HTLC,
and the remote party failing one of our HTLC’s.
This commit adds an additional return value to SettleHTLC in order to
make way for an upcoming change to modify the way bandwidth status from
the link to the switch is reported.
This commit removes the current active LocalAvailableBalance method
from the channel state machine itself. We still maintain the internal
availableLocalBalance method locally as this is used to ensure that we
don’t add an HTLC which puts our available balance below zero.
This commit completes a full re-write of the link’s packet overflow
queue with the goals of the making the code itself more understandable
and also allowing it to be more extensible in the future with various
algorithms for handling HTLC congestion avoidance and persistent queue
back pressure.
The new design is simpler and consumes much less coroutines (no longer
a new goroutine for each active HLTC). We now implement a simple
synchronized queue using a standard condition variable.
This commit also adds an incoming flag to
HtlcRetribution struct to allow the breach arbiter to
generate the appropriate witness based on the htlc's
directionality.
It also ensures that the size of the htlc retribution
slice is now determined by the size of the number of
htlcs present in the revoked snapshot, which fixes a
minor bug that could lead to nil pointer deferences.
This commit alters the existing retribution
post breach conf test case with the intention
of testing the correct response in event that
the remote party broadcasts a prior state
while HTLCs have been extended. This serves
as a preliminary integration for an expansion
of the breach arbiter integration tests.
The primary change involves using the new
htlchodl mode for debugging, which causes the
remote peer to ignore any intent to settle
incoming HTLCs. The result is that any
payments sent to the remote party are held in
limbo, allowing us to test for these
conditions more accurately.
Currently the test case only tests that the
justice transaction is mined. After we have
fully integrated the breach arbiter to sweep
2nd layer HTLCs, this test will be altered
to check for spends from the appropriate
inputs.
This commit updates `lnd` to the latest version of our Sphinx repo as
it has included a bug fix to use the proper version within the Sphinx
routing header.
