GlcoinCore/pool
1
0
Fork 0
mirror of https://github.com/lightninglabs/pool.git synced 2026-08-17 13:06:52 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update README

Browse source 
Mirror one-pager in terms of content and add some other items that are immediately useful
This commit is contained in:
Justin OBrien 2020-10-29 08:45:31 -10:00
parent c794dd3181
commit 7e2279dc45
1 changed files with 35 additions and 63 deletions
Download patch file Download diff file Expand all files Collapse all files

98
README.md
View file

@ -1,76 +1,48 @@
# Lightning Pool
Lightning Pool is a non-custodial batched uniform clearing-price auction for
Lightning Channel Lease (LCL). A LCL packages up inbound (or outbound!) channel
liquidity (ability to send/receive funds) as a fixed incoming asset (earning
interest over time) with a maturity date expressed in blocks. The maturity date
of each of the channels is enforced by Bitcoin contracts, ensuring that the
funds of the maker (the party that sold the channel) can't be swept until the
maturity height. All cleared orders (purchased channels) are cleared in a
single batched on-chain transaction.
Lightning Pool is a non-custodial, peer-to-peer marketplace that allows node operators that need inbound liquidity to pay node operators with available capital to open channels in their direction while retaining full custody of their funds. Pool’s first product is a Lightning Channel Lease - an inbound channel with a pre-agreed duration.
The existence of an open auction to acquire/sell channel liquidity provides all
participants on the network with a more _stable_ income source in addition to
routing network fees. By selling liquidity within the marketplace, individuals
are able to price their channels to ensure that they're compensated for the
time-value of their coins within a channel, accounting for worst-case force
close CSV delays.
Efficient capital allocation is one of the most widely felt pain points when using the Lightning Network. Existing node operators do not have access to pricing signals to help determine where in the network their outbound liquidity should be allocated, and new node operators have no way to signal that they need new inbound liquidity. Lightning Pool brings these two sides together into a single market while allowing them to maintain custody of their funds.
Pool critically allows participants on the network to exchange pricing
signals to determine where liquidity in the network is most _demanded_. A
channel opened to an area of the sub-graph that doesn't actually need that
liquidity will likely remain dormant and not earn any active routing fees.
Instead, if capital can be allocated within the network in an efficient manner,
being placed where it's most demanded, we can better utilize the allocated
capital on the network, and also allow new participants to easily identify
where their capital is most needed.
Checkout our [documentation](#tk) to learn more.
Amongst several other uses cases, the Pool allows a new participant in the
network to easily _boostrap_ their ability to receive funds by paying only a
percentage of the total amount of inbound funds acquired. As an example, a node
could acquire 100 million satoshis (1000 units, more on that below) for 100,000
satoshis, or 0.1%. Ultimately the prices will be determined by the open market
place.
## How it works
Lightning Pool is a non-custodial auction for liquidity where bids are kept private and trades clear periodically. Key aspects of Pool include:
- **Periodic clearing** - Market does not clear continuously, instead, it clears every block (or after multiple blocks, if there are no bids that match with existing asks).
- **Non-custodial** - Clients maintain an on-chain account that is a timelocked, 2-of-2 multisig with the auctioneer. These funds are fully in the user’s control at all times.
- **Sealed-bid** - All orders are submitted off-chain to the auctioneer, so bidders don’t have visibility into the bids of other participants
- **Uniform clearing price** - All participants in a batch clear at the same price. If your ask is for 2% annualized interest, you will receive >=2%. If you bid 5%, you will pay <=5%.
- **Batched execution** - Due to the account structure, the auctioneer is able to batch all completed orders into a single transaction, greatly reducing individual chain fees.
A non-exhaustive list of use cases includes:
* **Bootstrapping new users with side car channels**: A common question
posted concerning the Lightning Network goes something like: Alice is new
to Bitcoin entirely, how can she join the Lightning Network without her,
herself, making any new on-chain Bitcoin transactions? It’s desirable to a
solution to onboarding new users on to the network which is as as simple as
sending coins to a fresh address. The Pool solves this by allowing a third
party Carol, to purchase a channel _for_ Alice, which includes starting
_outbound_ liquidity.
## Installation
Download the latest binaries from the [releases](https://github.com/lightninglabs/pool/releases) page.
* **Demand fueled routing node channel selection**: Another common question
with regards to the LN is: "where should I open my channels to , such that
they'll actually be routed through"?. Pool provides a new signal for
autopilot agents: a market demand signal. The node can offer up its
liquidity and have it automatically be allocated where it's most demanded.
## LND
Note that LiT requires `lnd` to be built with **all of its subservers** and requires running at least `v0.11.1`. Download the latest [official release binary](https://github.com/lightningnetwork/lnd/releases/latest) or build `lnd` from source by following the [installation instructions](https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md). If you choose to build `lnd` from source, use the following command to enable all the relevant subservers:
* **Bootstrapping new services to Lightning**: Any new service launched on
the Lightning Network will likely need to figure out how to obtain inbound
channels so they can accept payments. For this Pool provides an elegant
solution in that a merchant can set up a series of "introduction points"
negotiated via the market place. The merchant can pay a small percentage of
the total amount of liquidity allocated towards it, and also ensure that
the funds will be committed for a set period of time.
```
make install tags="signrpc walletrpc chainrpc invoicesrpc"
```
* **Allowing users to instantly receive with a wallet**: A common UX
challenge that wallets face concerns ensuring a user can receive funds as
soon as they set up a wallet. Some wallet providers have chosen to open new
inbound channels to users themselves. This gives users the inbound
bandwidth they need to receive, but can come at a high capital cost to the
wallet provider as they need to commit funds with a 1:1 ratio. The
Lightning Pool allows them to achieve some leverage in a sense, as they can
pay only a percentage of the funds to be allocated to a new user. As an
eaxmple, they can pay 1000 satohis to have 1 million satoshis be alloacted
to a user.
## Usage
Read our [getting started guide](#tk) to learn more about how to use Pool.
For more detailed information, please check out [docs folder](docs/).
## Troubleshooting
[Join us on Slack](https://lightning.engineering/slack.html) and we'd be happy to help in any way we can. In the meantime please see our [FAQs](#tk).
# Installation
## Build from source
If you’d prefer to compile from source code, you’ll need at least `go 1.14` and `make`.
Please follow the
[installation instructions in the docs folder](docs/install.md).
Run the following commands to download the code, compile and install Pool:
```shell script
git clone https://github.com/lightninglabs/pool
cd pool
make install
```
This will install the binaries into your `$GOPATH/bin` directory.
## Compatibility
Lightning Pool requires `lnd` version `0.11.1-beta` or higher