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.
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.
Now that we have the self channel balance populated on the bid orders
and have also validated all diffs, we can set the push amount when
opening the channel as asker.
When validating a batch we need to make sure that all three parties
(maker, taker, server) come up with the same account ending state after
matching a bid order with a push amount.
We update the bid order submission CLI and add the --self_chan_balance
flag that will request an initially balanced channel to be leased.
To make sure that askers can signal that they understand that new
feature, we also bump the submitted order version for ask orders.
With this commit we add the new SelfChanBalance to the bid order. We
also add a new version for orders that signals compatibility with that
new field. A version increase on the ask side is needed to make sure the changes in
the asker's account balance are interpreted correctly on batch
validation.
We'll need to check the self chan balance (a.k.a. push amount) values in
several places, including the upcoming sidecar ticket functionality
itself. That's why we add these check functions to the sidecar package.
To make it way easier to add more data to orders, we add an extra key
in the order's bucket that will contain all future additional data
encoded as a tlv stream.
The PR containing this commit will likely become quite large as is and
therefore we don't want to overload it more by also adding a DB
migration. This can always be done in the future.
With the server now exposing this new RPC, we want to add the output of
it to the getinfo call to give users an idea what the current market
situation looks like.
To make initial triage easier and nudge people into reading the
documentation and gathering information before submitting an issue, we
add three issue templates: bug reports, feature requests and "other".
* Updated for a transaction close
* adding an extra line at the end of the file.
* sat_per_byte value update
As per PR review feedback, updating from 0 to something more realistic, like 11 sats per vbyte.
Co-authored-by: root <root@pop-os.localdomain>
