In this commit, we update getChanID to be aware of the FundingLocked
message as it will be retransmitted upon reconnect if both nodes think
that they’re at the very first commitment state.
In this commit, we’ve re-written the process of syncing the state of
channels after we reconnect. This re-write ensure correctness, and also
simplified the existing logic which would attempt to launch another
goroutine to handle requests from the switch to ensure that it doesn’t
block. This is no longer necessary as the AddPacket method that the
switch indirectly calls is non-blocking.
In this commit, we modify the existing implementation of the
Bandwidth() method on the default ChannelLink implementation to use
much tighter accounting. Before this commit, there was a bug wherein if
the link restarted with pending un-settled HTLC’s, and one of them was
settled, then the bandwidth wouldn’t properly be updated to reflect
this fact.
To fix this, we’ve done away with the manual accounting and instead
grab the current balances from two sources: the set of active HTLC’s
within the overflow queue, and the report from the link itself which
includes the pending HTLC’s and factors in the amount we’d need to (or
not need to) pay in fees for each HTLC.
In this commit, we’ve modified the link and the switch to start to use
the new mailBox in place of the existing synchronous message send
directly into the link’s upstream/downstream channels. With his change,
we no longer need to spawn a new goroutine each time an HTLC needs to
be forwarded, or a user payment is initiated.
In this commit, we add a new abstraction to the package: the mailBox.
The mailBox is a non-blocking, concurrent safe, in-order queue for
delivering messages to a given channelLink instance. With this
abstraction in place, we can now allow the switch to no longer launch a
new goroutine for each forwarded HTLC, or instantiated user payment.
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 do away with the existing availableLocalBalance
attribute and instead add a new, more accurate AvailableBalance method.
The new method will compute the available balance within the channel ,
assuming a new state was created at the instance the method was called.
This new method will now properly account for HTLC fees.
AvailableBalance is now called within AddHTLC in order to ensure we
don’t add any HTLC’s that are unable to be paid for from the PoV of the
fees on the commitment transaction.
We no longer need to manually pass in the channel delta to
AppendToRevocationLog (now called AdvanceCommitChainTail) as the
pointers on-disk will be updated atomically.
In this commit we update the RevokeCurrentCommitment method to properly
use the new database UpdateCommitment method along with properly
converting the in-memory commitment to its corresponding on-disk
format.
In this commit we complete the partially completed ReceiveReestablish
method and rename it to ProcessChanSyncMsg. The new version now
properly implements retransmission as defined within BOLT#2.
Additionally, we’ve added a new case which will optimistically try and
force a resynchronization of the commitment states if we detect we can
deliver a new commitment signature sooner than later after realizing
that we need to retransmit our last revocation message when we recevied
a new state transition.
This commit adds a new method: createCommitDiff. The method will, given
a newly constructed commitment, its signature, and HTLC signatures will
create a channeldb.CommitDiff. The CommitDiff created is to be stored
on disk, as it can be used in the case that the remote party didn’t
receive our CommitSig message and also forgot all the updates that we
queued with the update.
In this commit we complexly revamp the process of restoring all channel
state back into memory after a restart. We’ll now properly do the
following: restore the pending “dangling” commit of the remote party
into the in-memory commitment chain, re-populate all active HTLC’s back
into their respective update logs with the proper indexes/counters, and
properly restore the current commitment of the remote party back in
memory.
This commit adds a new method to the updateLog which will be used when
restoring the state of a channel from disk after a restart. This new
method will add an entry to the updateLog without incrementing either
of the counters as the HTLC already comes pre populated with its
historical index.
With these new fields, we’ll be able to properly reconstruct the log
state after a restart, as each commitment will now note both the
current HTLC and log index.
In this commit we’ve extended the TestChannelStateTransition method to
exercise the new state transition related messages. This includes
ensuring that when we add a new dangling commitment, and then the
remote party revokes it, then the on-disk state is update accordingly.
In this commit, we update the CloseChannel method to respect the new
on-disk bucket based structure. Additionally, we now ensure that we
delete the new chainBucket.
In this commit, in addition to the renaming we’ve modified the behavior
of AdvanceCommitChainTail as follows: this method now will simply
atomically advance the commitment tail, set the new commitment to the
prior dangling commitment, and update the on-disk revocation log.
The macho expects the new revocation state to already be stored within
the channel. This method is to be called once the remote party revokes
their current commitment state.
In this commit, we add a new method: RemoteCommitChainTip. This method
allows callers to poll the database state to check if we have an
un-acked commitment for the remote party. If so, then it should be
retransmitted once a communication channel has been re-established with
the channel peer. This method will return ErrNoPendingCommit if we
don’t currently have a dangling commitment.
In this commit, we add a new method AppendRemoteCommitChain. This
method is meant to be used once we extend a new state to the remote
party, but before we actually transmit the CommitSig message. With this
method, we store a fully valid CommitDiff on disk which can be used in
the case that we need to retransmit the state to the party as they
didn’t fully receive it.
In this commit we finalized the structure of the CommitDiff struct by
adding a set of LogUpdates, and also a valid CommitSig message.
The LogUpdate struct houses a messages that were transmitted and
locked-in with the new commitment state. We include the LogIndex along
with the wire messages itself in order to be able to properly
reconstruct the update log upon restart.
The CommitSig message included should be transmitted after the set of
LogUpdates, and fully covers the new commitment state and any new (or
already present) HTLC’s that were included as part of the state.
In this commit, we modify the UpdateCommitment method to accept a full
ChannelCommitment rather than a new transaction, the sig, and a
ChannelDelta. This new structure of this method also takes advantage of
the new bucket structure of the storage schema. Additionally, this
method will now atomically swap in the new passed commitment to point
to the LocalCommitment value within the struct.
In this commit we add a new MarkAsOpen method to the OpenChannel
struct. This method replaces the existing MarkChannelAsOpen method
which targeted the database struct itself.
In this commit we comptely overhaul the existing storage of the
OpenChannel struct to use the new common serialization defined within
the codec.go file. Additionally, we’ve modified the structure of the
channel database on disk. Rather then use the existing prefix based
segmentation, everything is now bucket based. This has resulted in much
simpler and easier to follow code. The bucket progression is:
openChannelBucket -> nodeBucket -> chainBucket -> channelBucket. We add
a chainBucket as it’s possible that in the future we may have several
channels on distinct chains with a given node.
With the above changes, we’re able to delete much of the existing code
within the file, drastically reducing its size.
