The main idea is that NotifyContractUpdate adds the ContractUpdate to
a map called unmerged. It is populated in Start by shallow-copying the
activeHTLCs map values (htlcSet). The htlcSets underlying maps are not
copied, and so unmerged will just contain pointers to them. This should
be fine since unmerged will not modify them. At the call-sites of
activeHTLCs, it is updated to include the unmerged sets. This happens
with a mutex and should not cause any data race, even though it is
copying the underlying map pointers. No persistence should be
necessary since on restart, activeHTLCs and unmerged will just be
populated again.
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.
In this commit, we start to ignore the option to allow the caller to use
the legacy onion payload. The new payload is much more flexible and
efficient, so there's really no reason to still use it, other than for
backwards compatibility tests. Our existing tests that exercise the
legacy feature uses a build tag, which forces nodes to not advertise the
new payload format, which then forces path finding to include the legacy
payload, so we can be confident that route is still being tested.
The existence of this option (which actually makes the TLV payload
opt-in for `SendToRoute` users) makes it harder to remove it from the
protocol all together. With this PR, we take a step forward to allowing
such a change which is being tracked on the spec level at:
https://github.com/lightning/bolts/pull/962.
In a future release, we'll move to remove the field all together.
Ignoring the field today doesn't seem to have any clear downsides, as
most payments always include the MPP payload (due to payment secrets),
so this shouldn't impact users in a significant way.
