lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-07 📝 Original message: Problem ...
📅 Original date posted:2018-11-07
📝 Original message:
Problem
====================================
Currently it’s difficult to reliably source inbound capacity for your node.
This is incredibly problematic for vendors and nodes hoping to setup shop
as a route facilitator. Most solutions at the moment require an element of
out of band negotiation in order to find other nodes that can help with
your capacity needs.
While splicing and dual funding mechanisms will give some relief by
allowing for the initial negotiation to give the other node an opportunity
to put funds in either at channel open or after the fact, the problem of
finding channel liquidity is still left as an offline problem.
Proposal
=====================================
To solve the liquidity discovery problem, I'd like to propose allowing
nodes to advertise initial liquidity matching. The goal of this proposal
would be to allow nodes to independently source inbound capacity from a
'market' of advertised liquidity rates, as set by other nodes.
A node, via their node_announcement, can advertise that they will match
liquidity and a fee rate that they will provide to any incoming
open_channel request that indicates requests it.
`node_announcement`:
new feature flag: option_liquidity_provider
data:
[4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee
charged per satoshi of liquidity added at channel open
[4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged
for providing liquidity at channel open
`open_channel`:
new feature flag (channel_flags): option_liquidity_buy [2nd least
significant bit]
push_msat: set to fee payment for requested liquidity
[8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
requested at channel open
`accept_channel`:
tbd. hinges on a dual funding proposal for how second node would send
information about their funding input.
If a node cannot provide the liquidity requested in `open_channel`, it must
return an error.
If the amount listed in `push_msat` does not cover the amount of liquidity
provided, the liquidity provider node must return an error.
Errata
======================================
It's an open question as to whether or not a liquidity advertising node
should also include a maximum amount of liquidity that they will
match/provide. As currently proposed, the only way to discover if a node
can meet your liquidity requirement is by sending an open channel request.
This proposal depends on dual funding being possible.
Should a node be able to request more liquidity than they put into the
channel on their half? In the case of a vendor who wants inbound capacity,
capping the liquidity request allowed seems unnecessary.
Conclusion
=======================================
Allowing nodes to advertise liquidity paves the way for automated node
re-balancing. Advertised liquidity creates a market of inbound capacity
that any node can take advantage of, reducing the amount of out-of-band
negotiation needed to get the inbound capacity that you need.
Credit to Casey Rodamor for the initial idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/07fce24b/attachment.html>;
📝 Original message:
Problem
====================================
Currently it’s difficult to reliably source inbound capacity for your node.
This is incredibly problematic for vendors and nodes hoping to setup shop
as a route facilitator. Most solutions at the moment require an element of
out of band negotiation in order to find other nodes that can help with
your capacity needs.
While splicing and dual funding mechanisms will give some relief by
allowing for the initial negotiation to give the other node an opportunity
to put funds in either at channel open or after the fact, the problem of
finding channel liquidity is still left as an offline problem.
Proposal
=====================================
To solve the liquidity discovery problem, I'd like to propose allowing
nodes to advertise initial liquidity matching. The goal of this proposal
would be to allow nodes to independently source inbound capacity from a
'market' of advertised liquidity rates, as set by other nodes.
A node, via their node_announcement, can advertise that they will match
liquidity and a fee rate that they will provide to any incoming
open_channel request that indicates requests it.
`node_announcement`:
new feature flag: option_liquidity_provider
data:
[4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee
charged per satoshi of liquidity added at channel open
[4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged
for providing liquidity at channel open
`open_channel`:
new feature flag (channel_flags): option_liquidity_buy [2nd least
significant bit]
push_msat: set to fee payment for requested liquidity
[8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding
requested at channel open
`accept_channel`:
tbd. hinges on a dual funding proposal for how second node would send
information about their funding input.
If a node cannot provide the liquidity requested in `open_channel`, it must
return an error.
If the amount listed in `push_msat` does not cover the amount of liquidity
provided, the liquidity provider node must return an error.
Errata
======================================
It's an open question as to whether or not a liquidity advertising node
should also include a maximum amount of liquidity that they will
match/provide. As currently proposed, the only way to discover if a node
can meet your liquidity requirement is by sending an open channel request.
This proposal depends on dual funding being possible.
Should a node be able to request more liquidity than they put into the
channel on their half? In the case of a vendor who wants inbound capacity,
capping the liquidity request allowed seems unnecessary.
Conclusion
=======================================
Allowing nodes to advertise liquidity paves the way for automated node
re-balancing. Advertised liquidity creates a market of inbound capacity
that any node can take advantage of, reducing the amount of out-of-band
negotiation needed to get the inbound capacity that you need.
Credit to Casey Rodamor for the initial idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181106/07fce24b/attachment.html>;