[Lightning-dev] Proposal for Advertising Channel Liquidity

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Nov 7 06:17:17 UTC 2018


Good morning Lisa,

>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.

My initial thought is that it would be dangerous to allow the initiator of the request to request for arbitrary capacity.

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.

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.

To my mind, this may become important.

Regards,
ZmnSCPxj

> 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/20181107/502cb6d2/attachment.html>


More information about the Lightning-dev mailing list