This change narrows the import scope for lightning-node-connect (LNC).
Instead of importing the entire pool package, LNC now only needs to
import poolrpc.
It also brings pool in line with the structure used in our other
projects.
This includes upgrading the logging framework to the V2 framework. This
new framework lets us deprecate the `maxlogfiles` and
`maxlogfilesize` config options.
Since any version prior to v0.15.4-beta will not sync to the mainnet
chain, we can safely bump the minimum required version to that since no
older version will be running (properly) anywhere.
This commit bumps the compile time dependency of lnd and lndclient to
the 0.16.x branch. This makes the code forward compatible but does not
yet change anything with respect to the minimum required version the
user needs to run.
During the integration tests we might want to shut down a trader client
through the admin RPC. If that closes the shutdown channel on a package
global interceptor, that means we can't start another trader client
during that test. We need to make sure we can pass in an interceptor for
each trader instance.
With lnd 0.15.0 almost out of the door, it is reasonable for us to ask
users to be on the latest 0.14.x version.
We use the walletrpc.SignPsbt method in Pool which was added in 0.14.2.
This commit moves the RequiredPermissions map to its own directory so
that projects importing the permissions list dont need to import all the
dependencies of the pool package.
Since the code for creating and using a macaroon service is the same for
multiple projects (pool, loop, litd etc), the code has been unified in
lndclient. So this commit removes the macaroon service code and instead
uses the lndclient code.
A new variable for the connected lnd node's version was added but was
not given a value when run in subserver mode within LiT.
This commit uses the lnd service's cached version directly and removes
the uninitialized variable.
In the integration tests we stop the pool daemon but don't exit the main
process. So it can happen that the underlying bbolt DB isn't properly
closed and when the daemon is started again during the test it runs into
a timeout. We fix this by properly closing the DB when the service is
stopped.
The macaroon service doesn't close the backend anymore because in the
lnd context the backend connection could be a shared connection to a
remote DB that we don't want to close when we start/stop the service
itself.
With this commit we update to the latest lndclient version of the 0.14.0
branch that reverts a breaking change in the basic client and also fixes
a "close of closed channel" panic.
This commit bumps pool to lndclient 13-7 so that code that depends
on lnd 0.13 can import pool. As is, pool is running with lndclient 0.12,
but pins minimum version to 0.11, so we are already in a state where
some of the apis available at compile time are not enforced by minimum
run version.
This commit bumps this minimum version up to 0.12 to minimize the
difference between the compile and runtime lnd version.
If users are only connected to the network through nodes with high fees
even the 5% default routing fee for the LSAT might not be enough. To
avoid them needing to compile Pool with a custom value, we expose that
value as a config option.
The RPC server won't be created by the time we attempt to reach for this
pointer, so we use a function closure to allow "lazy" evaluation which
only attempts to derf once the system is already up and running.
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.
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 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.
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 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.