This commit modifies the funding workflow slightly to move the querying
to the fee estimator (for the new channel) into the fundingManager
rather than within the LightningWallet layer. When querying to
FeePerWeight, we now multiply by 1000 to arrive at fee-per-kw.
Additionally, we now also properly thread through the fee-per-kw
offered by the initiator the to the responder of the channel workflow.
This commit modifies the fee calculation logic when creating or
accepting a new commitment transaction to use the set FeePerKw within
the channel rather then re-query the estimator each time. The prior
behavior was benign as we currently use a static fee estimator, but the
dynamic setting this could’ve caused a state divergence.
This commit corrects an error in the scaling as currently implemented
in the default static fee estimator. The spec draft has an error and
erroneously recommends multiplying by 4 to arrive at the fee-per-weight
from the fee-per-byte. This is incorrect as with the segwit block-size
increase, the ratio is 1/4 rather than 4.
This commit modifies the coin selection logic around selecting inputs
for a funding transaction to query the fee estimator directly (and use
fee-per-byte), rather than use the fee estimate which was passed into
the context.
We also use the value passed into the InitChannelReservation method
directly rather than make a call to the fee estimator. With this
change, the responder to a funding workflow will now properly adopt the
fee-per-kw suggested by the funder of the channel.
The remote balance in the case of a single funder workflow is simply
what ever the pushSat amount is. The capacity - fundingAmt in this
scenario would always be zero, so we simply just set it directly to
pushSat.
This commit modifies the name of a field in the OpenChannel struct to
better reflect its actual usage within this protocol. The FeePerKw
represents the amount of satoshi to be paid as fees per kilo-weight.
This field is set at the opening of a transaction and will be able to
be updated properly via the usage of the update_fee method.
This commit replaces the hard-coded 5000 satoshi fees with calls to the
FeeEstimator interface. This should provide a way to cleanly plug in
additional fee calculation algorithms in the future. This change
affected quite a few tests. When possible, the tests were changed to
assert amounts sent rather than balances so that fees wouldn't need to
be taken into account. There were several tests for which this wasn't
possible, so calls to the static fee calculator were made.
This commit adds the FeeEstimator interface, which can be used for
future fee calculation implementations. Currently, there is only the
StaticFeeEstimator implementation, which returns the same fee rate for
any transaction.
In order to cleanly handle shutdowns and restarts during state machine operation, the fee for the current
commitment transaction must be persisted. This allows the fee to be
reapplied when the current state is reloaded.
This commit changes the SingleHop and MultiHop integration tests to
assert amounts sent rather than balances. Because fees can be odd
amounts, this change makes it such that fee amounts don't need to be
explicitly taken into account in the tests.
In order to make the node's dust limit available to the wallet during
the initial stages of the funding process, add and set a
DustLimit field in the Contribution.
Primarily to avoid linting errors, the lnwallet.OP_CHECKSEQUENCEVERIFY
variable was removed and references to it replaced with
txscript.OP_CHECKSEQUENCEVERIFY.
This commit changes t.Fatal to t.Fatalf in TestCheckDustLimit so as to
provide more information. This commit also makes some column width
adjustments and minor spelling/formatting changes.
This commit fixes a panic due to a send on a closed channel that could
possibly occur depending on the order of channel closes when a client
goes to cancel a topology notification client.
Previously we closed the ntfnChan first, this would possible result in
a panic as the goroutine may have succeeded on a send at the same time
the channel was closed. Instead, we now close the `exit` channel first
which is meant to be a signal to the goroutine that the client has been
canceled.
This commit reverts a prior commit
178f26b8d5ef14b437b9d8d1755bd238212b4dec that introduced a scenario
that could cause a state desynchronization and/or a few extraneous
commitment updates. To avoid such cases, the commitment tick timer is
now only started after _receiving_ a commitment update.
This commit fixes a panic bug in the watiForChanToClose method caused
by a logic error leading to the return value of the function at times
being a nil pointer in the case that an error occurred. We now avoid
such an error by _always_ returning from the function if there’s an
error, but conditionally (in a diff if-clause) sending an error over
the error channel.
This commit updates two interface-level tests for confirmation
notifications to check the txIndex and blockHeight advertised to serve
as regression tests for the recent bug fix related to properly setting
these two fields.
This commit fixes to distinct bugs in the way we previously dipatched
notifications for transactions which needed a historical dispatch.
Previously we would compare transactions when scanning the block using
the `tx.Hash` field. This was incorrect has the `Hash` field is
actually the wtxid, not the txid which should be the item being
compared. We fix this within the second bug fix by actually using the
txid to find the proper transaction.
The second fix has to due with a slight race condition which led to an
off-by-one error when dispatching the historical confirmation. If while
we were dispatching the confirmation, a new block was found, then we
could calculate the wrong block height (off by one) as we were using
the ‘currentHeight’ instead the height of the block which included the
transaction.
This commit modifies the processing in the routing package eo new
announcements. Previously, if we cgot a cnew channel announcement but
didn’t yet know of the verses that the chanell connected, the
cnnounacment would be accepted. This behavior was eronoues as if the
channel were to be queried for, the DB query would fail as we would be
unable to retrieve the two nodes involved int he channel.
To avoid such an error case, we will now _reject_ any channel
announcements in which we don’t yet have a valid node announcement for
the connected nodes. This case has been inserted into the handling of
channel announcement, a new test has been added, and finally older
tests have also been updated to ensure that nodes are added to the
database _before_ the edge is.
This commit fixes a slight logic error that could render the
`pendingchannels` RPC unusable if a node was on the reciting end of a
channel force close with no time-locked balance. In such a case the
channel wouldn’t be sent to the utxoNursery, resulting in an “contract
not found error”.
To fix this behavior, we’ve created a typed error that can be checked
within the RPC, thus we no longer treat this routine case as an error
case.
This commit fixes a slight logic error in the breachArbiter. Previously
we wouldn’t watch a pending channel for closure if the regular
(settled) balance was non-zero. However, this was incorrect, as it’s
possible for us to be on the receiving side of a channel force closure.
This error would leave certain channels as “pending close zombies”
forever until a user manually deleted the entry (or promoted it to be
fully closed).
To fix this, we now utilize the new `TimeLockedBalance` field to make a
better judgment as to if the utxoNursery is watching over a channel or
not.
This commit adds the total time locked balance of a closed channel at
closure time to the CloseChannelSummary struct. With this information,
we now provide sub-systems within the daemon further knowledge which
can aide them in properly handling querying for the state of pending
close transactions, or if they should watch a channel for closure or
not.
This commit fixes a deviant in the way we serialize and deserialize the
node announcement message from that which is currently in the spec.
Before this commit we reversed the order of features and addresses.
Instead, on the wire, features should come _before_ the addresses.
We also add a new temporary feature bit to ensure nodes that don’t
directly connect to each other if they don’t have this new update.
However, this will also partition any current tests nets when new nodes
join them as the digest signed has changed, therefore invalidating any
older messages.
Fixes#207.
This commit allows users to sign messages with their node's private key
with the SignMessage interface. The signatures are zbase32 encoded for
human readability/paste-ability. Others users can verify that a message
was signed by another node in their channel database with the
VerifyMessage interface.
This commit fixes a bug that was introduced when the connection
handling was re-worked to properly handle the case of concurrent
connections being made. In certain cases after a successful initial
connection, a peer’s stray goroutine would still attempt to establish a
second outbound connection even though a connection had already been
established. This was properly handled by the connecting peer, but not
he receiving peer. This commit adds the additional logic to the
receiving peer to ensure that we properly handle this case.
This commit fixes a bug which could at times cause channels to be
unusable upon connection. The bug would manifest like the following:
two peers would connect, one loads their channels faster than the
other, this would result in the winning peer attempting to extend their
revocation window. However, if the other peer hadn’t yet loaded the
channel, then this would appear to them to be an unknown channel.
We properly fix this issue by ensure all channels are loaded _before_
any of the goroutines needed for the operation of the peer are
launched.
