This change avoids enforcing new reserved value when PSBT funding is not
finished yet as new inputs and outputs may still be added that could
change the outcome of the check.
This originally failed in the scenario when funding a channel from
external wallet *and depositing to on-chain wallet* was done
simultaneously in a single transaction. If such transaction confirms
then reserved UTXO is guaranteed to be available but the check didn't
take it into account.
The enforcement still occurs in the final step of PSBT funding flow, so
it is safe. It also occurs in case of non-PSBT funding.
when payment_hash or final_cltv_delta and payment_request was set, the error message showed that the parameters shouldn't be set with dest instead of payment_request
[skip ci]
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.
