Since the breacharbiter will publish an adjusted justice tx after
detecing a spend from the breached commitment, we could get into a race
where sometime it would not get the second spend before publication,
resulting in a deadlock on the publTx channel.
Now we instead wait for the publication of this adjusted tx before
notifying the second spend.
Fixes#5307.
Corrects some typos in the REST annotations for the routerrpc subserver.
Unfortunately these mistakes aren't caught by the current version of the
grpc-gateway library. But we intend to update to v2 soon which will
output alerts as mentioned in #5307.
In some rare instances it can happen that the nodes don't find each
other again after one of them has been re-created and the other one has
been restarted in the SCB tests. By making sure the re-created has the
same P2P port again as before, we make sure they can connect to each
other again successfully for executing DLP.
Since there is a lot of connecting and disconnecting between nodes in
the channel backup tests, we try to speed up that process by lowering
the min backoff from 1 second to 50 milliseconds. We also make sure we
never wait more than 1 second if it does take multple attempts. This
should sum up and hopefully speed up our tests a bit.
The Windows virtual machine that Travis runs the integration tests on
seems to be slower than the other machines. We try to increase the
stability of the tests by cutting the number of parallel running suites
in half. This will come at the cost of longer execution time but
hopefully with a better stability in return.
With this patch, we'll fail out earlier in the cycle in case of
some wonky parameters, and not leave zombie payments in the router
which currently are not cleaned up.
Fixes#5287.
The PSBT spec is a bit vague when it comes to the WitnessUtxo field of
an input as it's not strictly required for witness inputs. Therefore
Electrum for example does not include the field.
We need to make the SegWit input check a bit more elaborate by looking
at the output script of the UTXO and also the redeem script in case it's
a nested SegWit spend.
GetNodeInfo retrieves the policies for every edge the node belongs to.
When these policies are retrieved from the database, they're returned
in the following order: the first policy is the outgoing policy from the
node, and the second is the incoming policy to the node. This ordering
is not consistent with the ordering we have within our other RPCs like
GetChanInfo and DescribeGraph, where policies are sorted based on the
smaller public key of the nodes within an edge.
We fix this by maintaining the same order as our other RPCs.
Since we also must count revoked funds swept from second level revoked
outputs, we move the funds counting into the updateBreachInfo method,
where we already are checking whether the spend is by us or the remote.
We also clean up the logs a bit, to log the incremental sweep of funds
that now can happen.
We define a new struct justiceTxVariants, which holds three different
justice transactions:
1. The "normal" justice tx that spends all breached outputs
2. A tx that spends only the breached to_local output and to_remote output
(can be nil if none of these exist)
3. A tx that spends all the breached HTLC outputs (can be nil if no HTLC
outputs exist)
This will later be used to sweep the time sensitive outputs separately,
in case the normal justice tx doesn't confirm in time.
Now that we don't rely on the justice tx TXID anymore, we can remove
finalization of it. Instead we'll recreate the transaction when needed
from the persisted retribution info.
Since we want to potentially broadcast multiple versions of the justice
TX, instead of waiting for confirmation of a specific TXID, we instead
wait for the breached outputs to be spent.
inputs
Since we want to test more complex combinations of spends of the
breached outputs, we use two maps tracking
1. which transaction will spend the outpoint
2. which outpoints we expect the breacharbiter to include in the justice
tx
This let us trigger spends of the individual outputs, and depending on
what we want to test check whether the breacharbiter sweeps the expected
outpoints.
