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.
A high max batch fee rate would reserve a lot of the account balance for
fees.
Note that if the actual fee rate goes higher than the max batch fee rate
set, then the orders won't be included in the batch, and the default
must be overridden.
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.
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.
In tihs commit, we modify the order acceptance commands (llm submit ask
and llm submit bid) to take the final percentage rather than the fixed
rate. Historically we've seen that people find thinking in fixed point
arithmetic difficult. So instead of exposing this value, we now poll the
user for the amount their willing to pay or accept as yield for the
_entire duration_.
With this change, users only need to think about the lump sum coupon
payment rather than the internal fixed rate. This should also lend to
better price discovery as distinct orders may end up with the same
rate_fixed when converted at the end.
In addition to this change, we now show a break down of the order
parameters which includes the execution fee.
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.
