<div dir="ltr"><div><div><div>&gt; A node, via their node_announcement,</div><div><br></div><div>Most implementations today will ignore node announcements from nodes that</div><div>don&#39;t have any channels, in order to maintain the smallest routing set</div><div>possible (no zombies, etc). It seems for this to work, we would need to undo</div><div>this at a global scale to ensure these announcements propagate?</div><div><br></div><div>Aside from the incentives for leaches to arise that accept the fee then</div><div>insta close (they just drain the network and then no one uses this), I think</div><div>this is a dope idea in general! In the past, I&#39;ve mulled over similar</div><div>constructions under a general umbrella of &quot;Channel Liquidity Markets&quot; (CLM),</div><div>though via extra-protocol negotiation.</div><div><br></div><div>-- Laolu</div></div></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018 at 2:38 PM lisa neigut &lt;<a href="mailto:niftynei@gmail.com">niftynei@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="auto">Problem<br></div><div dir="auto">====================================</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div dir="auto">Proposal</div><div dir="auto">=====================================</div><div>To solve the liquidity discovery problem, I&#39;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 &#39;market&#39; of advertised liquidity rates, as set by other nodes.</div><div><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div>`node_announcement`:</div><div dir="auto">new feature flag: option_liquidity_provider<br>data:</div><div dir="auto"> [4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee charged per satoshi of liquidity added at channel open </div><div dir="auto"> [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged for providing liquidity at channel open</div><div dir="auto"><br></div><div dir="auto">`open_channel`:</div><div dir="auto">new feature flag (channel_flags): option_liquidity_buy [2nd least significant bit]</div><div dir="auto">push_msat: set to fee payment for requested liquidity</div><div dir="auto">[8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding requested at channel open</div><div dir="auto"><br></div><div dir="auto">`accept_channel`:</div><div>tbd. hinges on a dual funding proposal for how second node would send information about their funding input.</div><div dir="auto"><br></div><div dir="auto"><div dir="auto">If a node cannot provide the liquidity requested in `open_channel`, it must return an error.</div><div>If the amount listed in `push_msat` does not cover the amount of liquidity provided, the liquidity provider node must return an error.</div><div><br></div><div>Errata</div><div>======================================</div><div>It&#39;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.</div><div><br></div><div>This proposal depends on dual funding being possible.</div><div><br></div><div>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.</div></div><div dir="auto"><br></div><div>Conclusion</div><div>=======================================</div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto"><br></div><div>Credit to Casey Rodamor for the initial idea.</div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div>