On Wed, Nov 7, 2018 at 11:02 PM Olaoluwa Osuntokun <laol...@gmail.com> wrote:
> > 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? > Right on. I'm not too worried about this tbh; a new node on the network could easily fix this by taking liquidity from another node that's already offering it, to create a few balanced channels to itself. This would a) put it on the map and b) make the liquidity that it's looking to offer more valuable, as the other channels it's opened make it more likely to be routed through. > > 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 <nifty...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
