This commit modifies a peer’s htlcManager goroutine in order to
properly implement the new state machine defined by the specification.
The major change to this new state machine is that we can no longer
have a limited number of unrevoked commitment states. As a result, we
no longer need to track how many outsanding changes we have, and only
need to track if we have a pending change or not. This simplifies the
logic a bit.
Additionally, when receive a new signature we FIRST send an
RevokeAndAck, THEN we if we need to send a signature in response or
not. This is the major change to the state machine from the PoV of the
htlcManager. Previously, the order was flipped.
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 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.
This commit minifies the BtcdNotifier concrete implementation of the
ChainNotifier interface to allow callers to optionally cancel an
outstanding block epoch or spend notificaiton intent.
To do this efficiently, we now give each notification intent a unique
ID based on if it’s an epoch intent or a spend intent. We then use this
ID to reference back to the original un-dispatched notification intent
when the caller wishes to cancel the intent.
When iterating with the ChainNotifier, it currently isn’t possible to
cancel a non-dispatched yet active notificaiton intent. As a result,
this can be rather wasteful in many parts of lnd which my repeatedly
create a new spend notification depending on if/when a peer is
connected or not.
In order to fix this, we add a new `Cancel func()` field to both the
`BlockEpochEvent` and `SpendEvent` structs. This new closure attribute
allows the caller to cancel the yet-to-be-dispathed event, allowing the
ChainNotifier to free up resources.
This commit modifies the running update count within all ChannelDelta’s
to track the number of updates using a uint64 rather than a uint32.
This change reflects the fact that the obsfucated commitment hints are
to be encoded using a 48-bit integer, rather than a 32-bit integer.
This commit modifies the prior HTLCSettleRequest to more closely match
the UpdateFufillHTLC defined within the specification. The only
semantic change is the move from a slice of pre-images (for “multi-sig”
LN) to a single payment preimage.
This commit morphs the prior CancelHTLC into the new UpdateFailHTLC
message and also gets rid of the obsolete HLTCAddReject message while
we’re at it.
The primary change from the CancelHTLC message to the UpdateFailHTLC
message is that the CancelReason is now simply called Reason and that
it’s now an opaque encrypted set of bytes. With this update the failure
messages are now more flexible (they can even carry new
ChannelUpdate’s) and also don’t reveal the exact cause of failure to
intermediate nodes.
This commit renames and modifies the CommitSignature message to more
closely match the CommitSig message defined within the current set of
draft specifications.
The major change within the new message is that we now longer
explicitly specify the update log index of the remote node that this
signature covers. This is due to the fact the revocation message now
also double as acknowledgements of the remote parties recevied
commitment update messages.
This commit renames the prior CommitRevocation message to RevokeAndAck
in order to better align the set of wire messages implemented by the
`lnwire` message with those currently defined within the specification.
This commit prevent unnecessary connection flapping by ensure we don’t
attempt to auto-connect to a peer that we’re unable to create or start
the goroutines of. With this commit, we won’t attempt to auto-connect
to a peer that has incompatible feature sets to that of ours.
Sticking with our tradition of tracking the two latest go releases,
we'll now build against Go 1.8 (which was recently released and Go
1.7.5).
The release of Go 1.8 is very attractive to the project as it includes
performance and GC improvements as well as the addition of more
profiling and race condition detection capabilities within the runtime.
In this commit the support for global and local feature vectors were
added in 'server' and 'peer' structures respectively. Also with commit
additional logic was added and now node waits to receive 'init'
lnwire.Message before sending/responding on any other messages.
In this commit the feature maps were added which which binds the name
of the global feature with it index in feature vector. The index is
just an order of the feature and the final binary representation of
feature vector is determined by decode function. This maps helps to
operate with feature by their names rather than their indexes.
'init' message is the first message reveals the features supported or required
by this node. Nodes wait for receipt of the other's features to simplify error
diagnosis where features are incompatible. This message will help negotioate the
the features which are supported by both sides.
This commit fixes a panic that can result when a zpay32 payment request
that is too short (and possibly invalid) is attempted to be decoded.
To fix this bug, we now simply ensure that that after we decode the
zbase32 encoding, the resulting set of bytes is _exactly_ the length we
expect. A new error has been introduced to handle this case, and a
simple test has been added which ensures proper handling of short
payment requests.
Fixes#127.
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 a new assertion in the channel force closure test in
order to exercise the fix for a bug related to channel force closure
implemented in a prior commit. With this new assertion, we ensure that
bob is aware of his on-chain balance after a force channel closure
initiated by alice.
This commit fixes a bug which would cause the node on the _receiving_
side of a channel force close to be blind of their immediately funds
on-chain. The root of the issue was that within the btcwallet
implementation of the WalletController method ‘NewRawKey’, the wallet
wouldn’t request notifications for the new address, as the direct
function from the waddrmgr was used which skips registration of the new
address.
To fix, this, we now ensure that btcwallet will receive notifications
for keys used within the raw p2wkh commitment output. This ensures that
the wallet is aware of funds that are made available as a result of a
channel force closure by the channel counter party.
This commit fixes a bug which would previously lead to corruption of
the channel state when a node had one or more channels open and one of
them was closed either forcibly or cooperatively. The source of the bug
itself as a typo: rather than using the construed `deliveryKey`
variable to fetch/put/delete the delivery scripts, `deliveryScriptsKey`
(the key prefix itself) as used. This bug would cause the database to
be unable to read _any_ channel from the database after one was
deleted, as each channel would actually be reading/writing-to the
_exact same_ delivery script.
The fix for the bug itself is simple: eliminate the typo.
This commit modifies the behavior for the commands which open and close
channels on the command line. Previsouly a user needed to use the
`—block` flag in order to get information about any possible errors or
the full progress of a request. This commit alters the behavior
slightly to block until the _first_ message or error is returned from
the gRPC stream.
With this change, the command line usage has a better UX as users
instantly get more information without having to peer into the logs.
This commit patches a bug in the code for handling a remote cooperative
channel closer. Previous if the region node didn’t know of the channel
which was being requested to close, then a panic would occur as the
entry read from the map would be nil.
To fix this bug, we now ensure that the channel exists before we
perform any actions on it. In a later commit which overhauls the
channel opening and closing to match that of the specification, this
logic will be modified to properly send an error message in response to
the failed channel closure.
This commit addresses some lingering TODO’s which ensure that related
state to a channel is properly deleted by the CloseChannel method.
Previously the values for the respective dust-limits of either side,
the on-disk HTLC’s, and any entries the revocation log for the channel
weren’t being properly deleted.
Additionally, we now modify the checks within the unit tests to ensure
that we can still read the channel from disk w/o running into an error
(thought the slice will be blank), and also the the revocation log is
properly garbage collected.
This commit modifies the existing syncing logic to launch a new
goroutine on connect to synchronize graph state with the new peer
rather than the prior blocking version. This change should make the
initial sync a little snappier and also possible eliminate a circular
dependency between the ChannelRouter and the server.
This commit fixes bug that could result in the panicking or crashing of
nodes in the case of an at-funding-time reorganization within the
network. In order to avoid such a case, we now ensure that the
advertised transaction index is within the bounds of the block before
attempting to access it.
Note that this is a temporary patch commit until full advertisement
validation which is implemented in the discovery PR lands in master.
Additionally, better reorg handling during the funding process is being
specified within the spec and will properly be implemented within lnd
at a later date.
This commit fixes a slight scripting related issue as a result of
default policy in Bitcoin Core 0.13.1. With this version of Bitcoin
Core, nodes will now enforce a policy that ensures the first argument
of OP_IF is either an empty vector or a 0x01 value. Our current sent of
functions to generate the witness for the delay clause of the
commitment transaction instead uses a 0x00 value rather than an empty
byte vector.
With this commit we fix the issue by ensuring that we use an empty
vector rather an 0x00 for forcing the commitment delay script pathway.
This commit fixes a prior block propagation race-condition by detecting
and properly processing “premature” announcements. A premature
announcement is one that’s received with an anchored block height which
is beyond our chain tip. Once received, we now store these
announcements in a special map that’s caches them in memory. Once a new
block arrives, we check the map for the existence of any entries,
processing them as normal if so.
This commit modifies the logic of the contract hand-off within the
breachArbiter to ensure that only a single internal closeObserver
goroutine is ever active for a given contract.
This modification cleans up the logs in the case of multiple
reconnections and may possible eliminate some non-deterministic bugs
related to channel force closures.
