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.
In this commit, we remove the raw channel state machine pointer from the
chan closer and instead replace that with an interface that captures
*just* the methods we need in order to do the co-op close dance.
This is a preparatory refactoring for some upcoming unit tests.
In this commit, we stop clamping the ideal fee rate to the commitment
fee of the channel. This catches us up to this PR of the spec:
https://github.com/lightning/bolts/pull/847.
We also do away with the old 3x ideal fee "max fee", and replace that
with an explicit max fee. This new max fee will either be the default
multiplier of the ideal fee, or a new user specified max fee value.
In this commit, we fix a detected flake: we go to make a payment, and
then want to assert that 2 attempts we required. The existing logic
assumes that the success and the payment will still be on disk. With a
recent PR, we now delete failed payments by default, but after the fact,
in a non-atomic fashion.
We fix this issue simply by having all the nodes keep around failed
payments for the sake of all the old itests that assumed this
information would always be on disk.
Introduced in: https://github.com/lightningnetwork/lnd/pull/6438.
Fixes https://github.com/lightningnetwork/lnd/issues/6711.
In this commit, we modify the `macaroons.NewService` consturctor to
accept the main interface rather than the raw DB. This allows us to use
other backends other than bolt or the kvdb interface to store the
macaroon root keys.
We also create a new ExtendedRootKeyStore interface that implements some
of the more advanced features we use such as macaroon encryption and
password rotation.
In this commit, we consolidate the _lease specific_ logic for the
success and timeout HTLC resolvers. We do this with the addition of a
new struct which is then composed via struct embedding with the two
existing structs. This fixes a flake in the integration tests by
ensuring the height is set up front, rather than eventually once the
height matches the lock time.
This commit upgrades to the latest version of btcwallet that fixes an
issue that would cause us to not properly sign a validate populated PSBT
in certain scenarios.
Fixes https://github.com/lightningnetwork/lnd/issues/6579
Olaoluwa Osuntokun