Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Good morning group, My friend came to similar (almost the same) conclusions over a year ago, and I were working on implementation of this. I had first working prototype based on clightning (but not trustless), but at that time there were so many troubles with c-lightning, co I decided to make this solution based on LND. Unfortunately, I have other issues with LND also. There are some API method missing in LND and c-lightning also. This is the reason, I'm seriously tired doing this. I think, that was mistake to start working on that without more talks with you and community. Tomorrow, we scheduled to talk if it make sense to continue. A lot of options are possible. If you, agree, it would be valuable to make such thing, I can work on it as full time job (my friend is wiling to pay for that). I prefer to write it in Java rather and also need your support especially in terms of lack of some API methods. Please let me know, if we can build cross-implementation group to work on such thing and if you are willing to help. Best Regards, Cezary Dziemian pon., 12 lis 2018 o 11:05 ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> napisał(a): > Good morning lisa, > > > can simply close the channel. So if I'm charging for liquidity, I'd >> actually >> > want to charge for the amount (in mSAT/BTC) times time. >> >> So perhaps you could make a market here by establishing a channel saying >> that >> >> "I'll pay 32 msat per 500 satoshi per hour for the first 3 days" >> >> When you open the channel with 500,000 satoshi donated by the other guy, >> you're then obliged to transfer 32 satoshi every hour to the other guy >> for three days (so a total of 14c or so). >> >> If the channel fails beforehand, they don't get paid; if you stop >> paying you can still theoretically do a mutual close. >> > > I think that this can also be gamed by a second, cooperating node that > sends payments through the channel to meet the rate and capture the fees > for the first. You can make this less likely by charging higher > transmission fees that make such an attack infeasible, and it's less > 'damaging' than an immediate close in that there's still open capacity > available for some time, at least until the 'bogus' payments have drained > the capacity that you solicited in the first place. > > > I believe not? > I do not see any terms in the contract regarding payments through the > channel other than the "liveness" payment. > So regardless of activity (or lack of activity) in the channel, the above > payments should be made. > If the taker misses a payment, the maker closes the channel outright, > freeing itself from the obligation. > If the maker refuses to route, it loses out on potential routing fees. > Any activity through it do not seem to matter. > > This mechanism may actually be superior to the CLTV-encumberance I and > Rene proposed. > > Regards, > ZmnSCPxj > > > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Good morning lisa, >>> can simply close the channel. So if I'm charging for liquidity, I'd actually >>> want to charge for the amount (in mSAT/BTC) times time. >> >> So perhaps you could make a market here by establishing a channel saying >> that >> >> "I'll pay 32 msat per 500 satoshi per hour for the first 3 days" >> >> When you open the channel with 500,000 satoshi donated by the other guy, >> you're then obliged to transfer 32 satoshi every hour to the other guy >> for three days (so a total of 14c or so). >> >> If the channel fails beforehand, they don't get paid; if you stop >> paying you can still theoretically do a mutual close. > > I think that this can also be gamed by a second, cooperating node that sends > payments through the channel to meet the rate and capture the fees for the > first. You can make this less likely by charging higher transmission fees > that make such an attack infeasible, and it's less 'damaging' than an > immediate close in that there's still open capacity available for some time, > at least until the 'bogus' payments have drained the capacity that you > solicited in the first place. I believe not? I do not see any terms in the contract regarding payments through the channel other than the "liveness" payment. So regardless of activity (or lack of activity) in the channel, the above payments should be made. If the taker misses a payment, the maker closes the channel outright, freeing itself from the obligation. If the maker refuses to route, it loses out on potential routing fees. Any activity through it do not seem to matter. This mechanism may actually be superior to the CLTV-encumberance I and Rene proposed. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
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 va
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
On Wed, Nov 7, 2018 at 11:02 PM Olaoluwa Osuntokun wrote: > > A node, via their node_announcement, > > Most implementations today will ignore node announcements from nodes that > don't have any channels, in order to maintain the smallest routing set > possible (no zombies, etc). It seems for this to work, we would need to > undo > this at a global scale to ensure these announcements propagate? > Right on. I'm not too worried about this tbh; a new node on the network could easily fix this by taking liquidity from another node that's already offering it, to create a few balanced channels to itself. This would a) put it on the map and b) make the liquidity that it's looking to offer more valuable, as the other channels it's opened make it more likely to be routed through. > > Aside from the incentives for leaches to arise that accept the fee then > insta close (they just drain the network and then no one uses this), I > think > this is a dope idea in general! In the past, I've mulled over similar > constructions under a general umbrella of "Channel Liquidity Markets" > (CLM), > though via extra-protocol negotiation. > > -- Laolu > > > On Wed, Nov 7, 2018 at 2:38 PM lisa neigut wrote: > >> Problem >> >> Currently it’s difficult to reliably source inbound capacity for your >> node. This is incredibly problematic for vendors and nodes hoping to setup >> shop as a route facilitator. Most solutions at the moment require an >> element of out of band negotiation in order to find other nodes that can >> help with your capacity needs. >> >> While splicing and dual funding mechanisms will give some relief by >> allowing for the initial negotiation to give the other node an opportunity >> to put funds in either at channel open or after the fact, the problem of >> finding channel liquidity is still left as an offline problem. >> >> Proposal >> = >> To solve the liquidity discovery problem, I'd like to propose allowing >> nodes to advertise initial liquidity matching. The goal of this proposal >> would be to allow nodes to independently source inbound capacity from a >> 'market' of advertised liquidity rates, as set by other nodes. >> >> A node, via their node_announcement, can advertise that they will match >> liquidity and a fee rate that they will provide to any incoming >> open_channel request that indicates requests it. >> >> `node_announcement`: >> new feature flag: option_liquidity_provider >> data: >> [4 liquidity_fee_proportional_millionths] (option_liquidity_provider) >> fee charged per satoshi of liquidity added at channel open >> [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged >> for providing liquidity at channel open >> >> `open_channel`: >> new feature flag (channel_flags): option_liquidity_buy [2nd least >> significant bit] >> push_msat: set to fee payment for requested liquidity >> [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding >> requested at channel open >> >> `accept_channel`: >> tbd. hinges on a dual funding proposal for how second node would send >> information about their funding input. >> >> If a node cannot provide the liquidity requested in `open_channel`, it >> must return an error. >> If the amount listed in `push_msat` does not cover the amount of >> liquidity provided, the liquidity provider node must return an error. >> >> Errata >> == >> It's an open question as to whether or not a liquidity advertising node >> should also include a maximum amount of liquidity that they will >> match/provide. As currently proposed, the only way to discover if a node >> can meet your liquidity requirement is by sending an open channel request. >> >> This proposal depends on dual funding being possible. >> >> 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. >> >> 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 >> > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
On Wed, Nov 7, 2018 at 10:17 PM Anthony Towns wrote: > On Wed, Nov 07, 2018 at 06:40:13PM -0800, Jim Posen wrote: > > can simply close the channel. So if I'm charging for liquidity, I'd > actually > > want to charge for the amount (in mSAT/BTC) times time. > > So perhaps you could make a market here by establishing a channel saying > that > > "I'll pay 32 msat per 500 satoshi per hour for the first 3 days" > > When you open the channel with 500,000 satoshi donated by the other guy, > you're then obliged to transfer 32 satoshi every hour to the other guy > for three days (so a total of 14c or so). > > If the channel fails beforehand, they don't get paid; if you stop > paying you can still theoretically do a mutual close. > I think that this can also be gamed by a second, cooperating node that sends payments through the channel to meet the rate and capture the fees for the first. You can make this less likely by charging higher transmission fees that make such an attack infeasible, and it's less 'damaging' than an immediate close in that there's still open capacity available for some time, at least until the 'bogus' payments have drained the capacity that you solicited in the first place. > Maybe a complicated addition to the protocol though? > > Cheers, > aj > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Hello ZmnSCPxj, You bring up some good points. On Wed, Nov 7, 2018, 21:19 ZmnSCPxj 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. > > 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. > Rega
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Was approaching more so from the angle of a node new node with no existing channels seeking to bootstrap connections to the network. -- Sent from my Spaceship On Fri, Nov 9, 2018, 9:10 AM Anthony Towns On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote: > > > A node, via their node_announcement, > > Most implementations today will ignore node announcements from nodes that > > don't have any channels, in order to maintain the smallest routing set > > possible (no zombies, etc). It seems for this to work, we would need to > undo > > this at a global scale to ensure these announcements propagate? > > Having incoming capacity from a random node with no other channels doesn't > seem useful though? (It's not useful for nodes that don't have incoming > capacity of their own, either) > > Cheers, > aj > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
On Thu, Nov 08, 2018 at 05:32:01PM +1030, Olaoluwa Osuntokun wrote: > > A node, via their node_announcement, > Most implementations today will ignore node announcements from nodes that > don't have any channels, in order to maintain the smallest routing set > possible (no zombies, etc). It seems for this to work, we would need to undo > this at a global scale to ensure these announcements propagate? Having incoming capacity from a random node with no other channels doesn't seem useful though? (It's not useful for nodes that don't have incoming capacity of their own, either) Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
> A node, via their node_announcement, Most implementations today will ignore node announcements from nodes that don't have any channels, in order to maintain the smallest routing set possible (no zombies, etc). It seems for this to work, we would need to undo this at a global scale to ensure these announcements propagate? Aside from the incentives for leaches to arise that accept the fee then insta close (they just drain the network and then no one uses this), I think this is a dope idea in general! In the past, I've mulled over similar constructions under a general umbrella of "Channel Liquidity Markets" (CLM), though via extra-protocol negotiation. -- Laolu On Wed, Nov 7, 2018 at 2:38 PM lisa neigut wrote: > Problem > > Currently it’s difficult to reliably source inbound capacity for your > node. This is incredibly problematic for vendors and nodes hoping to setup > shop as a route facilitator. Most solutions at the moment require an > element of out of band negotiation in order to find other nodes that can > help with your capacity needs. > > While splicing and dual funding mechanisms will give some relief by > allowing for the initial negotiation to give the other node an opportunity > to put funds in either at channel open or after the fact, the problem of > finding channel liquidity is still left as an offline problem. > > Proposal > = > To solve the liquidity discovery problem, I'd like to propose allowing > nodes to advertise initial liquidity matching. The goal of this proposal > would be to allow nodes to independently source inbound capacity from a > 'market' of advertised liquidity rates, as set by other nodes. > > A node, via their node_announcement, can advertise that they will match > liquidity and a fee rate that they will provide to any incoming > open_channel request that indicates requests it. > > `node_announcement`: > new feature flag: option_liquidity_provider > data: > [4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee > charged per satoshi of liquidity added at channel open > [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged > for providing liquidity at channel open > > `open_channel`: > new feature flag (channel_flags): option_liquidity_buy [2nd least > significant bit] > push_msat: set to fee payment for requested liquidity > [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding > requested at channel open > > `accept_channel`: > tbd. hinges on a dual funding proposal for how second node would send > information about their funding input. > > If a node cannot provide the liquidity requested in `open_channel`, it > must return an error. > If the amount listed in `push_msat` does not cover the amount of liquidity > provided, the liquidity provider node must return an error. > > Errata > == > It's an open question as to whether or not a liquidity advertising node > should also include a maximum amount of liquidity that they will > match/provide. As currently proposed, the only way to discover if a node > can meet your liquidity requirement is by sending an open channel request. > > This proposal depends on dual funding being possible. > > 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. > > 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 > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
On Wed, Nov 07, 2018 at 06:40:13PM -0800, Jim Posen wrote: > can simply close the channel. So if I'm charging for liquidity, I'd actually > want to charge for the amount (in mSAT/BTC) times time. So perhaps you could make a market here by establishing a channel saying that "I'll pay 32 msat per 500 satoshi per hour for the first 3 days" When you open the channel with 500,000 satoshi donated by the other guy, you're then obliged to transfer 32 satoshi every hour to the other guy for three days (so a total of 14c or so). If the channel fails beforehand, they don't get paid; if you stop paying you can still theoretically do a mutual close. Maybe a complicated addition to the protocol though? Cheers, aj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Thanks for proposing this! I think it is absolutely one of the biggest onboarding/usability challenges for many use cases. My first thought is that like ZmnSCPxj mentioned, the person offering liquidity can simply close the channel. So if I'm charging for liquidity, I'd actually want to charge for the amount (in mSAT/BTC) times time. So like 1 mSAT per satoshi of bandwidth per hour or something like that. I don't think there's a perfect way of enforcing this at the protocol layer, but maybe you could lock up the fees in channel reserve which decreases over time and gets donated to miners on an early close? Instead of a flat payment for liquidity, I've considered in the past a model where you pre-pay on fees. So if I'm a large merchant and I expect to be receiving lots of volume in payments, it is totally rational for you to put up liquidity opening a channel to me because you will earn fees on payments routed to me through that channel. So what I could do to convince you is to say, "I expect if you open a 1 BTC channel to me, you will earn at least 10 mSAT per minute in routing fees. And if you don't I'll cover the difference." So every minute, I'll pay you 10 mSAT up front, then for all HTLCs that come through the channel to me up to that limit, you'll forward the fees onto me as reimbursement. I don't think this protocol is any less vulnerable to attacks, but perhaps aligns incentives better? My other concern with this sort of proposal is that it makes it easier to perform HTLC withholding/loop attacks, which are executed by the receiving end of a circuit. Currently on the network, there's a nice built-in protection that it's not obvious how to convince victim to open a channel to you. This is probably something that should get dealt with separately, but part of me doubts that it'll be possible to create a liquidity market without factoring in reputation. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
Good morning Lisa, On Wednesday, November 7, 2018 2:17 PM, ZmnSCPxj via Lightning-dev 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
Re: [Lightning-dev] Proposal for Advertising Channel Liquidity
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. 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
[Lightning-dev] Proposal for Advertising Channel Liquidity
Problem Currently it’s difficult to reliably source inbound capacity for your node. This is incredibly problematic for vendors and nodes hoping to setup shop as a route facilitator. Most solutions at the moment require an element of out of band negotiation in order to find other nodes that can help with your capacity needs. While splicing and dual funding mechanisms will give some relief by allowing for the initial negotiation to give the other node an opportunity to put funds in either at channel open or after the fact, the problem of finding channel liquidity is still left as an offline problem. Proposal = To solve the liquidity discovery problem, I'd like to propose allowing nodes to advertise initial liquidity matching. The goal of this proposal would be to allow nodes to independently source inbound capacity from a 'market' of advertised liquidity rates, as set by other nodes. A node, via their node_announcement, can advertise that they will match liquidity and a fee rate that they will provide to any incoming open_channel request that indicates requests it. `node_announcement`: new feature flag: option_liquidity_provider data: [4 liquidity_fee_proportional_millionths] (option_liquidity_provider) fee charged per satoshi of liquidity added at channel open [4 liquidity_fee_base_msat] (option_liquidity_provider) base fee charged for providing liquidity at channel open `open_channel`: new feature flag (channel_flags): option_liquidity_buy [2nd least significant bit] push_msat: set to fee payment for requested liquidity [8 liquidity_msat_request]: (option_liquidity_buy) amount of dual funding requested at channel open `accept_channel`: tbd. hinges on a dual funding proposal for how second node would send information about their funding input. If a node cannot provide the liquidity requested in `open_channel`, it must return an error. If the amount listed in `push_msat` does not cover the amount of liquidity provided, the liquidity provider node must return an error. Errata == It's an open question as to whether or not a liquidity advertising node should also include a maximum amount of liquidity that they will match/provide. As currently proposed, the only way to discover if a node can meet your liquidity requirement is by sending an open channel request. This proposal depends on dual funding being possible. 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. 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
