Good morning Lisa,
On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev
<lightning-dev@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.
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
