In this commit, we extend the FeeEstimator methods to allow them to
return an error. This is required as most implementations aside from
the static fee estimator will want to be able to return errors to users
to indicate the inability to properly estimate fees.
In this commit, we move the FeeEstimator interface into a distinct file
as follow up commits will begin to flesh out the interface with
additional implementations.
Fix wrong calculation of overshot amount which causes coin select
function to go into infinite loop. If overshoot amount is calculated
by subtraction of totalSatoshis and amtNeeded than on the second
iteration of loop amtNeeded already include required fee inside, which
causes continuation of the coin selection loop.
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 naming and comments of the routines that
create the sender/receiver HTLC scripts to denote that a set of
distinct keys are used. The scripts materially haven’t changed, but the
set of keys expected has.
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 method we fix an existing deadlock within the unit tests when
running with the race condition detector on. We don’t need to grab the
mutex within the ProcessChanSyncMsg method as this should be the very
first method called when initializing the channel if a channel state
sync is needed.
In this commit we ensure that the channel is always able to exit by
adding a select statement with a quit case when we’re waiting on the
result of a job that was previously sent into the sigPool.
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.
After addition of the retransmission logic in the channel link, we
should make the onion blobs persistant, the proper way to do this is
include the onion blobs in the payment descriptor rather than storing
them in the distinct struct in the channel link.
In this commit BOLT№2 retranmission logic for the channel link have
been added. Now if channel link have been initialised with the
'SyncState' field than it will send the lnwire.ChannelReestablish
message and will be waiting for receiving the same message from remote
side. Exchange of this message allow both sides understand which
updates they should exchange with each other in order sync their
states.
This commit changes the use of SigHash flags in the spend
transactions created in scrit_utils. Instead of always
using SigHashAll for the sweep signature, we instead use
the sighash flag specified by the passed sign descriptor.
Tis commit makes the btcwallet signer implementation use
signDesc.HashType instead of SigHashAll when signing
transactions. This will allow the creator of the transaction
to specify the sighash policy when creating the accompanying
sign descriptior.
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 moves the commitment transaction generation code out of
fetchCommitmentView into createCommitmentTx. Aside from being a pretty
clean logical split, this allows the transaction generation code to be
unit tested more effectively.
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.
The fee estimation for funding transactions now properly accounts for
different types of UTXOs spent, whereas previously it assumed all
inputs were spending native P2WKH outputs.
Use binary.Read/Write in functions to serialize and deserialize
channel close summary and HTLC boolean data, as well as in
methods to put and fetch channel funding info. Remove lnd
implementations of readBool and writeBool as they are no
longer needed. Also fix a few minor typos.
Use sort.Slice in SignNextCommitment function in lnwallet/channel.go,
as part of the move to use new language features. Remove
sortableSignBatch type wrapper for slice of signJobs since it is
no longer needed to sort jobs according to their output indices.
Also fix a few minor typos in channel.go and sigpool.go.
This commit fixes an existing bug where we attempted to re-use the same
commitTweak value when creating an HTLC resolution. Instead, we now
create the commit tweak value factoring the key that is to be used for
signing.
In this commit, we extend the help message for `newaddress`
to indicate which address types can be used when directly
funding channels. Additionally, we add some additional text
to the insufficient funding error to detail that we don't have
enough witness outputs.
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 fixes an existing bug within extractHtlcResolutions. The
prior code would use an index to assign the returned
OutgoingHtlcResolutions into a single slice. However, this is invalid
as there are two cases where an HTLC might be skipped: if it’s an
incoming HTLC, or if the HLTC itself is dust from the PoV of the
commitment chain.
To fix this, we now instead use append to add items to the slice. This
ensure that we don’t have any “empty” items in between fully populated
items.
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 fixes a bug wherein we would use the incorrect csvDelay
when crafting HTLC resolutions after a unilateral channel closure.
Previously, we would always use the csvDelay of the local party, as in
the force close case that’s the correct value. However, a unilateral
channel closure instead requires the _remote_ delay.
This commit fixes an existing bug when crafting the HTLC resolution in
the face of a commitment broadcast. Previously, we we’re using the
localKey which is incorrect, as directly below we properly use the
delayKey when crafting the secondLevelHtlcScript to sign.
This commit adds a new field: MaturityDelay, to the
UnilateralCloseSummary struct. This new field will be required, in an
upcoming update as it’s needed in order to properly sweep the
second-level HTLC outputs after MaturityDelay blocks has passed since
confirmation.
This commit fixes a minor bug (that doesn’t affect anything atm) when
crafting the SignDesc for sweeping breached outputs. Previously, we
would take the p2wkh script and then p2wsh-ify that, placing that into
the SignDesc. This is incorrect as the p2wkh script is “injected” into
the sighash when signing, and thus doesn’t need another encoding layer.
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 removes the current active LocalAvailableBalance method
from the channel state machine itself. We still maintain the internal
availableLocalBalance method locally as this is used to ensure that we
don’t add an HTLC which puts our available balance below zero.
This commit also adds an incoming flag to
HtlcRetribution struct to allow the breach arbiter to
generate the appropriate witness based on the htlc's
directionality.
It also ensures that the size of the htlc retribution
slice is now determined by the size of the number of
htlcs present in the revoked snapshot, which fixes a
minor bug that could lead to nil pointer deferences.
This commit is a follow up to the prior commit, as since we reversed
the order of the pubkeys in the multi-sig scripts, then we also need to
reverse the order of the signatures that we use when attempting to
spend the funding output directly.
When creating the script for the funding output, we were reversing the
order of the public keys due to an incorrect assertion of the return
value of the bytes.Compare function. To fix this, we now flip the
order, allowing us to properly create channels as specified within the
specification.
This commit adds to methods to the ChannelReservation struct: one for
generating the channel constraints we require for the remote party, and
one for validating their desired constraints, and committing them to
our ChannelConfig.
With these two new methods, we can now begin to properly store and
adhere to the current set of channel flow control constraints.
