Good morning lisa,
> 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't relish the idea of funding a
> badly skewed channel. If you're worried about capital being tied up
> unnecessarily, you can reject offers without a sizeable input of their own.
>
> There are, however, scenarios where requests for badly skewed channels make
> sense. Imagine that you're a large vendor, such as Amazon. You're likely not
> going to ever need much outbound capacity, but you will be perpetually in the
> market for more inbound capacity.
>
> In fact, as a liquidity provider, I think that you'll probably be delighted
> to have an open channel with Amazon, as there's a good chance that channel
> will be highly utilized, which means more fee traffic for you, and a high
> probability that they'll be requesting more liquidity from you in the future,
> as the existing channel gets unbalanced.
This is correct and I have since changed my mind. A true market would only
impose that the market taker actually pay for the service.
>> 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?
>
> 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't
> necessarily beneficial either -- if you've connected to a high volume payment
> channel, the liquidity you've provided will be used up rather quickly,
> rendering the channel itself pretty useless.
Please see the other thread regarding the proposed mechanism that I and Rene
generated.
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001555.html
In this mechanism, only the liquidity provider is encumbered by the agreed-upon
channel lifetime.
In particular, section "Reduction of Licky Obligation", I point out that if the
merchant has received funds, then the money of the liquidity provider that is
encumbered by this lifetime is reduced.
That is, the channel balance on the side of the liquidity provider is reduced
due to the merchant receiving funds.
I pointed out also, that this should be perfectly fine for the merchant, since
the point of it is to receive payments, and this change in channel balance
implies that the merchant has received payments.
Once the channel has saturated to the minimum receivable amount, only the
channel reserve of the liquidity provider remains encumbered with the channel
lifetime.
It would be quite fine for the liquidity provider to close the channel, as the
locked funds are now only quite small.
> Considering incentives, keeping a high-traffic channel open should be worth
> more in routing fees than the liquidity that you've provided. If the
> liquidity market acts rationally, it should price itself to reflect this
> reality and the risk of being laolu'd should remain fairly insignificant.
There are two sides of the laolu attack (I actually came up with both sides of
the attack and wrote it on-list before the summit, but I suppose "being
laolued" is easier to say than "being ZmnSCPxjed").
1. If the liquidity market values the routing fees more than the liquidity
fees, such that liquidity fees are small, then I can attack this market by
requesting capacity, paying a tiny liquidity fee, then shutting off my node and
letting the liquidity provider close the channel after it realizes it will
never earn routing fees from me.
2. If the liquidity market values the liquidity fees more than the routing
fees, then I can attack this market by offering capacity, then closing the
channel and re-offering my freed capacity to another customer.
To prevent one of the above attacks should be sufficient, since this will lead
the market to value one class of fees more than the other, biased towards the
attack that has been shut down.
It is impossible to prevent the first attack, since it is impossible to
distinguish between a node that was hit by lightning and destroyed utterly, and
a node that is simply turned off to attack the liquidity market.
Hence, the proposal to impose a minimum channel lifetime, in order to prevent
the second attack. We expect the liquidity market to then settle to the
protected side, i.e. liquidity providers will value liquidity fees higher than
routing fees.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
