We update several of our integration tests that exercise different
scenarios with regards to the broadcast of a channel commitment
transaction with HTLCs in-flight to use the new commitment type for
channel leases. We do this to ensure we have complete coverage of said
channel commitment type. This required changing several assumptions
throughout the tests based on when we should expect sweeps to happen.
This aims to cover an edge case and also serves as an optimization of
what happens when an input that was offered to the Sweeper with an
exclusive group is re-offered without one. This happens every time we
attempt to sweep the different possible anchors of a channel at the time
of broadcast, as we don't know which commitment transaction will end up
confirming in the chain. Once the commitment transaction confirms
however, we know which anchor output to act upon and re-offer it to the
Sweeper without an exclusive group. At this point, the Sweeper will
continue to attempt sweeping the other anchor output versions even know
we know they are not valid.
In order to sweep the commitment and HTLC outputs belonging to a
script-enforced leased channel, each resolver must know whether the
additional CLTV clause on the channel initiator applies to them. To do
so, we retrieve the historical channel state stored within the database
and supplement it to the resolvers to provide them with what's needed in
order to sweep the necessary outputs and resolve their respective
contracts.
This commit modifies the channel state machine to be able to derive the
proper commitment and second-level HTLC output scripts required by the
new script-enforced leased channel commitment type.
The new commitment type consists of adding an additional CLTV
requirement to guarantee a leased channel's expiration on any commitment
and HTLC outputs that pay directly to the channel initiator.
This commit adds the ability for a channel initiator/responder to
determine whether the channel to be opened can use a specific commitment
type through explicit negotiation. It also includes the existing
implicit negotiation logic to fall back on if explicit negotiation is
not supported.
This commit aims to address a flaw in our anchor reserve enforcement
logic in which an inbound "legacy" channel (i.e. a channel with a
commitment type that precedes anchors) would be rejected by the
recipient if they have at least one opened channel using the anchors
commitment type and do not have enough on-chain funds to meet the
anchors reserve.
We do this to trigger a bug that will be resolved in a follow-up commit.
This bug prevents inbound legacy channels from being rejected by the
recipient if they have at least one anchor channel already opened
without an on-chain balance.
This log can be "spammy" while nodes throughout the network have yet to
upgrade to v0.13.0-beta, which includes several enhancements to prevent
the broadcast of zombie edges/updates.
GetNodeInfo retrieves the policies for every edge the node belongs to.
When these policies are retrieved from the database, they're returned
in the following order: the first policy is the outgoing policy from the
node, and the second is the incoming policy to the node. This ordering
is not consistent with the ordering we have within our other RPCs like
GetChanInfo and DescribeGraph, where policies are sorted based on the
smaller public key of the nodes within an edge.
We fix this by maintaining the same order as our other RPCs.
This ensures the waiting receiving channel always receives an error to
prevent a deadlock when processing a network update that fails due to
the validation barrier.
On commit d5aedbcbd9:
1000 @ 0x43a285 0x44a38f 0xc42e86 0xc80fda 0xc8682d 0xc976c9 0x46fce1
github.com/lightningnetwork/lnd/routing.(*ChannelRouter).AddNode+0x245 github.com/lightningnetwork/lnd/routing/router.go:2218
github.com/lightningnetwork/lnd/discovery.(*AuthenticatedGossiper).addNode+0x3b9 github.com/lightningnetwork/lnd/discovery/gossiper.go:1510
github.com/lightningnetwork/lnd/discovery.(*AuthenticatedGossiper).processNetworkAnnouncement+0x574c github.com/lightningnetwork/lnd/discovery/gossiper.go:1554
github.com/lightningnetwork/lnd/discovery.(*AuthenticatedGossiper).networkHandler.func1+0x24github.com/lightningnetwork/lnd/discovery/gossiper.go:1043
Since we don't have to worry about network latency within our
integration tests, we can shorten the broadcast timeout for neutrino
integration tests from 5s to 1s.
We'd never decrement the number of pending backups upon a watchtower
accepting one, making it confusing for users to determine whether their
backups have actually been accepted. Along the way, we also rename
NumTasksReceived to NumTasksPending to better reflect its purpose.
Previously, we would always allow dependent jobs to be processed,
regardless of the result of its parent job's validation. This isn't
correct, as a parent job contains actions necessary to successfully
process a dependent job. A prime example of this can be found within the
AuthenticatedGossiper, where an incoming channel announcement and update
are both processed, but if the channel announcement job fails to
complete, then the gossiper is unable to properly validate the update.
This commit aims to address this by preventing the dependent jobs to
run.
The recently added gossip throttling was shown to be too aggressive,
especially with our auto channel enable/disable signaling. We switch to
a token bucket based system instead as it's based on time, rather than a
block height which isn't constantly updated at a given rate.
We do this instead of using the source of the AnnounceSignatures
message, as we filter out the source when broadcasting any
announcements, leading to the remote node not receiving our channel
update. Note that this is done more for the sake of correctness and to
address a flake within the integration tests, as channel updates are
sent directly and reliably to channel counterparts.
We do this instead of using the source of the AnnounceSignatures
message, as we filter out the source when broadcasting any
announcements, leading to the remote node not receiving our channel
update. Note that this is done more for the sake of correctness and to
address a flake within the integration tests, as channel updates are
sent directly and reliably to channel counterparts.
As similarly done with premature channel announcements, we'll no longer
allow premature channel updates to be rebroadcast once mature. This is
no longer necessary as channel announcements that we're not aware of are
usually broadcast to us with their accompanying channel updates.
This change was largely motivated by an increase in high disk usage as a
result of channel update spam. With an in memory graph, this would've
gone mostly undetected except for the increased bandwidth usage, which
this doesn't aim to solve yet. To minimize the effects to disks, we
begin to rate limit channel updates in two ways. Keep alive updates,
those which only increase their timestamps to signal liveliness, are now
limited to one per lnd's rebroadcast interval (current default of 24H).
Non keep alive updates are now limited to one per block per direction.
This addresses a potential panic when a tower has one of its candidate
sessions chosen, but its only reachable address was removed by a
user-initiated RPC before the fact.
A while back, changes were made to the wallet such that it waits for the
backend to be synced before beginning to store the latest 10,000 blocks
of the chain. This inherently broke sync progress implementations based
on the best_header_timestamp result from the GetInfo RPC for
neutrino-based nodes as the wallet is no longer tracking all blocks in
the chain. To work around this, we now make sure to return the backend's
best header timestamp instead of the wallet's, allowing said sync
progress implementations to work again.
This is useful when we wish to have a channel frozen for a specific
amount of blocks after its confirmation. This could also be done with an
absolute thaw height, but it does not suit cases where a strict block
delta needs to be enforced, as it's not possible to know for certain
when a channel will be included in the chain. To work around this, we
add a relative interpretation of the field, where if its value is below
500,000, then it's interpreted as a relative height. This approach
allows us to prevent further database modifications to account for a
relative thaw height.
This was initially done as there were a few assertions throughout the
codebase requiring a channel's policy to be known. Now that these have
been addressed, we no longer need to store restored channels in the
graph, as their policies where incomplete anyway.
The current implementation of LeaseOutput already checked whether the
output had already been leased by the persisted implementation, but not
the in-memory one used by lnd internally. Without this check, we could
potentially end up with a double spend error if lnd acquired the UTXO
internally before the LeaseOutput call.
This addresses a panic when a notification is canceled after its been
detected as included in a block and before its confirmation notification
is dispatched.
This is meant to handle a quirk in which key descriptors obtained
through walletrpc.DeriveKey don't result in the derived key being
persisted to the wallet's database, unlike with DeriveNextKey. Due to
this and some fallback logic in the wallet with regards to empty key
locators, if a request only specified the compressed public key, the
signature returned would be over a different key, namely the one derived
from (family=0, index=0).
Wilmer Paulino