In this commit, we fix an existing bug, as only the initiator needs to
validate any new fee updates. If the initiator sends an invalid fee,
then it will be rejected by the responder as it may put them below
their required reserve.
In this commit, we ensure that we reject any UpdateFee messages if
after applying the update, the initiator doesn’t have enough funds to
actually pay for the new commitment state.
A test has been added to exercise this new behavior.
In this commit, we update the retransmission logic to ensure that we
properly retransmit any sent UpdateFee messages as part of a state
transition. When creating a CommitDiff, if we have a pending fee
update, then we’ll add that to the set of logs updates. When restoring
the commit diff from disk, if we encounter an UpdateFee entry, then
we’ll apply that as waiting to be ACK’d and skip adding it as a log
entry.
A new test has been added to excessive this new behavior.
In this commit, we correct the BTC -> SAT conversion in
BtcdFeeEstimator. Previously, we use 10e8 instead of 1e8, causing us to
be off by an order of magnitude.
Adding 99 here didn’t really do anything but obfuscate when we were
trying to compute. We’re just using internet division to calculate 1%
of the channel capacity amount. This is the amount that the remote
party must remain above at all times.
In this commit, we fix an existing issue that could at times cause an
inconsistent view between the set of total coins, and the set of segwit
coins in the wallet of the node. This could be caused by initiating a
funding flow, but then the funding negotiation breaking down somewhere
along the lines. In this case, us or the other peer will disconnect.
When we initiate funding flows, we lock coins exclusively, to ensure
that concurrent funding flows don’t end up double spending the same
coin. Before this commit, we wouldn’t ever unlock those coins. As a
result, our view of available coins would be skewed.
The walletbalance call would show all the coins, but when adding the
—witness_only flag, some coins would be missing, or gone all together.
This is because the former call actually scans the txstore and manually
tallies the amount of available coins, while the latter looks at the
sent of available outputs, which is filtered based on which coins are
locked.
To remedy this, we now ensure that when a peer disconnects, we wipe all
existing reservations which will return any locked outputs to the set
of available outputs for funding flows.
In this commit we add a new case to the main select statement within a
channel link. This select statement will serve as a Sipping Bird which
will check the network fee rate (as returned by the fee estimator) and
compare that to the fee on the commitment transaction. Using the
shouldAdjustCommitFee function, we determine if we should update the
commitment fee. If so, then we’ll send an UpdateFee message and also
trigger a new commitment update.
We also add a new unit test: TestChannelLinkUpdateCommitFee to ensure
that we update the fee accordingly if the fee increases or decreases by
a large portion.
In this commit, we add a new helper function to the link which will be
utilized in a later commit. This helper function will help us determine
if we should update the commitment fee, in response to a change in the
network fee return by our fee estimators.
In this commit we update our glide file to point to the new version of
my fork of btcd with the fee estimator RPC merged in, and also the
version of btcwallet that allows callers to manually specify a value
for the fee rate of a given transaction.
In this commit, we add a new ResetState method to the channel state
machine which will reset the state of the channel to `channelOpen`. We
add this as before this commit, it was possible for a channel to shift
into the closing state, the closing negotiation be cancelled for
whatever reason, resulting the the channel held by the breachArbiter
unable to act to potential on-chain events.
With the new negotiation policy, we instead just need to ensure that
our fee inches closer to the other party’s with each iteration, and
that it’s within the proper bounds.
In this commit, we expose the new fee control features to the relevant
commands on the command line. This will allow users to have a greater
degree of control of the fees they pay when: sending coins on chain,
opening a channel, or closing a channel.
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.
