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.
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 add a new test that fails with the current logic in
`validateOrder`. The function as isn't doesn't isolate the orders for
each account, so the orders from account A can prevent a user from
making an order to account B.
The funding feerate field was previoulsy unused, so we rename it to
"max batch fee rate" in order to use it to communicate to the server the
maximum fee rate we are willing to pay to be included in a batch.
We also increase the default value to 500 sat/vbyte.
The ReservedValue method returns the worst case value the must be
available in the account to ensure the trader can pay for the order
including its fees.
This is a follow up to #21. In this PR increase the fixed rate
denominator from 1e6 to 1e9 (a factor of 100x), which will allow us to
express a per-block lease rate for the smallest possible order (1 unit,
or 100k sats) over the longest possible lease period (6 months).
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.
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.
We use the same proto message types everywhere for these kinds
of fields:
- absolute amounts (sats): uint64
- fee rates (sat/kWU): uint64
- fee rates (ppm): uint32
- blocks (absolute and relative): uint32
Additionally we unify the comments and remove the [ json_name = "" ]
declarations in the trader proto as they aren't needed with the
jsonpb marshaller that we use.
Then we align the naming of the account key to be called trader key
everywhere instead of user's sub key.
