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.
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.
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.
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.
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.
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.
Because we have to always expect an OrderMatchPrepare to be sent
multiple times, we need to make sure we clean up our funding shims from
the previous pending batch.
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 relax the node addr requirement to only apply to
those that want to submit ask orders. If you're selling channels, then
you should be an actual routing node, meaning you're accepting inbound
connections. As a result, we now only apply this requirement, as this
allows those that needs inbound channels (putting in bids) to not be
exposed to the network.
In this commit, we add the missing logic to register for funding shims
when we're the taker of an executed order, and also to establish new
channels after we send OrderMatchAccept when we're the maker of an
executed order.
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.
