Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-08 📝 Original message: > A node, via their ...
📅 Original date posted:2018-11-08
📝 Original message:
> A node, via their node_announcement,
Most implementations today will ignore node announcements from nodes that
don't have any channels, in order to maintain the smallest routing set
possible (no zombies, etc). It seems for this to work, we would need to undo
this at a global scale to ensure these announcements propagate?
Aside from the incentives for leaches to arise that accept the fee then
insta close (they just drain the network and then no one uses this), I think
this is a dope idea in general! In the past, I've mulled over similar
constructions under a general umbrella of "Channel Liquidity Markets" (CLM),
though via extra-protocol negotiation.
-- Laolu
On Wed, Nov 7, 2018 at 2:38 PM lisa neigut <niftynei at gmail.com> wrote:
> 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.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181108/fedb1500/attachment.html>;
📝 Original message:
> A node, via their node_announcement,
Most implementations today will ignore node announcements from nodes that
don't have any channels, in order to maintain the smallest routing set
possible (no zombies, etc). It seems for this to work, we would need to undo
this at a global scale to ensure these announcements propagate?
Aside from the incentives for leaches to arise that accept the fee then
insta close (they just drain the network and then no one uses this), I think
this is a dope idea in general! In the past, I've mulled over similar
constructions under a general umbrella of "Channel Liquidity Markets" (CLM),
though via extra-protocol negotiation.
-- Laolu
On Wed, Nov 7, 2018 at 2:38 PM lisa neigut <niftynei at gmail.com> wrote:
> 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.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181108/fedb1500/attachment.html>;