ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-07 📝 Original message: Good morning Lisa, On ...

📅 Original date posted:2018-11-07
📝 Original message:
Good morning Lisa,

On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:

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

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.

This however brings up the other potential attack:

1. I advertise that I have 1.0 BTC available for liquidity requests.
2. You answer this advertisement, and pay me a good fee for this 1.0 BTC being locked into a channel.
3. After the channel is opened, I immediately close it, having earned the fee for liquidity, without in fact delivering that liquidity.

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?

Regards,
ZmnSCPxj

> 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/6ff47164/attachment.html>;