lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-12 📝 Original message: Hello ZmnSCPxj, You bring ...
📅 Original date posted:2018-11-12
📝 Original message:
Hello ZmnSCPxj,
You bring up some good points.
On Wed, Nov 7, 2018, 21:19 ZmnSCPxj <ZmnSCPxj at protonmail.com wrote:
> 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.
>
> 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.
> 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.
I think there's definitely some clever things we can do to provide stronger
guarantees around a 'minimum service offer', and they can be investigated
independently of the advertisement mechanism that I've proposed here.
Independent of what guarantees the protocol offers, there's a bunch of
strategies that individual nodes can additionally take to limit potential
losses: starting with by soliciting small liquidity offers, shopping around
for the best rates, blacklisting IP addresses/node id's of unreliable
nodes, using a ratcheting mechanism (start with a small liquidity request
that you close/rebalance upward as the incoming capacity is drained).
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.
> 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/20181112/45e41973/attachment-0001.html>;
📝 Original message:
Hello ZmnSCPxj,
You bring up some good points.
On Wed, Nov 7, 2018, 21:19 ZmnSCPxj <ZmnSCPxj at protonmail.com wrote:
> 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.
>
> 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.
> 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.
I think there's definitely some clever things we can do to provide stronger
guarantees around a 'minimum service offer', and they can be investigated
independently of the advertisement mechanism that I've proposed here.
Independent of what guarantees the protocol offers, there's a bunch of
strategies that individual nodes can additionally take to limit potential
losses: starting with by soliciting small liquidity offers, shopping around
for the best rates, blacklisting IP addresses/node id's of unreliable
nodes, using a ratcheting mechanism (start with a small liquidity request
that you close/rebalance upward as the incoming capacity is drained).
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.
> 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/20181112/45e41973/attachment-0001.html>;