When trying to enable a single unified REST proxy in LiT, we noticed
that one URI collides between Loop and Pool (/v1/lsat/tokens).
We change the URI in Pool to fix the collision.
This is a potentially breaking change! Though we do not use REST in LiT
and are not aware of other projects using Pool's REST API yet so it
should impact a small number of users (or nobody really in the best
case).
With this commit we update to v0.1.6-beta of the aperture dependency
which fixes the issue of pending LSAT tokens not being removed even if
the payment failed for good.
To make sure we don't just block for forever if another Pool daemon
process is already running, we add a timeout and error out if obtaining
the unique file lock fails after 5 seconds.
There is an open issue for Python gRPC clients that is
currently being debugged https://github.com/grpc/grpc/issues/23172
It can be mitigated server-side by specifying h2 in the metadata header.
A sidecar channel uses different multisig keys than a normal order so we
need to fix the lookup in the batch transaction. While we're at it, we
might as well return the self chan balance and whether it was a sidecar
channel in the leases response.
With the RPC methods now in place, we add a new sidecar subcommand to
our CLI and add verbs for interacting with sidecars to it.
Because the ticket is in an encoded form we also add a printticket
subcommand for easy inspection.
With this commit we add the ability to both create/expect a sidecar offer as a
provider as well as registering an offer as the recipient to the main
RPC server.
If we're the provider of a sidecar channel we don't have to register a
funding shim or connect out to the taker. We'll just have to provide the
signature in the next step.
If we're the provider of a sidecar channel we don't have to wait for an
incoming channel as that won't be opened towards us. Therefore if there
are only sidecar channels in a batch, we don't have to wait at all.
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.
Whenever we are expecting a sidecar channel with us as the recipient, we
subscribe to the auction server through the special new SubscribeSidecar
RPC that works exactly the same as the SubscribeBatchAuction with the
only difference that we can use our channel funding multisig key as the
authentication key instead of the trader account key.
We have to react to all batch auction messages but our role is somewhat
simplified as we don't have to fully verify or sign the batch itself.
If we are the receiver of a channel, all we have to do in the channel
setup (OrderMatchSign) step is wait for all expected channels to be
opened to us in time.
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 business logic for creating a sidecar
channel offer as the provider.
We choose the funding manager as the place for this logic as that
already has most of the required lnd clients and will ultimately be
responsible for kickstarting the funding of the sidecar channel on the
provider's side.
With this commit we add a new sidecar acceptor type that is exclusively
responsible for managing the recipient's tasks of executing a sidecar
channel. The two tasks are:
1. Verify a sidecar ticket and the offer contained within then add the
recipient node information to the ticket so it can be returned to the
sidecar provider. This is step 2/4 of the entire sidecar execution
protocol.
2. Interact with the auction server and connect out to an asker's node in the
right moment then accept the incoming channel. This is step 4/4 of the
entire sidecar execution protocol.
The code for these two tasks are kept separate from the default funding
manager to make it easier to extract a standalone sidecar acceptor
client later on. It also makes it easier to see what code would need to be
re-implemented in another language to integrate just the acceptor part.
The account recovery process uses a bi-directional streaming RPC on
the server side. Unfortunately, because of the way streaming RPCs
work, the LSAT interceptor isn't able to _purchase_ a token during
a streaming RPC call (the 402/payment required error is only returned
after the interceptor was handed the call, so it cannot act on it
anymore). But since a user that has lost their data most likely als
lost their LSAT, the recovery will fail if this is the first call to
the server ever. That's why we call an RPC that's definitely not on
the white list first to kick off LSAT creation.
As a preparation for allowing multiple managers to consume the pending
channel updates, we move those events from a single channel to a
subscribe.Server construct.
We also pass in the subscription client to use into waitForChannelOpen
so we can use a different one in different flows.
As a preparation to be able to serve the pending channel updates from
lnd to multiple internal subscribers, we move the handling of those
events to the funding manager itself.
As a preparation to add non-exported fields to the funding manager, we
want to create a NewManager function that takes a config instead of
instantiating the manager directly.
To prepare for accepting sidecar channels where we don't have a real
order item in our local database, we use the order fetcher function in
the funding manager instead of the DB directly. That way we can pass in
fake bid orders during the sidecar acceptance.
The channel funding process for a sidecar channel will look different
from the normal process. To avoid too much code duplication, we first
extract the parts that remain the same into its own method.
We no longer need to hold a mutex since when we get to the
waitForChannelOpen method all previously spawned goroutines must have
completed.
The name SubscribeAccountUpdates could indicate that this is a
long-running operation. The method returns after successful
authentication of the stream though. That's why we rename it to
StartAccountSubscription and update the comment to make it more clear
that this should return after a few seconds at the most.
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.
Both the trader offering to buy a sidecar channel for another node as
well as the recipient node will need to store the involved sidecar
tickets in their local databases. We add a simple store interface and
its implementation that will be used in future commits.
For proper and safe channel acceptance the recipient node also needs to
know which key index it used for a ticket's multisig key so it can sign
the authentication flow with the auctioneer correctly (which takes a key
locator and not key descriptor).
To make the offer and sidecar contract more explicit, we also include
the lease duration in blocks in the offer part. This field will
overwrite any value set when using the CLI to submit the bid order.
With this commit we add a first description and HOWTO about what sidecar
channels are and how they can be created.
We add this commit first to give any reviewer the full context about
what we're trying to achieve first.
With everything else in place, we now only need to add and start a
channel acceptor that looks at each incoming channel and rejects it if
the push amount offered doesn't match the value in the bid order.
We'll add a channel acceptor in the next commit that verifies self chan
amounts for incoming channels. We need to notify that acceptor about new
funding shims that we register when receiving new order matches.
Otherwise the acceptor won't be aware of the bids and their current
pending channel ID.
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.
