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.
The local database can now store a sidecar ticket with a bid order. We
now also need to accept it on the local RPC interface and forward it to
the auctioneer.
With this commit we add the optional sidecar ticket to bid orders.
Because the node submitting the bid order doesn't necessarily need to be
the node creating the offer, we just store the ticket as is and don't
require it to be in the database already.
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.
With this commit we add the new SelfChanBalance to the bid order. We
also add a new version for orders that signals compatibility with that
new field. A version increase on the ask side is needed to make sure the changes in
the asker's account balance are interpreted correctly on batch
validation.
The order manager already stores the local lnd node's identity public
key. We return it in an exported method so the RPC server can access it
as well without needing to query it again.
To make sure we only allow querying it after the manager is started, we
add an atomic flag for the startup state.
We add a new order version that is allowed to submit lease durations
outside of the default/legacy 2016 block duration.
No new fields are added, so nothing changes in the serialization or the
digest. This version only signals that the client is able to process
batch requests with multiple duration buckets.
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).
In this commit, we introduce a new field to only bids (for now): a min
node tier. This node tier is meant to allow buyers to express the level
of "quality" they're interested in for a given purchased channel. This
quality is determined using the current server-side rating system. The
base node tier are those considered "above the cut", this is also the
default tier: t1. The next node tier is t0, and is the buckets all other
nodes fall in. As the tiers rise, the number of nodes in each tier
shrinks, as these are meant to be the upper percentile of all nodes.
NOTE: The way this is implemented is actually a _breaking change_ from
the perspective of orders as we add a new field, which is included in
the order digest, without also bumping the version.
In this commit, we replace the existing min/max duration system with a
single field that expresses the expected duration of a lease. Note that
we've left some of the exiting logic in place that select a duration
from a bid in an attempt to make this more of a "soft fork" which will
allow any existing orders to be cleared out as normal before we switch
over.
Once we add multiple durations (this commit assumes a single duration),
we'll need to modify the verification logic to be able to handle
multiple clearing prices for a given batch.
We add a couple of order specific events which we use to track the
activity around orders. Some events track the timestamps at which we
persist a change to orders, other events track more volatile occurrences
of the match making process.
In this commit, we allow Tor addrs to be attached to orders. This will
allow clients to buy/sell channels using a Tor node, or a Tor-only node.
A follow up commit to this will adjust the client-side logic to have the
asker connect out to the bidder as well if the asker is behind a Tor
node.
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.
