Since bbolt returns references to internally stored data when storing
locally it's best to copy the byte slices returned or alternatively
convert them to string (which also makes a copy) to avoid crashes casued
by memory corruption.
This commit removes the context as a param needed when calling methods
of HarnessNode. This change moves the context management inside
HarnessNode, aside from saving us a few lines, it makes the context
creation/timeout less error-prone.
This commit adds a running context to HarnessNode which replaces all the
background context used and also serves as a way to signal quit when the
test is shutting down.
Instead of hard coding a commit to use for a binary tool that we use
during the build process, we now only use "go install" to install the
binaries and the golang builtin versioning system to pin the exact
version/commit we want to use in go.mod.
In this commit, we fix an API inconsistency introduced by a recent fix.
Without this commit, it would be possible for a local user to attempt an
explicit funding type, but then _fallback_ to implicit negotiation if
the remote party didn't have the bit set.
We resolve this by adding a new bit of information to ensure that if
we're the funder and want explicit chan negotiation, we don't settle
for anything less. A new test case has been added to exercise this
behavior.
To recap for posterity, the following issues were found and fixed in the
negotiation logic:
1. If the remote party sent a channel type (in accept channel), but we
didn't, then we would error out. We no longer error out and instead
ensure the channel type they sent matches what we derived via
implicit funding.
2. If the remote party _did not_ have the bit set, but they sent a
chan type (in open channel), we would error out. We no longer error
out, but instead will fall back to implicit negotiation.
Ultimately we want to eventually flip the explicit funding bit to
_required_ to eliminate any other future ambiguities and also ensure
that it isn't possible to inadvertently fall back to implicit funding,
when the _user_ expects explicit funding.
In this commit, we fix a bug that would cause newly updated nodes to be
unable to start up, if they have an older channel that was closed before
we started to store all the historical state for each channel.
The issue is that we started to write the complete state to disk, but
newer channels don't have it, so when we try to supplement the
resolvers, we run into this error.
Ultimately, we only need this new supplemented information for script
enforcement channels. Ideally we would instead check the channel type
there instead, but it doesn't appear to be available in this context as
is, without further changes.
Fixes https://github.com/lightningnetwork/lnd/issues/6001.
This fixes an issue where if one tries to unset a feature like anchors,
and other feature depend on it, then `lnd` fails to start as it realizes
that its dependnacy set is inconsistent.
Fixes https://github.com/lightningnetwork/lnd/issues/6002
Fixes#6013.
This commit fixes the Tor healthcheck that would previously fail if
there were multiple hidden service registered.
In the controller, we only need to know that our service is contained in
the list of active services. But we can't do a string equality check
since there might be multiple services, comma separated.
As is customary with new GitHub actions, they don't work on first
attempt if you don't test them *sigh*
We need to use a more recent version of golang than is pre-installed to
avoid the "unknown directive: retract" error message.