In this commit, we refactor the existing channel closure logic for
co-op closes to use the new channelCloser state machine. This results
in a large degree of deleted code as all the logic is now centralized
to a single state machine.
In this commit, the relevant RPC’s have been modified to properly
parse, and pass through the new fee control related parameters for each
of the RPC’s.
In this commit, we add a new state machine to the project in order to
simplify and encapsulate the logic of negotiating the fees of the
closing transaction during the cooperative channel closure procedure.
This new implementation fixes several defects in the prior version of
the fee negotiation protocol as previously implemented within the peer.
Namely, we’ll now ensure that we converge to an acceptable fee
eventually, and clamp down the fee in the case that the starting fee is
greater than the fee of the commitment transaction.
The new fee negotiation also is very simple and should serve as a good
base for future improvements. After proposing our initial fee, if the
fee proposed by the remote party isn’t within 30% of our last fee, then
we increase/decrease our fee by 10%. This process continues until
either they send the same fee as we sent in a prior round, or they send
the identical fee that we sent in the last round.
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.
