This commit fixes an out of bounds error that would occur in the case
where we received a new commitment where the accompanying HTLC sigs were
too few. Now we'll just reject such an commitment.
A test exercising the behavior is also added.
In this commit, we add an additional check within
validateCommitmentSanity due to the recent change to unsigned integers
for peer balances in the channel state machine. If after evaluation
(just applying HTLC updates), the balances are negative, then we’ll
return ErrBelowChanReserve.
This commit adds a test that trigger a case where the balance
could end up being negative when we used the logIndex when
calculating the channel's available balance. This could
happen when the logs got out of sync, and we would use
the balance from a settled HTLC even though we wouldn't
include it when signing the next state.
In this commit, we add a new function that allows a caller to create a
UnilateralCloseSummary with the proper materials. This will be used
within a new sub-system to be added in a later commit to properly
dispatch notifications when on-chain events happen for a channel.
In this PR, we entirely remove the closeObserver from the channel state
machine. It was added very early on before most of the other aspects of
the daemon were built out. This goroutine was responsible for
dispatching notifications to outside parties if the commitment
transaction was spent at all. This had several issues, since it was
linked to the *lifetime* of the channel state machine itself. As a
result of this linkage, we had to do weird stuff like hand off in
memory pointers to the state machine in order to ensure notifications
were properly dispatched.
In this commit, we add a new test case for unilateral channel closes to
ensure that if the remote party closes the commitment on-chain. Then
we’re able to sweep both incoming and outgoing HTLC’s from their
commitment. With this tests, we ensure that the values returned for
HtlcResolutions from the UnilateralCloseSummary are correct and allow
us to sweep all funds properly.
In this commit we add some additional scenarios to the TestForceClose
test. With this expanded test case, we now ensure the the party that
force closes is able to properly sweep both incoming and outgoing
HTLC’s fully with the information contained the HtlcResolution struct.
In this commit, we update the channel state machine tests to use a new
key for each purpose. Before this commit, the same key would be used
the entire time. As a result, a few bugs slipped by that would’ve been
detected if we used fresh keys for each purpose. Additionally, this
reflect the real world case as we always use distinct keys for each
purpose to avoid key re-use.
To implement the BOLT 03 test vectors, a more powerful mockSigner is
required. The new version of mockSigner stores multiple keys and signs
the transaction outputs with the appropriate one.
This commit fixes a nasty bug that has been lingering within lnd, and
has been noticed due to the added retransmission logic. Before this
commit, upon a restart, if we had an active HTLC and received a new
commitment update, then we would re-forward ALL active HTLC’s. This
could at times lead to a nasty cycle:
* We re-forward an HTLC already processed.
* We then notice that the time-lock is out of date (retransmitted
HTLC), so we go to fail it.
* This is detected as a replay attack, so we send an
UpdateMalformedHTLC
* This second failure ends up creating a nil entry in the log,
leading to a panic.
* Remote party disconnects.
* Upon reconnect we send again as we need to retransmit the changes,
this goes on forever.
In order to fix this, we now ensure that we only forward HTLC’s that
have been newly locked in at this next state. With this, we now avoid
the loop described above, and also ensure that we don’t accidentally
attempt an HTLC replay attack on our selves.
Fixes#528.
Fixes#545.
In this commit, add an additional return value to
CompleteCooperativeClose. We’ll now report to the caller our final
balance in the cooperative closure transaction. We report this as
depending on if we’re the initiator or not, our final balance may not
exactly match the balance we had in the last state.
This commit fixes a lingering bug that could at times cause
incompatibilities with other implementations when attempting a
cooperative channel close. Before this commit, we would use a pointer
to the funding txin everywhere. As a result, each time we made a new
state, or verified one, we would modify the sequence field of the main
txin of the commitment transaction. Due to this if we updated the
channel, then went to do a cooperative channel closure, the sequence of
the txin would still be set to the value we used as the state hint.
To remedy this, we now copy the txin each time when making the
commitment transaction, and also the cooperative closure transaction.
This avoids accidentally mutating the txin itself.
Fixes#502.
Previously, some methods on a LightningChannel like SettleHTLC and
FailHTLC would identify HTLCs by payment hash. This would not always
work correctly if there are multiple HTLCs with the same payment hash,
so instead we change these methods to identify HTLCs by their unique
identifiers instead.
In this commit, we fix an existing bug that would cause issues within
the switch due to a value not being properly set. Before this commit we
would copy a byte array into a slice without first creating the
necessary capacity for that slice. To fix this, we’ll now ensure that
the blob has the proper capacity before copying over. Several tests
have been updated to always set a fake onion blob.
In this commit, we extend the initial check within SignNextCommitment
to bail out early if we don’t yet know the commitment point of the
remote party. This prevents a class of nil pointer panics if we attempt
to create a new state without yet having received the FundingLocked
message.
In this commit, we fix an existing bug within our cooperative channel
closing transaction generation. Before this commit, we wouldn’t account
for the fee already allocated within the commitment transaction. As a
result, we would calculate the evaluated balance considering the fee
incorrectly. In this commit, we fix this by adding the commitment fee
to the balance of the initiator when crafting the closing transaction
In this commit, we fix an existing bug, as only the initiator needs to
validate any new fee updates. If the initiator sends an invalid fee,
then it will be rejected by the responder as it may put them below
their required reserve.
In this commit, we ensure that we reject any UpdateFee messages if
after applying the update, the initiator doesn’t have enough funds to
actually pay for the new commitment state.
A test has been added to exercise this new behavior.
In this commit, we update the retransmission logic to ensure that we
properly retransmit any sent UpdateFee messages as part of a state
transition. When creating a CommitDiff, if we have a pending fee
update, then we’ll add that to the set of logs updates. When restoring
the commit diff from disk, if we encounter an UpdateFee entry, then
we’ll apply that as waiting to be ACK’d and skip adding it as a log
entry.
A new test has been added to excessive this new behavior.
In this commit, we add fully verification (other than checking the
commitment point matches after the fact) of the new optional fields
added to the lnwire.ChannelReestablish message. Two scenarios can
arise: we realize the remote party is on a prior state (and possibly
lost data), or we realize that *we* are on a prior state with the
remote party verifiably proving that they’re on a newer state.
In this commit we extend the set of fields populated within the
returned lnwire.ChannelReestablish to populate the optional data loss
fields. This entails included the commitment secret of the most
recently revoked remote commitment transaction and also our current
unrevoked commitment point.
In this commit, we update all the key derivation within the state
machine to account for the recent spec change which introduces a
distinct key for usages within all HTLC scripts. This change means that
the commitment payment and delay base points, are only required to be
online in the case that a party is forced to go to chain.
We introduce an additional local tweak to the keyring for the HTLC
tweak. Additionally, two new keys have been added: a local and a remote
HTLC key. Generation of sender/receiver HTLC scripts now use the local
and remote HTLC keys rather than the “payment” key for each party.
Finally, when creating/verifying signatures for second-level HTLC
transactions, we use these the distinct HTLC keys, rather than re-using
the payment keys.
In this commit we modify the primary InvoiceRegistry interface within
the package to instead return a direct value for LookupInvoice rather
than a pointer. This fixes an existing race condition wherein a caller
could modify or read the value of the returned invoice.
In this commit, we’ve added a set of unit tests to cover all enumerated
channel sync scenarios, including the case where both nodes deem that
they’re unable to synchronize properly.
In this commit we revert a prior commit
(5240953de02d281be694b2c87d151d6c7dce2cb5) which was added as a stop
gap before we added the proper state needed to recover from cases where
the commitment transactions of both chains had diverged slightly due to
asymmetric dust limits.
In this commit, we fix an existing derivation from the commitment state
machine as defined within the specification. Before this commit, we
only kept a single counter which both HTLC adds and fails/settles would
share. This was valid in the prior pre-spec iteration of the state
machine. However in the current draft of the spec, only a distinct
counter for HTLCs are used throughout.
This would cause an incompatibility, as if we mixed adds and settles
during an exchange, then our counter values would differ with other
implementations. To remedy this, we now introduce a distinct HTLC
counter and index within the updateLog.
Each Add will increment both the log counter, and the HTLC counter.
Each Settle/Fail will only increment the log counter. Inbound
Settle/Fails will index into the HTLC index as to target the proper
HTLC. The PaymentDescriptor type has been extended with an additional
field (HltcIndex) which itself tracks the index of an incoming/outgoing
HTLC.
This commit fixes the TestChannelBalanceDustLimit unit test in
channel_test.go. The unit test does not account for the fees
required by adding an HTLC. As a result, Alice's balance according
to her local and remote commitment chains drops below 0 at certain
points. By using the correct fee, this is avoided.
This commit expands the existing TestForceClose test case to add an
HTLC (outgoing) to Alice’s commitment transaction before force closing.
We then ensure that both the pre-signed timeout transaction _and_ the
sign descriptor to sweep the second-level output are fully valid.
This commit extracts the ending dust adherence test case from the
existing TestForceClose test case into a distinct test case. With this
modification, we now ensure that the two new tests are focused and test
a single scenario at at time.
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 fixes a bug within the HTLC construction and commitment
transaction construction that would result in HTLC _values_ within the
commitment transaction being off by a factor of 1000. This was due to
the fact that we failed to convert the amount of an HTLC, in mSAT, to
SAT before placing it as an output within the commitment transaction.
When attempt to locate the output index of a particular half, we use
the unconverted amount, meaning it was unnoticed.
This commit adds a new assertion within the TestSimpleAddSettleWorkflow
test to ensure that the HTLC is found within the commitment transaction
with the proper value in satoshi.
Note that this commit is temporary, and should be reverted once #231 is
merged. The reason we need to do this for now, is that we don’t
properly track the exact state of the remote party’s commitment. In
this test case, the resulting HTLC’s added are dust to one party, but
non-dust to another. So upon restart, the states (balance wise) has
diverged.
This commit adds the possibility for the initiator of a
channel to send the update_fee message, as specified
in BOLT#2. After the message is sent and both parties
have committed to the updated fee, all new commitment
messages in the channel will use the specified fee.
If an HTLC’s value is below a node’s dust limit, the amount for that
HTLC should be applied to to the fee used for the channel’s commitment
transaction.
In order to be able to use the DeriveRevocationRoot in the createChannel
function inside the htlcswicth package we need to make it public.
NOTE: The original lnwallet.CreateChannel function haven't been
sufficient as far it not takes the private keys as input.
This commit changes the cooperative channel close workflow to comply
with the latest spec. This adds steps to handle and send shutdown
messages as well as moving responsibility for sending the channel close
message from the initiator to the responder.
This commit modifies the fee calculation logic when creating or
accepting a new commitment transaction to use the set FeePerKw within
the channel rather then re-query the estimator each time. The prior
behavior was benign as we currently use a static fee estimator, but the
dynamic setting this could’ve caused a state divergence.
This commit replaces the hard-coded 5000 satoshi fees with calls to the
FeeEstimator interface. This should provide a way to cleanly plug in
additional fee calculation algorithms in the future. This change
affected quite a few tests. When possible, the tests were changed to
assert amounts sent rather than balances so that fees wouldn't need to
be taken into account. There were several tests for which this wasn't
possible, so calls to the static fee calculator were made.
This commit adds the FeeEstimator interface, which can be used for
future fee calculation implementations. Currently, there is only the
StaticFeeEstimator implementation, which returns the same fee rate for
any transaction.
This commit changes t.Fatal to t.Fatalf in TestCheckDustLimit so as to
provide more information. This commit also makes some column width
adjustments and minor spelling/formatting changes.
This commit fixes a lingering TODO within the wallet portion of the
codebase by properly adhering to the set dust limits when closing a
channel. With this new commit if a party’s current settled balance is
below their current dust-limit, then it will be omitted from the
commitment transaction.
The prior test that asserted negative outputs are rejected has been
removed as they’ll now be avoided by ensuring we omit dust outputs from
the commitment transaction.
This commit removes all instances of the fastsha256 library and
replaces it with the sha256 library in the standard library. This
change should see a number of performance improvements as the standard
library has highly optimized assembly instructions with use vectorized
instructions as the platform supports.
Currently non-HTLC outputs will be accepted in the commitment
transaction as long as it is non-zero. We change this by not allowing
outputs with a value lower than the dust limit. The value of such
an output will go towards transaction fees.
This commit fixes a class of bug that currently exists within the
cooperative closure methods for the channel state machine. As an
example, due to the current hard coded fees, if one of the outputs
generated within the generated closure transaction has a negative
output, then the initiating node would gladly forward this to the
remote node. The remote node would then reject the closure as the
transaction is invalid. However, the act of completing the closure
would cause the remote node’s state machine to shift into a “closed”
state. As a result, any further closure attempts by the first node
(force or regular) would go unnoticed by the remote node.
We fix this issue by ensuring the transaction is “sane” before
initiating of completing a cooperative channel closure.
At test case has been added exercising the particular erroneous case
reported by “moli” on IRC.
In this commit the initial implementation of revocation hash
generation 'elkrem' was replaced with 'shachain' Rusty Russel
implementation which currently enshrined in the spec. This alghoritm has
the same asymptotic characteristics but has more complex scheme
to determine wish hash we can drop and what needs to be stored
in order to be able to achive full compression.
This commit updates the set of channel state machine tests to properly
compile and execute with the latest set of changes to the state
machine.
Most of the changes within this commit are just renaming and field
changes as a result of the new wire messages.
The more substantial change is due to the change in semantics of the
new state machine w.r.t what has and has not been ACK’d when a new
state transition is implemented. In the case of a concurrent update
(both sides add to the log before a state transition), both sides need
to trigger a state update in order to ensure their updates have been
included.
This commit removes the BlockChainIO interface as a dependency to the
LightningChannel struct as the interface is no longer used within the
operation of the LightningChannel.
This commit modifies the logic around adding cancel entries to the
update log for the commitment state machine slightly by also including
the r-hash of the HTLC that’s been cancelled in the entry for the
cancellation. With this change, we can accurately track which HTLC is
being cancelled within outer sub-systems.
This commit alters the new HTLC cancellation logic to instead allow the
canceller of an HTLC to cancel the HTLC by the payment hash rather than
the index of the HTLC.
