<div dir="ltr"><div dir="auto"><div>Hello ZmnSCPxj,<div dir="auto"><br></div><div dir="auto">You bring up some good points.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Nov 7, 2018, 21:19 ZmnSCPxj &lt;<a href="mailto:ZmnSCPxj@protonmail.com" rel="noreferrer" target="_blank">ZmnSCPxj@protonmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Good morning Lisa,<br></div><div><br></div><div>On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev &lt;<a href="mailto:lightning-dev@lists.linuxfoundation.org" rel="noreferrer noreferrer" target="_blank">lightning-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><div> <br></div><blockquote type="cite" class="m_-6104667780749522259m_-5972252173303871225m_-5683501758899945372protonmail_quote"><div>Good morning Lisa,<br></div><div><br></div><div>&gt;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 <br></div><div>&gt;allowed seems unnecessary.<br></div><div><br></div><div>My initial thought is that it would be dangerous to allow the initiator of the request to request for arbitrary capacity.<br></div><div><br></div><div>For instance, suppose that, via my legion of captive zombie computers (which are entirely fictional and exist only in this example, since I am an ordinary human person) I have analyzed the blockchain and discovered that you have 1.0 BTC you have reserved for liquidity requests under this protocol.  I could then have one of those computers spin up a temporary Lightning Node, request for 1.0BTC incoming capacity with only some nominal fee, then shut down the node permanently, leaving your funds in an unuseable channel, unable to earn routing fees or such.  This loses you potential earnings from this 1.0 BTC.<br></div><div><br></div><div>If instead I were obligated to have at least greater capacity tied into this channel, then I would also be tying up at least 1.0 BTC into this channel as well, making this attack more expensive for me, as it also loses me any potential earnings from the 1.0 BTC of my own that I have locked up.<br></div></blockquote><div></div></blockquote></div></div><div dir="auto">As you point out below, at the very least a liquidity providing node would get paid. Another thing worth considering is that the spec, as written, is merely a mechanism for advertising and receiving offers for dual funding. There are no rules about what offers you, as a liquidity advertising node, have to accept. A node operator has the flexibility to reject any offer above or below their stated fee rate, or if they don&#39;t relish the idea of funding a badly skewed channel. If you&#39;re worried about capital being tied up unnecessarily, you can reject offers without a sizeable input of their own.</div><div dir="auto"><br></div><div dir="auto">There are, however, scenarios where requests for badly skewed channels make sense. Imagine that you&#39;re a large vendor, such as Amazon. You&#39;re likely not going to ever need much outbound capacity, but you will be perpetually in the market for more inbound capacity.</div><div dir="auto"><br></div><div dir="auto">In fact, as a liquidity provider, I think that you&#39;ll probably be delighted to have an open channel with Amazon, as there&#39;s a good chance that channel will be highly utilized, which means more fee traffic for you, and a high probability that they&#39;ll be requesting more liquidity from you in the future, as the existing channel gets unbalanced.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>A counterpoint to this argument, however, is that if the fee for the liquidity is high enough, then it does not matter to you whether I use the 1.0 BTC or not: you have already been paid for it.<br></div><div><br></div><div>This however brings up the other potential attack:<br></div><div><br></div><div>1.  I advertise that I have 1.0 BTC available for liquidity requests.<br></div><div>2.  You answer this advertisement, and pay me a good fee for this 1.0 BTC being locked into a channel.<br></div><div>3.  After the channel is opened, I immediately close it, having earned the fee for liquidity, without in fact delivering that liquidity.<br></div><div><br></div><div>Perhaps we can modify channel commitment transactions for channels opened via liquidity requests, so that they have an `nSequence` that prevents them from being claimed for a month or so.  What do you think?<br></div><div></div></blockquote></div></div><div dir="auto"><br></div><div>At what point should a liquidity providing node (maker) be able to close the channel? Immediately is not very beneficial to either of you -- you both tied up your money for the time required to push through bitcoin txns through, plus you lose closing + opening fees. Stipulating a length of time isn&#39;t necessarily beneficial either -- if you&#39;ve connected to a high volume payment channel, the liquidity you&#39;ve provided will be used up rather quickly, rendering the channel itself pretty useless.</div><div><br></div><div>I think there&#39;s definitely some clever things we can do to provide stronger guarantees around a &#39;minimum service offer&#39;, and they can be investigated independently of the advertisement mechanism that I&#39;ve proposed here.  Independent of what guarantees the protocol offers, there&#39;s a bunch of strategies that individual nodes can additionally take to limit potential losses: starting with by soliciting small liquidity offers, shopping around for the best rates, blacklisting IP addresses/node id&#39;s of unreliable nodes, using a ratcheting mechanism (start with a small liquidity request that you close/rebalance upward as the incoming capacity is drained).</div><div><br></div><div>Considering incentives, keeping a high-traffic channel open should be worth more in routing fees than the liquidity that you&#39;ve provided. If the liquidity market acts rationally, it should price itself to reflect this reality and the risk of being laolu&#39;d should remain fairly insignificant.</div><div><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div><blockquote type="cite" class="m_-6104667780749522259m_-5972252173303871225m_-5683501758899945372protonmail_quote"><div>To my mind, this may become important.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><blockquote type="cite" class="m_-6104667780749522259m_-5972252173303871225m_-5683501758899945372protonmail_quote"><div dir="ltr"><div dir="auto"><br></div><div>Conclusion<br></div><div>=======================================<br></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. <br></div><div dir="auto"><br></div><div dir="auto"><br></div><div>Credit to Casey Rodamor for the initial idea.<br></div></div></blockquote><div><br></div></blockquote><div><br></div></blockquote></div></div></div>
</div>