ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-12 📝 Original message: Good morning lisa, > As ...
📅 Original date posted:2018-11-12
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/1c91e3eb/attachment-0001.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/1c91e3eb/attachment-0001.html>;