This commit adds a new companion struct: OutgoingHtlcResolution to the
commitment state machine. The purpose of this struct is the provide the
caller with the information necessary to sweep all outgoing HTLC’s in
the case of a broadcast up-to-date commitment transaction.
The HTLC resolutions allow a caller to sweep an outgoing HTLC into
their wallet after the absolute timeout of the HTLc has passed. This is
a two step process, with the first portion consisting of broadcasting
the HTLC timeout transaction itself, and the second portion consisting
of claiming the HTLC itself after a CSV delay.
This commit adds awareness of active HTLC outputs to the
BreachRetribution struct. Previously, in the case of a breach, the
struct was only populated with enough information to sweep the two
commitment outputs. With this commit, the struct now has enough
information to sweep _all_ outputs within the commitment transaction.
This commit updates the central fetchCommitmentView method to manage
and derive the necessary easy required to create new commitments due to
the new state machine design within the specification. Each state now
requires us to derive a number of keys for each commitment state:
localDelay, remoteDelay, localKey, remoteKey, the commitment point, and
finally the revocation key itself.
This commit updates the set of functions tasked with generating HTLC’s
scripts for new commitments to now adhere to the new commitment
transaction design. With this change, the process of claiming an HTLC
now requires a second-level HTLC transaction, which solves a prior
issues due to the tight coupling of the timeout and delay clauses when
claiming an HTLC.
This commit adds a new method to the commitment struct:
populateHtlcIndexes. populateHtlcIndexes modifies the set of HTLC's
locked-into the target view to have full indexing information
populated. This information is required as we need to keep track of the
indexes of each HTLC in order to properly write the current state to
disk, and also to locate the PaymentDescriptor corresponding to HTLC
outputs in the commitment transaction.
We also modify toChannelDelta to take not of these new changes, and
access the appropriate index directly.
This commit modifies the way we account for dust HTLC’s within the
commitment state machine when creating and validating new states.
Previously, an HTLC was dust if the amount of the HTLC was below the
dustLimit of the commitment chain. Now, with the HTLC covenant
transaction, the value of the HTLC also needs to cover the required fee
of the HTLC covenant transaction at the specified fee rate of the
commitment chain.
As a result, we now determine if an HTLC is dust or not, only at the
commitment site, using the new htlcIsDust function.
This commit modifies the current core channel state machine in order to
may a step towards BOLT-0002 and BOLT-0003 compliance. In this change,
we abandon the prior revocation window, in favor of a fixed revocation
window of size two. The revocation window will be filled at the start
of the lifetime of the channel, and never extended from there until the
channel has been fully closed.
We now maintain two variables, the current un-revoked commitment point,
and the next commitment point to use when creating a new state. The
next commitment point must initially be inserted into the channel state
with the InitNextRevocation method.
A major difference between the prior revocation key handling is that
the remote party now instead sends us the _commitment point_ in
isolation, which we then use locally (with our revocation base point)
to create the next full revocation key for _their_ commitment
transaction.
This commit updates much of the state interaction within the
LightningChannel structure to account for the recent changes within the
chanenldb involving the OpenChannel struct, namely the introduction of
ChannelConfig and ChannelConstraints.
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.
This commit fixes a race condition that would at times occur in the
htlcswitch.TestChannelLinkBidirectionalOneHopPayments test case. A race
condition would occur in the goroutine running ReceiveNewCommitment
compared with the grouting that would obtain the snapshot in order to
make a forwarding decision.
We fix this by creating a new public key for each new commitment
transaction such that we complete avoid the read/write race condition.
This commit fixes a race condition that was discovered as a result of
the new htlcswitch package. The StateSnapshot method and all of the
other methods which mutate the state of the channel state machine were
using distinct mutexes. The fix is trivial: all methods accessing the
internal channel state variable now use the same mutex.
add rhash to the payment descriptor when receiving the settle htlc in
order to be able to pass it during settle htlc packet generation and
later find the user pending payment by rhash without additional hashing.
In this commit we made state machine to be responsible for returning
proper available balance - amount of satoshi which we able to use at
current moment. This will help us in constrction channel link
abstraction.
In this commit severe bug have been fixed which allows the state of the
nodes to be desychnorinesed in the moments of high htlc flow. We limit
the number of the htlc which we can add to commitment transaction
to half of the available capcity. This change fixes the bug when
commimtment transaction on the verge of being full, in this case race
condition might occures and remote htlc will be rejected, but at the
same time they will be added on remote side, the same situiation will
happen with htlc we have added, which cause the commitment transactions
to be different.
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.
In order to cleanly handle shutdowns and restarts during state machine operation, the fee for the current
commitment transaction must be persisted. This allows the fee to be
reapplied when the current state is reloaded.
This commit modifies the actions of the closeObserver goroutine to
utilize a _new_ channel to send channel close details over. The
original close signal channel is still used to notify observers that a
channel _has_ been closed, but this new channel will provide a single
observer with details w.r.t _how_ a channel was closed.
This commit adds an additional field to the ForceCloseSummary that
allows observers of the channel that sends this struct to track _which_
channel the force close came from.
This commit improves the channel state machine by converting the
objective PendingUpdates method to a subjective FullySynced method
which is to be used in place of PendingUpdates. The new FullySynced
method is fully encompassing and replaces any upper state required by
the state machine which wraps this one.
The new FullySynced method is identical to PendingUpdates aside from
the fact that: it now also factors in the log message index of the
remote commitment chain, and also introduces a concept of an “owed
commitment”. A commitment chain owes a commitment if the height of the
local commitment chain is higher than that of the remote chain.
This commit removes the theirPrevPkScript field from the
LightningChannel struct all together. It’s no longer needed as the more
fundamental mutation bug has been fixed within the channel state
machine.
This commit fixes a class of bug that can arise in the channel state
machine when a very high throughput workflow is attempted. Since the
PaymentDescriptor’s within a commitment pointed directly into the log,
any changes to a payment descriptor would also be reflected in all
other ones. Due to this mutation possibility, at times, the
locateOutputIndex method would fail since the HTLC’s pkScript was
modified, causing the channel to fail.
We fix this class of bug by simply ensure that once an HTLC has been
associated with a particular commitment, then it becomes immutable.
This commit fixes a slight oversight in the current state machine which
assumes that both commitment chains are always at the same height. In a
future where we move back to allowing nodes to pipeline commitment
updates, this will not always be the case.
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 does some minor shuffling around and also adds some
additional comments to the restoreStateLogs method within the channel
state machine. After the latest merge in this area, the code has
diverged slightly from what’s considered typical within the rest of the
codebase.
It is possible that that there are multiple HTLCs with different values,
but the same public key script. As such, a check against the value should
be performed when looking for HTLC outputs in a commitment transaction.
Create a new helper method called genHtlcScript which will
generate the public key scripts for a supplied HTLC. This functionality
from addHTLC is removed, and addHTLC will instead call this new
method.
In restoreStateLogs we will regenerate the public key scripts for the
HTLCs with genHtlcScript and restore the proper values.
When an HTLC is either cancelled or settled we must properly set the
pkScript for the HTLC on the remote commitment, such that we can
generate a valid ChannelDelta.
Description of bug:
When calling ReceiveNewCommitment() we will progress through methods
fetchCommitmentView and addHTLC which will add HTLC outputs to the
commitment transaction in the local commitment chain and save the
pkScript to the relevant PaymentDescriptor which resides in the
corresponding updateLog. Finally the local commitment will be added
to the local commitment chain.
When the same user next calls SignNextCommitment we will again
progress through fetchCommitmentView and addHTLC. In addHTLC we will
now overwrite the pkScripts in the PaymentDescriptors with the
pkScript from the context of the remote commitment. When we later
call RevokeCurrentCommitment and proceed into toChannelDelta, we
will not be able to find the correct pkScript in the PaymentDescriptor
to match it against the outputs in the commitment transaction.
This will lead to the nested function locateOutputIndex returning
incorrect values.
Fixing the bug:
We introduce three new fields in PaymentDescriptor:
* ourPkScript
* theirPkScript
* theirPrevPkScript
ourPkScript will include the pkScript for the HTLC from the context
of the local commitment.
theirPkScript will take the value of the latest pkScript for the HTLC
from the context of the remote commitment.
theirPrevPkScript will take the second-latest pkScript for the HTLC
from the context of the remote commitment. This is the value we use
in toChannelDelta when we save a revoked commitment from our peer.
The appropriate value of these fields are set in the addHTLC method.
Additionally we pass a boolean value to toChannelDelta so we know
whether we are operating on a local or remote commitment and grab
the correct pkScript in locateUpdateIndex.
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.
If the value of the to-local output is below the dust limit, the
ForceCloseSummary should not include a sign descriptor for this output.
We also find the proper to-self output by looking for the expected public
key script and not assume that no HTLC outputs exist.
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.
This commit avoids a class of bug wherein the state of the channel
would be marked as closing enough though an error occurred somewhere in
the function. The bug was due to the fact that the channel `status` was
shifted before any actual logic within the function(s) were executed.
We fix this bug by _only_ shifting the channel status once the function
has completed without any error.
This commit adds a new method to the channel’s state machine:
NextRevocationKey. This method is being added in preparation for the
upcoming change to switch to the commitment transaction format outlined
in the spec. When this comes to pass, the ExtendRevocationWindow method
will be removed, as it will no longer be needed.
The NextRevocationKey method will be needed as to conform to the spec,
we’ll need to send the next revocation key within the `fundingLocked`
message.
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.
Fix SetStateNumHint and GetStateNumHint to properly
set and get the stateNumHints using the lower 24 bits
of the locktime of the commitment transaction as the
lower 24 bits of the obfuscated state number and the
lower 24 bits of the sequence field as the higher 24
bits.
This commit adds an additional case of the closeObserver that will
properly handle the case of a channel being closed by a de-sync’d
commitment transaction from the PoV of the local node. In the case of a
minor 1-state divergence, the commitment transaction broadcast by the
remote node will be 1 state ahead of the commitment transaction we have
locally. This should be seen as a regular unilateral close as they
remote peer didn’t violate the channel contract in any way.
We address this case by changing the `==` to a `>=`.
This commit updates the internal channel state machine to the one as
described within the spec and currently implemented within the rest of
the other Lightning implementations.
At a high level the following modifications have been made:
* When signing we no loner include the index of the remote party’s
log
that our signature covers. Instead we include ALL of our current
updates, but only the updates of the remote party that we’ve
ACK’d.
* A pending change is considered ACK’d once a revocation message
has been received, locking in the changes in the remote party’s
commitment transaction.
* When sending a new commitment, we remember the index of our
log at that point so we can mark that portion of the log as ACK’d
once we receive a revocation message from the remote party.
* When receiving a new commitment signature, we include ALL of
the remote party’s changes that we’ve received but only our set
of changes that’ve been ACK’d by the remote party.
* Implicitly a revocation message now also implicitly serves to ACK
all the changes that were included in the CommitSig message
received before it.
The resulting change is a rather minor diff. However, with this state
machine it’s important to note that the order to sig/revoke messages
has been swapped. A proper exchange now looks like the following:
* Alice -> Add, Add, Add
* Alice -> Sig
* Revoke <- Bob
* Sig <- Bob
* Alice -> Revoke
One other thing that’s worth noting is that with this state machine,
since what’s included in an update is implicit, both side may need to
at times send a new commitment update in the case of a concurrent state
transition initiated by both sides.
Finally, all counters/indexes have been made 64-bit integers in order
to properly match the spec.
This commit adds a new struct to the channel state machine: updateLog.
updateLog encapsulates the update log linked list itself, a series of
new counters we’ll need in order to switch to the spec’s state machine
and also the index into the log itself. This new struct serves to
simplify much of the logic surrounding the update log and also
elminates a bit of code duplication within the current state machine.
This commit only adds the new struct. The rest of the state machine
will be updated in a later commit to use the new log and its new
counters.
This commit fixes a bug in the LightingChannel commitment state machine
which could occasionally result in the total number of satoshis sent or
received being counted twice if a redundant state transition were
initiated.
To fix this bug, we now only increment the number of satoshi
sent/recv’d iff it’s the first time the HTLC has been processed.
This commit ensures that when a channel’s closeObserver is signaled to
exit before a channel closure has been detected, then the resources
dedicated to the pending spend notification can be freed up.
rHashMap is used to store the PaymentDescriptor belonging to a received
HTLC's revocation hash. This improves the efficiency of looking up
PaymentDescriptors from their RHash whenever we want to settle or cancel
that HTLC.
This commit adds the ability to cancel a channel’s internal
closeObserver goroutine by adding a new public facing Stop method.
Additionally, we now make passing a ChainNotifier interface completely
optional. If the ChainNotifier isn’t passed in as a constructor, then
the closeObserver goroutine will never be launched. This new feature
lets the caller ensure that only a single closeObsever for any given
channels exists.
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 fixes a bug introduced by the past attempt to Make Logging
Great Again. Since we unset the curve parameters when reading/writing
the messages, if we have a lingering reference that’s active elsewhere
in the daemon, then we’ll modify that reference. To fix this, we now
explicitly set the Curve parameters in two areas.
A similar commit has been pushed to lightning-onion.
This commit modifies the closeObserver goroutine to ensure that a close
summary has been inserted into the database before signalling any
observers that a unilateral channel closure was detected. This fixes a
slight bug where a peer would force close a channel, but we wouldn’t
properly detect that and clean up the channel state if had a failed
cooperative channel closure.
This commit modifies the logic of the closeObserver slightly to not
incorrectly mark the broadcast of the commitment transaction triggered
by a cooperative channel closure as an unprompted broadcast.
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 partially rectifies a quick hack that was previously thrown
in to address an issue discovered due to possible state inconsistencies
between an active channel object and the daemon’s breachAbrbiter.
A prior commit has modified the interaction between the peer and the
breachArbiter to eliminate the state in consistency. Therefore, we no
longer need to access the database to ensure that we’re observing the
latest channel state in order to correctly make a decision about
whether a broadcast commitment transaction is a breach or not.
This commit modifies the attributes of the LightningChannel struct to
publicly expose the funding keys used within the channel for the local
and remote party. Exposing these keys publicly will allow callers to
use the keys involved to generate authenticated channel advertisements
for the routing layer.
This commit modifies the channel closing logic to remove the hard coded
bools indicating which side is attempting the closure. With the recent
changes, the initiator must always pay the channel closure fees.
This information is recently stored on disk, therefore we can use the
boolean to ensure that the closure transaction is created properly no
matter who initiates the close.
This fixes a bug.
This commit introduces a new sub-system into the daemon whose job it is
to vigilantly watch for any potential channel breaches throughout the
up-time of the daemon. The logic which was moved from the utxoNursery
in a prior commit now resides within the breachArbiter.
Upon start-up the breachArbiter will query the database for all active
channels, launching a goroutine for each channel in order to be able to
take action if a channel breach is detected. The breachArbiter is also
responsible for notifying the htlcSwitch about channel breaches in
order to black-list the breached linked during any multi-hop forwarding
decisions.
This commit adds detection of contract breaches within the commitment
state-machine for a channel. A contract breach is defined as the event
wherein a channel counter-party broadcasts a previously revoked
commitment transaction. Such an event immediately closes a channel as
the funds are now in a state of dispute.
Once a breach is detected, a snapshot of the breached state is
retrieved from the database’s revocation log. This snapshot is then
used to generate the revocation leaf used within this particular state
along with all the other information ncessary to sweep ALL active funds
within the channel. This information is encapsulated within the
BreachRetribution struct which is sent over a new channel dedicated to
sending/receiving BreachRetributions.
This commit modifies the logic within the state machine to properly
populate the new field of `OutputIndex` which the HTLC stored within a
channel delta.
With this change, in the future we’ll be able to quickly locate a
particular HTLC output in the scenario that the commitment transaction
has been broadcast on-chain and we need to sweep it. Allocating a few
extra bytes on-disk saves us from the guess-and-check logic+code
required otherwise.
This commit adds some necessary locking to ensure that all updates to
the internal state of the commitment state machine are fully serial and
thread-safe. This change is required to ensure future actions w.r.t
taking action once a revoked commitment transaction has been broadcast
are not carried out while the channel’s state is being updated.
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.
