The unit test sometimes fails with a connection timeout when trying to
connect to the reorg mining node. We attempt to make things more robust
by doubling both the number of retries as well as the retry timeout
itself.
Fixes#6386.
Bumps the btcutil/psbt library to the latest version v1.1.3 that fixes
an issue with de-serializing a PSBT that contains an unsigned
transaction with no inputs.
This commit adds a pair of encoder/decoder to take the advantage of the
BigSize format when encoding an uint64 and possibly an uint32.
Often the time an uint64 value is not big enough to fill all the 8
bytes, thus using BigSize can save extra bytes when save it to db. And
for uint32, if we know most of the values do not exceed 65536, we can
also save at least 1 byte using BigSize format.
This commit introduces `MakeBigSizeRecord` that can be used optionally
where db space is a concern.
Base the calculation on the actual float64 overflow point rather than an
indirect limit on probability.
This is a preparation for an infinite attempt cost.
In this commit, we update the min Go version to be version 1.18. This
breaks our prior rule of supporting the last two major versions, but
allows us to use the larger features in 1.18 sooner, such as the newly
released type parameters.
Fixes#6396.
This commit fixes a panic that occurred when trying to sign for a
Taproot output without specifying the full UTXO information for each
input. Instead of panicking an error is now returned.
In case of a multi shard payment with more than one in-flight shards,
one shard quitting with a terminal failure will stop the payment
lifecycle and close the `shardHandler`'s `quit` channel. In the
`collectResult` function we're waiting for the `Switch` to
asynchronously return a result for each shard. This may have been
interrupted by the aformentioned `quit` channel's closing skipping
attempt failure (or success) notification towards the control tower
and therefore skipping proper settle/fail info fill in the channel db.
Since payments have a composite state of a global failure reason and
settle/fail info for all attempts, any attempt with an unfilled
settle/fail info keeps a payment in-flight even if the payment itself
isn't in-flight anymore.
