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.
This commit adds the ability to send/recv HTLC cancellation to the
commitment state machine. Previously this feature had been
unimplemented within the state machine, with only adds/settles working.
With this change, there’s now now no concept of “timing” out HTLC’s,
only the cancellation of HTLC’s which may be triggered for various
reasons.
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.
The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
This commit converts the rearming two commitment spend functions to use
the lnwallet.Signer interface directly rather than manually manage
private keys during the signing process. This commit is in preparation
for implementation of fully automated revoked uncooperative closure
detection and retribution.
This commit modifies the channel state machine slightly to encode the
current state number using 30-bits of the sequence number within the
commitment transaction’s only input.
Such a modification reduces up the processing time required to punish
the counter party for breaching the contract established within the
channel by broadcasting an older revoked state.
This fixes#58 with a minor modification to what was originally
suggested.
This commit modifies the lnwallet code and related tests in order to
adhere to the recent field-name change to channeldb.OpenChannel.
Instead of having the field ‘TheirLNID’ which is the sha256 of the
node’s public key, we now instead use the public key directly in all
contexts.
This commit consists of a mass variable renaming to call the pkScript being executed for segwit outputs the `witnessScript` instead of `redeemScript`. The latter naming convention is generally considered to be reserved for the context of BIP 16 execution. With segwit to be deployed soon, we should be using the correct terminology uniformly through the codebase.
In addition some minor typos throughout the codebase has been fixed.
This commit modifies the prior funding workflow to account for fees
when creating the funding output. As a stop gap, the current fee for
the commitment transaction is now hard-coded at 5k satoshis. Once the
fee models are in place this should instead be some high multiple of
the current “average” fee rate within the network, continuing, the
proper fee should be adjusted from the commitment transaction has
outputs are added/removed.
This commit adds full persistence logic of the current lowest
un-revoked height within each commitment chain. The newly added
channeldb methods for record state transitions within both commitment
chains are now utilized. This un-settled HTLC state is now read upon
initialization, with the proper log entries inserted into the state
update log which reflect the garbage collected log right before the
restart.
A new set of tests have been added to exercise a few edge cases around
HTLC persistence to ensure the in-memory log is properly restored based
on the on-disk snapshot.
This commit performs a major refactor of the current wallet,
reservation, and channel code in order to call into a WalletController
implementation rather than directly into btcwallet.
The current set of wallets tests have been modified in order to test
against *all* registered WalletController implementations rather than
only btcwallet. As a result, all future WalletControllers primary need
to ensure that their implementation passes the current set of tests
(which will be expanded into the future), providing an easy path of
integration assurance.
Rather than directly holding the private keys throughout funding and
channel creation, the burden of securing keys has been shifted to the
specified WalletController and Signer interfaces. All signing is done
via the Signer interface rather than directly, increasing flexibility
dramatically.
During channel funding, rather than creating a txscript.Engine to
verify commitment signatures, regular ECDSA sig verification is now
used instead. This is faster and more efficient.
Finally certain fields/methods within ChannelReservation and
LightningChannel have been exposed publicly in order to restrict the
amount of modifications the prior tests needed to undergo in order to
support testing directly agains the WalletController interface.
This commit adds a basic test for cooperative channel closure. The
current test ensures correctness of the cooperative closure procedure
initiated by either the channel initiator, or the channel responder.
This commit patrons the state update logs properly within the channel
state machine. This change fixes a number of bugs caused by treating a
central log as two logically distinct logs. Rather than having a bit
indicating if the entry is incoming/outgoing, an entry is added to a
remote or local log depending on which modification method is used.
As a result the code is much easier to follow due to separation of
concerts.
Finally, when attempting to sign a new update with an exhausted
renovation window a distinct error is returned in order to allow higher
level callers to properly back-off and handle the protocol event.
This commit fixes a slight bug in the channel state machine’s code
executed when processing a revocation messages. With this commit after
processing a revocation, log entries which we should forward to the
downstream or upstream peer for settling/adding HTLC’s are now properly
returned.
The testa have also been updated to ensure to correct htlc’s are
returned “for forwarding”.
We no longer track HTLC’s by their r-hash within the log into the
index, as we may have multiple HTLC’s that can be redeemed by the same
pre-image. Instead we now use a separate index which is keyed by a
log-index.
Additionally, the SettleHTLC method now also returns the index of the
HTLC being settled which allows the remote party to quickly locate the
HTLC within their log.
This commit also introduces a few trace/debug log messages which will
likely be pruned in the near future
This commit finishes the initial draft of the commitment state machine.
A full re-write of the prior protocol which combines aspects of the
former ‘lnstate’ package has replaced the prior un-finished
stop-and-wait protocol.
This new protocol is designed to operate in an asynchronous environment
and to facilitate non-blocking batched and pipelined updates to the
committed channel states. The protocol is also de-synchronized meaning
that either side can propose new commitment states independent of the
actions of the other party.
The state machine implemented is very similar to that of c-lightning,
however we allow multiple unrevoked commentates in order to minimize
blocking, and also to reduce latency across several hops in a
bi-directional setting.
The current implementation consists of 3 main data structures: a
commitment chain which consist of unrevoked commitment transactions
(one for each side), and a (mostly) append-only log of HTLC updates
shared between both sides. New commitments proposed index into the log
denoting which updates they include, this allows both parties to
progress chains independent of one another. Revoked commitments, reduce
the length of the chain by one, and free up space within the revocation
window.
At this point only basic tests are in place for the state machine,
however more extensive testing infrastructure along with formal proofs
using PlusCall are planned.
