This commit refactors the proto definitions of the
reservation notifications to use a more generic
mechanism that can be used for other types of
notifications as well.
Previously we defaulted to fetching 1000 payments at a time when running
the cost migration however due to slowness on LND side this may prevent
the migration from completing due to RPC timeout kicking in. This commit
adds a new config value to give more control to the user by setting the
batch size as needed.
Updating the mocks to be complete implementation of the underlying
interfaces is not always possible due to cross dependency issues.
This commit embeds the interfaces into the mocks so we can at least
always compile them.
This is needed to avoid non-standard batch transactions (larger than 400k wu).
A non-cooperative input is 393 wu, so 1000 inputs are still under 400k wu.
Option WithMixedBatch instructs sweepbatcher to create mixed batches with regard
to cooperativeness. Such a batch can include both sweeps signed both
cooperatively and non-cooperatively. If cooperative signing fails for a sweep,
transaction is updated to sign that sweep non-cooperatively and another round of
cooperative signing runs on the remaining sweeps. The remaining sweeps are
signed in non-cooperative (more expensive) way. If the whole procedure fails for
whatever reason, the batch is signed non-cooperatively (the fallback).
Size of a signature affects the weight of transaction, which is verified
in tests.
Also method SignOutputRaw now returns the number of signatures matching
the number of signature descriptors to prevent crashes in tests where
multiple inputs are signed.
This commit transforms the looprpc subpackage into a versioned module.
By doing so, projects that rely solely on the generated RPC code from
the proto files will benefit from significantly reduced dependencies
during compilation.
Previously sweepbatcher used loop/labels.LoopOutBatchSweepSuccess to assign
transactions labels. The value is "BatchOutSweepSuccess -- $batch_id", which
does not fit use cases outside of loop-out. Now there is option WithTxLabeler
which sets a function used to generate the label.
Tested scenarios:
1. For a regular sweep newly added it waits for initialDelay + publishDelay
before publishing a transaction.
2. For a sweep recovered from DB it does not wait before publishing tx.
3. If a sweep is about to expire, initialDelay is skipped.
WithPublishDelay sets the delay of batch publishing that is applied in the
beginning, after the appearance of a new block in the network or after the
end of initial delay (see WithInitialDelay). It is needed to prevent
unnecessary transaction publishments when a spend is detected on that block.
Default value depends on the network: 5 seconds in mainnet, 0.5s in testnet.
For batches recovered from DB this value is always 0s.
WithInitialDelay instructs sweepbatcher to wait for the duration provided
after new batch creation before it is first published. This facilitates
better grouping. It only affects newly created batches, not batches loaded from
DB, so publishing does happen in case of a daemon restart (especially important
in case of a crashloop). Defaults to 0s. If a sweep is about to expire (time
until timeout is less that 2x initialDelay), then waiting is skipped.
Renamed defaultPublishDelay to defaultTestnetPublishDelay. Its godoc was already
for defaultTestnetPublishDelay, but the const was named defaultPublishDelay.
