In this commit, we fix an existing bug that had ramifications within
the operation of the lnd daemon. Before this commit, if the Stop()
method was called, then the closeObserver would exit as well. This
means that would no longer be watching for channel breaches on-chain,
and could miss either a cooperative channel closure or an actual
contract breach.
To fix this, we now introduce a new method to stop for closeObserver:
CancelObserver(). This should ONLY be called once either: the contract
has been fully settled on-chain, or whom ever is watching the relevant
signals has a newer version of the channel that it will watch instead.
In this commit, we modify CreateCloseProposal to no longer return the
same fee passed in. In the past, this method accepted a fee rat rather
than an absolute fee, and would return the computed absolute fee. Now
that the method takes the absolute fee directly, this is unnecessary.
In this commit, we modify the funding reservation workflow slightly to
allow callers to specify their own custom fee when initialization a
funding workflow. This gives power-users the ability to control exactly
how much in fees are paid for each new funding transaction.
In this commit, we extend the existing SendOutputs method on the
WalletController interface to be able to accept a custom fee. With
this, users are now able to specify their exact fee, allowing the
wallet to be fee estimation agnostic.
In this commit, we add a new implementation of the FeeEstimator
interface: the BtcdFeeEstimator. This implementation of the
FeeEstimator is backed by an active bcd instance. Any requests to query
for the current fee for a given confirmation target are proxied to this
active bcd instance.
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 modify the OpenChannel, CloseChannel, SendCoins, and
SendMany RPC’s to be able to allow users to manually specify their
fees. Users can either specify a target number of confirmations, or a
target value for manual sat/byte.
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.
For a calls to ListChannels we now only set the
ActiveChannel.Active=true if the link is found by the
htlcswitch. This is done to be able to make it possible
to tell if a newly opened channel has been added to
the htlcswitch, such that we can synchronize on this
during tests before we attempt to close the channel.
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 add support within lnwire for the optional dataloss
fields in ChannelReestablish. With these fields, it’s possible to:
verify that the remote node really knows of the state of our prior
local commitment, and also that they’ve sent us the current commitment
point for their current state.
In the event of dataloss, it’s possible for the party which lost data
to claim their commitment output in the remote party’s commitment if
they broadcast their current commitment transaction.
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 begin implementing the latest spec change to reduce
the attack surface on online channels. In this commit, we introduce a
distinct HTLC base point which will be used to sign the second-level
HTLC transactions for each active HLTC on the commitment transaction of
the remote node. With this, we allow the commitment key to remain
offline, as it isn’t needed in routine channel updates, unless we need
to go to chain.
This commit removes the use of a purge height from the nursery
store, instead tracking the last graduated height. This serves
to indicate the last height that the nursery store successfully
graduated. It also adds a method for retrieving the set of all active
heights below a particular threshold, e.g. the last graduated height,
allowing the utxo nursery to replay these heights on startup for the
specific purpose of re-registering for confirmations of outputs in the
height index.
This commit addresses an issue that could occur if a
message was attempted added to the sendQueue by the
queueHandler before the writeHandler had started.
If a message was sent to the queueHandler before the
writeHandler was ready to accept messages on the
sendQueue, the message would be added to the
pendingMsg queue, but would not be attempted sent
on the sendQueue again before a new incoming message
triggered a new attempt.
