The auctioneer will now provide a height hint along with every proposed
batch it sends to traders. This height hint is then used by each trader
to base off their absolute lease expiration height, such that they can
agree on the same value and avoid any divergences due to block
propagation discrepancies between them.
For the batch verify test, the dust limit is now smaller by 160
satoshis, so we reduce the main account by this amount in order to
commit a minimal diff, rather than overhaul the test to be more robust.
If we're the provider of a sidecar channel then we don't actually have
the private key of the funding multisig key. Therefore we cannot
re-derive it on demand and have to use the key provided in the sidecar
ticket instead.
We need to use the DefaultBatchStepTimeout variable outside of the
funding manager as well and move it to the order package to not create a
circular dependency when accessing it from the root package.
When validating a batch we need to make sure that all three parties
(maker, taker, server) come up with the same account ending state after
matching a bid order with a push amount.
Because the batch Versions are in the order package, the use of
order.DefaultVersion is confusing and not clear to be related to the
version of the _batch_, just from its name. We fix that by renaming the
versions of the batch.
Since this error caused quite some confusion among our users, we demote
it to info and change the text to further explain what's happened.
If a trader is involved in a batch and the channel funding fails in the
batch sign phase, a pending channel is never created in lnd. If the next
batch prepare message comes in, we try to clean up all pending channels
of the previous attempt. Because the channel negotiation failed and
there is no pending channel, cleaning up fails with this message.
We also need to make the channel abandonment independent of a particular
format of a pending batch, so we refactor it into a standalone function
instead of a method on the in-memory batch format.
We want to be able to clean up after a pending batch that is replaced.
We want to do this for both in-memory pending batches but also for
persisted local snapshot batches on startup. Therefore we need to
refactor the cleanup methods into independent functions.
To make iterating over batch IDs easier, we add a new helper function
that returns all batch IDs starting at the start key (inclusive) and
ending at the end key (inclusive) by decrementing the public keys. If
the end key cannot be reached by decrementing the start key by a maximum
of 10k times, we abort and return the first 10k items (without the end
key).
As a preparation to abandon canceled channels, we first extract the
utility method to locate a channel output created in a batch from the
batch verifier into the batch itself.
As a preparation to avoid package import cycles when introducing more
generic terms, we move the FeeSchedule interface and its
LinearFeeSchedule implementation to the terms package.
In this commit, we ensure that if we need to reject a batch for w/e
reason, then we also unregister all funding shims. Otherwise, if we
repeat a modified version of that batch, then we'd fail early as the
attempt to register than same shim would be rejected.
We need this method for further synchronization: once this is sent we
expect the traders to respond with signatures for each of the accounts
involved in the batch. The addition of this message also means that the
responder of the channel funding has time to register their shim (done
before they send their Accept message) as we don't send the
OrderSignBegin message until all traders have accepted the batch. The
initiator can now use receipt of the OrderSignBegin as a signal to
initiate the channel funding.
We also fix an existing oversight in the `OrderMatchSign`: it expected a
fully valid witness, but the only thing the traders can produce by
themselves is a signature for their input.
Previously, if the connection between the trader and auctioneer was torn
down before the trader received a batch's finalize message, then the
trader would lose all context about the batch they participated in.
Committing the batch before providing our signatures to the auctioneer
ensures that this cannot happen. Follow-up work will allow the trader to
obtain the latest information regarding a pending batch upon
reconnections.
