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.
In this commit, we change the key stored within the internal order kit
into a raw pubkey array. Along the way we fix a bug in the verifier
tests due to using a map with pointer keys rather than the actual value
itself.
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.
The mapping in this function ensures that a given bid/ask pair will have
a unique deterministic pending channel ID to use when registering
funding shims and also making channels.
This commit aims to address a current gap within the system where trader
account states can become desynchronized if they participated in a batch
and they never received a Finalize message from the auctioneer.
From now on, if an account spend arrives while a trader has a pending
batch, then we assume they weren't able to receive its Finalize message,
and use the spend as an indication that the batch has been finalized.
This works because if a trader signs for a batch and disconnects, the
batch should have already been persisted, and if the batch was actually
finalized (i.e., broadcast without any changes), then the account should
have been spent.
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.
This commits serves as preparatory work for committing a pending batch
before providing signatures to the auctioneer. This is achieved by first
storing the batch as pending upon receiving a new batch and marking it
as complete upon receiving a finalize message.
Some of the test cases relied on a map's keys always being in the
order they were defined, which is not guaranteed by the runtime.
A data race is also fixed by creating a new instance of the verifier
for each run.
