This commit removes a merge artifact introduced by a rebase of a
previous PR.
While we're at it, we streamline the grammar, formatting and general
look-and-feel of the release notes.
Because we pass in the same config into multiple notifiers, we sometimes
get a data race in the unit tests. By creating a copy of the config we
avoid that.
Since we fixed a number of issues in chainntnfs.NewBitcoindBackend that
makes it compatible with bitcoind v26.0, we now want to use that
function in all our unit tests.
With the chainntnfs.NewMiner now being optimized for not creating
nodes with colliding ports, we use it in all unit tests that spin up
temporary miners.
This commit fixes a number of issues with our temporary bitcoind nodes
that we spin up for unit tests:
- We didn't remove the node's temporary data dir after tests finished.
- We used random ports which lead to unwanted port collisions.
- We used ipc:// unix sockets for ZMQ which currently isn't supported
in bitcoind v26.0 due to a regression. Since we can reliably create
new non-colliding ports now, we should use TCP for ZMQ anyway.
With this commit we create a new function that returns system wide
unique ports by using a single file to keep track of previously used
ports. We'll want to use this everywhere whenever we need to listen on a
new, random port during unit or integration tests.
Because we now have a unique source, we don't need to apply the port
offset that was used for the different tranches of parallel running
integration tests before.
To make it less confusing what version of bitcoind is actually
installed, we now require the version to be specified as a command line
argument.
Because we tag the version in the docker image tag as bitcoin-core:XX
but the binary internally is located under /opt/bitcoin-XX.Y/, we
manually set Y to 0.
To avoid build caches getting larger and larger, causing our builds to
fail, we separate the caches of the different job types.
If we don't separate them, then the caches can end up being a
combination of the different jobs, which isn't useful (for example the
build cache of the cross compilation build isn't useful in an
integration test and vice versa).
This commit gives the linter container access to the local machine's
build and module cache, drastically decreasing the run time of
subsequent linter runs (no difference on first run with this change).
In this commit, we bump the version of the master branch to v0.17.99.
This reflects the fact that master will be a super set of all the minor
releases until v0.18, and will also include changes towards v0.18.
This commit adds a new sub command to the wallet that allows using the
new funding option from a template.
Creating a new command is way easier for the user to understand than
adding multiple flags that are only valid in certain combinations.
For the itest in the next commit we'll need to be able to fetch the
input information for an address over RPC. The only piece missing is the
address' index, which we add in this commit. Everything else should be
derivable from the ListAddresses and ListAccounts calls.
In some situations (for example in Taproot Assets), we need to be able
to prove that an address is a bare BIP-0086 address that doesn't commit
to any script. We can do that by providing the BIP-0032 derivation info
and internal key.
In the following commits we'll add a new, third, funding option for
funding PSBTs: It will allow users to specify pre-selected inputs but
still request the wallet to perform coin selection up to the total
output sum amount.
This is a helper function that we will need to accurately determine the
weight of inputs specified in a PSBT.
Due to the nature of P2WSH and script-spend P2TR inputs, we can only
accurately estimate their weights if the full witness is already known.
So this helper function rejects inputs that use a script spend path but
don't fully specify the complete witness stack.
We want to re-use the logic that determines what change amount is left
over depending on whether we add or don't add a change output to a
transaction, respecting the change output's dust limit.
We'll want to be able to tell the coin selection algorithm that we
intend to add any change to an existing output instead of assuming that
a change output is always created.
If we add any left over change to an existing output, we can skip the
dust amount check as we assume the selected existing output already has
a non-dust amount requested (responsibility of the caller to assert).
Before this commit the coin selection logic in the chanfunding package
would always assume that there is a P2WSH funding output and potentially
a P2TR change output. But because we want to re-use the coin selection
for things other than just channel funding, we make the logic more
generic by allowing us to specify both the existing weight of the
transaction (the already known, static parts of the TX) as well as the
type of the potential change output we would use.
With this commit we prepare for the lnwallet channel funding logic to be
aware of the config-level coin selection strategy by adding it to the
wallet config.
Oliver Gugger