In this commit, we activate the merge queue by using the new merge_group
selector. Without this, the CI won't report back the progress of a CI
run to the merge queue, so things won't get auto merged.
Before this commitment, we'd end up failing in `schnorr.ParseSignature`
if a non-default sighash was used. To fix that, we'll slice the
signature to only pass in the sig w/o the sighash flag.
In this commit, we modify our gossip broadcast logic to ensure that we
always will send out our own gossip messages regardless of the
filtering/feature policies of the peer.
Before this commit, it was possible that when we went to broadcast an
announcement, none of our peers actually had us as a syncer peer (lnd
terminology). In this case, the FilterGossipMsg function wouldn't do
anything, as they don't have an active timestamp filter set. When we go
to them merge the syncer map, we'd add all these peers we didn't send
to, meaning we would skip them when it came to broadcast time.
In this commit, we now split things into two phases: we'll broadcast
_our_ own announcements to all our peers, but then do the normal
filtering and chunking for the announcements we got from a remote peer.
Fixes https://github.com/lightningnetwork/lnd/issues/6531
Fixes https://github.com/lightningnetwork/lnd/issues/7223
Fixes https://github.com/lightningnetwork/lnd/issues/7073
We start with a simple Map function that can be useful for transforming
objects on the fly.
We may want to eventually make this Taro pakage into a module so we can
just have everything in one place:
https://github.com/lightninglabs/taro/tree/main/chanutils.
In this commit, we modify the way we compute the starting ideal fee for
the co-op close transaction. Before thsi commit, channel.CalcFee was
used, which'll compute the fee based on the commitment transaction
itself, rathern than the co-op close transaction. As the co-op close
transaction is potentailly bigger (two P2TR outputs) than the commitment
transaction, this can cause us to under estimate the fee, which can
result in the fee rate being too low to propagate.
To remedy this, we now compute a fee estimate from scratch, based on the
delivery fees of the two parties.
We also add a bug fix in the chancloser unit tests that wasn't caught
due to loop variable shadowing.
The wallet import itest has been updated as well, since we'll now pay
600 extra saothis to close the channel, since we're accounting for the
added weight of the P2TR outputs.
Fixes#6953
In this PR, we introduce a new Github work flow tool that should help us
keep better track fo reviewer load across the proejct. Ideally this can
also be used as a tool to help new PRs find a reviewer, and also for us
to better balance out review load, and keep track of how long it takes
to do PR turnaround.
As usual, we keep with the last two Go versions, which means the last
year of Go release (they release every 6 months or so).
This change means we can now use the type params (generics) in the
project!
Bitcoind 23 will use the new `getdeploymentinfo` while versions after 19
(but below 23) will use the `UnifiedSoftForks` field instead of the
`SoftForks UnifiedSoftForks` field.
With this PR the taproot gating logic has been tested on bitcoind
versions: 21, 22, and 23. 21 is when the taproot logic was first added.
We forgot to do this after 0.15 was tagged, but usually we use a x.99
version to indicate that the commits in master are between releases.
This might also make it easier to help identify exactly which version a
user is running in issue reports.
[skip-ci]
In this commit, we modify the watch tower to use P2TR addrs for just
about anything sweep related.
One eye sore in this diff are the changes to
`backup_task_internal_test.go`. All the values are hard coded, and now
either differ by a value of 48, or needed to be modified to account for
the new assumptions propagated to rewards values and fees.
In this commit, we catch up our logic with the latest version of the
spec that removed support for normal p2kh and p2sh addresses for co-op
closes, in order to make dust calculations more uniform.
In this commit, we add awareness of the option_shutdown_anysegwit that
permits both sides to send newer segwit based addresses. This'll
eventually enable us to send taproot addresses for co-op close.
In this commit, we add a check during normal node construction to see if
the backend node supports Taproot. If it doesn't, then we want to
shutdown and force the user to take note.
To check if the node supports Taproot, we'll first try the normal
getblockchaininfo call. If this works, cool, then we can rely on the
value. If it doesn't, then we'll fall back to the getdeploymentinfo call
which was added in a recent version of bitcoind [1]. Newer versions of
bitcoind might also have this call, and the getblockchaininfo call, but
not actually populate the softforks field [2]. In this case, we'll fall
back, and we also account for the case when the getblockchaininfo RPC is
removed all together.
[1]: https://github.com/bitcoin/bitcoin/pull/23508
[2]: https://github.com/bitcoin/bitcoin/pull/25114Fixes#6773
In this commit, we add a test case to exercise the fact that if we
request a confirmation notification with the raw block, then it includes
one. We add this to the existing test that uses the conf ntfn rpc call
for simplicity.
In this commit, we add a new option for the existing confirmation
notification system that optionally allows the caller to specify that a
block should be included as well.
The only quirk w/ the implementation here is the neutrino backend:
usually we get filtered blocks, we so need to first fetch the block
again so we can deliver the full block to the notifier. On the notifier
end, it'll only be checking for the transactions we care about, to
sending a full block doesn't affect the correctness.
We also extend the `testBatchConfirmationNotification` test to assert
that a block is only included if the caller specifies it.
In this commit, we parse the new max fee field, and pass it through the
switch, all the way to the peer where it's ultimately passed into the
chan closer state machine.