Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
> bLIPs have a slightly different process than BIPs, as well as a different set > of editors/maintainers (more widely distributed). As we saw with the Speedy > Trial saga (fingers crossed), the sole (?) maintainer of the BIP process was > able to effectively steelman the progression of an author document, with no > sound technical objection (they had a competing proposal that could've been > a distinct document). bLIPs sidestep shenanigans like this by having the > primary maintainer/editors be more widely distributed and closer to the > target domain (LN). That's fair. The BIP repository as a whole lost credibility when the sole maintainer at the time steelmanned progress for no good reason. It was done in bad faith and no steps were taken to remove even the *perception* of impropriety. I hope the maintainers of the bLIP repository can be more impartial. The automatic assignment of proposal numbers is an excellent improvement. It's an idea that the BIP repo should adopt since it removes responsibility and power from the maintainers. > > The other thing bLIPs do is do away with the whole "human picks the number > of documents", and "don't assign your own number, you must wait". Borrowing > from EIPs, the number of a document is simply the number of the PR that > proposes the document. This reduces friction, and eliminates a possible > bikeshedding vector. > > -- Laolu > > > On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces wrote: >> >> BIPs are already the Bazaar style of evolution that simultaneously >> allows flexibility and coordination/interoperability (since anyone can >> create a BIP and they create an environment of discussion). >> >> BOLTs are essentially one big BIP in the sense that they started as a >> place for discussion but are now more rigid. BOLTs must be followed >> strictly to ensure a node is interoperable with the network. And BOLTs >> should be rigid, as rigid as any widely used BIP like 32 for example. >> Even though BOLTs were flexible when being drafted their purpose has >> changed from descriptive to prescriptive. >> Any alternatives, or optional features should be extracted out of >> BOLTs, written as BIPs. The BIP should then reference the BOLT and the >> required flags set, messages sent, or alterations made to signal that >> the BIP's feature is enabled. >> >> A BOLT may at some point organically change to reference a BIP. For >> example if a BIP was drafted as an optional feature but then becomes >> more widespread and then turns out to be crucial for the proper >> operation of the network then a BOLT can be changed to just reference >> the BIP as mandatory. There isn't anything wrong with this. >> >> All of the above would work exactly the same if there was a bLIP >> repository instead. I don't see the value in having both bLIPs and >> BIPs since AFAICT they seem to be functionally equivalent and BIPs are >> not restricted to exclude lightning, and never have been. >> >> I believe the reason this move to BIPs hasn't happened organically is >> because many still perceive the BOLTs available for editing, so >> changes continue to be made. If instead BOLTs were perceived as more >> "consensus critical", not subject to change, and more people were >> strongly encouraged to write specs for new lightning features >> elsewhere (like the BIP repo) then you would see this issue of growing >> BOLTs resolved. >> >> Cheers >> Ariel Lorenzo-Luaces >> >> On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun wrote: >> > >> > > That being said I think all the points that are addressed in Ryan's mail >> > > could very well be formalized into BOLTs but maybe we just need to >> > > rethink >> > > the current process of the BOLTs to make it more accessible for new ideas >> > > to find their way into the BOLTs? >> > >> > I think part of what bLIPs are trying to solve here is promoting more >> > loosely >> > coupled evolution of the network. I think the BOLTs do a good job >> > currently of >> > specifying what _base_ functionality is required for a routing node in a >> > prescriptive manner (you must forward an HTLC like this, etc). However >> > there's >> > a rather large gap in describing functionality that has emerged over time >> > due >> > to progressive evolution, and aren't absolutely necessary, but enhance >> > node/wallet operation. >> > >> > Examples of include things like: path finding heuristics (BOLTs just say >> > you >> > should get from Alice to Bob, but provides no recommendations w.r.t _how_ >> > to do >> > so), fee bumping heuristics, breach retribution handling, channel >> > management, >> > rebalancing, custom records usage (like the podcast index meta-data, >> > messaging, >> > etc), JIT channel opening, hosted channels, randomized channel IDs, fee >> > optimization, initial channel boostrapping, etc. >> > >> > All these examples are effectively optional as they aren't required for >> > base >> > node operation, but they've organically evolved over time as node >> >
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
BOLTs should be BIPs too. Ideally, the authors should be the ones to migrate them, but mirroring is fine - just nobody's taken the time to do it yet. Please stop promoting lies about the BIP repo. I did not "steelman" anything. Adding a third BIP editor more involved with Lightning sounds like a good idea. On Thursday 01 July 2021 20:25:23 Olaoluwa Osuntokun wrote: > > BIPs are already the Bazaar style of evolution that simultaneously > > allows flexibility and coordination/interoperability (since anyone can > > create a > > > BIP and they create an environment of discussion). > > The answer to why not BIPs here applies to BOLTs as well, as bLIPs are > intended to effectively be nested under the BOLT umbrella (same repo, etc). > It's also the case that any document can be mirrored as a BIP, this has > been suggested before, but the BIP editors have decided not to do so. > > bLIPs have a slightly different process than BIPs, as well as a different > set > of editors/maintainers (more widely distributed). As we saw with the Speedy > Trial saga (fingers crossed), the sole (?) maintainer of the BIP process > was able to effectively steelman the progression of an author document, > with no sound technical objection (they had a competing proposal that > could've been a distinct document). bLIPs sidestep shenanigans like this by > having the primary maintainer/editors be more widely distributed and closer > to the target domain (LN). > > The other thing bLIPs do is do away with the whole "human picks the number > of documents", and "don't assign your own number, you must wait". Borrowing > from EIPs, the number of a document is simply the number of the PR that > proposes the document. This reduces friction, and eliminates a possible > bikeshedding vector. > > -- Laolu > > On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces wrote: > > BIPs are already the Bazaar style of evolution that simultaneously > > allows flexibility and coordination/interoperability (since anyone can > > create a BIP and they create an environment of discussion). > > > > BOLTs are essentially one big BIP in the sense that they started as a > > place for discussion but are now more rigid. BOLTs must be followed > > strictly to ensure a node is interoperable with the network. And BOLTs > > should be rigid, as rigid as any widely used BIP like 32 for example. > > Even though BOLTs were flexible when being drafted their purpose has > > changed from descriptive to prescriptive. > > Any alternatives, or optional features should be extracted out of > > BOLTs, written as BIPs. The BIP should then reference the BOLT and the > > required flags set, messages sent, or alterations made to signal that > > the BIP's feature is enabled. > > > > A BOLT may at some point organically change to reference a BIP. For > > example if a BIP was drafted as an optional feature but then becomes > > more widespread and then turns out to be crucial for the proper > > operation of the network then a BOLT can be changed to just reference > > the BIP as mandatory. There isn't anything wrong with this. > > > > All of the above would work exactly the same if there was a bLIP > > repository instead. I don't see the value in having both bLIPs and > > BIPs since AFAICT they seem to be functionally equivalent and BIPs are > > not restricted to exclude lightning, and never have been. > > > > I believe the reason this move to BIPs hasn't happened organically is > > because many still perceive the BOLTs available for editing, so > > changes continue to be made. If instead BOLTs were perceived as more > > "consensus critical", not subject to change, and more people were > > strongly encouraged to write specs for new lightning features > > elsewhere (like the BIP repo) then you would see this issue of growing > > BOLTs resolved. > > > > Cheers > > Ariel Lorenzo-Luaces > > > > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun > > > > wrote: > > > > That being said I think all the points that are addressed in Ryan's > > > > mail > > > > > > could very well be formalized into BOLTs but maybe we just need to > > > > rethink > > > > > > the current process of the BOLTs to make it more accessible for new > > > > ideas > > > > > > to find their way into the BOLTs? > > > > > > I think part of what bLIPs are trying to solve here is promoting more > > > > loosely > > > > > coupled evolution of the network. I think the BOLTs do a good job > > > > currently of > > > > > specifying what _base_ functionality is required for a routing node in > > > a prescriptive manner (you must forward an HTLC like this, etc). > > > However > > > > there's > > > > > a rather large gap in describing functionality that has emerged over > > > > time due > > > > > to progressive evolution, and aren't absolutely necessary, but enhance > > > node/wallet operation. > > > > > > Examples of include things like: path finding heuristics (BOLTs just > > > > say you > > > > > should get from Alice to Bob, but provides no
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
> But they don't address the first point at all, they instead work around > it. To be fair, I don't think we can completely address that first point: > properly reviewing spec proposals takes a lot of effort and accepting > complex changes to the BOLTs shouldn't be done lightly. I think this is a fair characterization that I agree with. I also agree that there isn't really a way to fundamentally address it. The issue of scarce review resources is something just about any large open source project needs to deal with: everyone wants to make a PR, but no one wants to review the PRs of others, unless it scratches some tangential itch they may have. IMO it's also the case that the problem/solution space of LN is so large, that it's hard to expect every developer to review each new proposal that comes in, as they themselves have their own set of priorities (product, businesses, protocol, personal, etc). In the end though, I think when there've been critical items that affect all implementations and/or the existence of the protocol itself, developers typically band together to commit resources to help a proposal move forward. One upcoming example of this will be the "base" taproot channel type (the design space is pretty large in that it even permits a new type of symmetric state revocation-based channel). > it will add fragmentation to the network, it will add maintenance costs > and backwards-compatibility issues Will it actually add any more fragmentation that already exists? Due to all the extensibility we've added in the protocol, it's already possible for any implementation to start to work on their own sub-protocols. This just gives them a new venue to at least _describe_ what they're using. As usual, it's up to other implementations if they want to adopt it or not, or advise against its use. > many bLIPs will be sub-optimal solutions to the problem they try to solve > and some bLIPs will be simply insecure and may put users' funds at risk > (L2 protocols are hard and have subtle issues that can be easily missed) This may be the case, but I guess at times it's hard to know if something is objectively sub-optimal without further exploration of the design space, which usually means either more people involved, or more time examining the problem. Ultimately, different wallets/implementations may also be willing to make different usability/security trade-offs. One example here is zero conf channels: they assume a greater degree of trust with the party you're _accepting_ the channel from, as if you receive funds over the channel, they can be double spent away. However it's undeniable that they improve the UX by reducing the amount of time a user needs to wait around before they can actually jump in and use LN. In the end though, there's no grand global committee that prevents people from deploying software they think is interesting or useful. In the long run, I guess one simply needs to hope that bad ideas die out, or speak out against them to the public. As LN sits a layer above the base protocol, widespread global consensus isn't really required to make certain classes of changes, and you can't stop people from experimenting on their own. > We can't have collisions on any of these three things. Yeah, collisions are def possible. IMO, this is where the interplay with BOLTs comes in: BOLTs are the global feature bit/tlv/message namespace. A bLIP might come with the amendment of BOLT 9 to define feature bits they used. Of course, this should be done on a best effort basis, as even if you assign a bit for your idea, someone can just go ahead and deploy something else w/ that same bit, and they may never really intersect depending on the nature or how widespread the new feature is. It's also likely the case that already implementations, or typically forks of implementations are already using "undocumented" TLVs or feature bits in the wild today. I don't know exactly which TLV type things like applications that tunnel messages over the network use, but afaik so far there haven't been any disastrous collisions in the wild. -- Laolu On Thu, Jul 1, 2021 at 2:19 AM Bastien TEINTURIER wrote: > Thanks for starting that discussion. > > In my opinion, what we're really trying to address here are the two > following > points (at least from the point of view of someone who works on the spec > and > an implementation): > > - Implementers get frustrated when they've worked on something that they > think > is useful and they can't get it into the BOLTs (the spec PR isn't reviewed, > it progresses too slowly or there isn't enough agreement to merge it) > - Implementers expect other implementers to specify the optional features > they > ship: we don't want to have to reverse-engineer a sub-protocol when users > want our implementation to provide support for feature XXX > > Note that these are two very different concerns. > > bLIPs/SPARKS/BIPs clearly address the second point, which is good. > But they don't
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
> BIPs are already the Bazaar style of evolution that simultaneously > allows flexibility and coordination/interoperability (since anyone can create a > BIP and they create an environment of discussion). The answer to why not BIPs here applies to BOLTs as well, as bLIPs are intended to effectively be nested under the BOLT umbrella (same repo, etc). It's also the case that any document can be mirrored as a BIP, this has been suggested before, but the BIP editors have decided not to do so. bLIPs have a slightly different process than BIPs, as well as a different set of editors/maintainers (more widely distributed). As we saw with the Speedy Trial saga (fingers crossed), the sole (?) maintainer of the BIP process was able to effectively steelman the progression of an author document, with no sound technical objection (they had a competing proposal that could've been a distinct document). bLIPs sidestep shenanigans like this by having the primary maintainer/editors be more widely distributed and closer to the target domain (LN). The other thing bLIPs do is do away with the whole "human picks the number of documents", and "don't assign your own number, you must wait". Borrowing from EIPs, the number of a document is simply the number of the PR that proposes the document. This reduces friction, and eliminates a possible bikeshedding vector. -- Laolu On Wed, Jun 30, 2021 at 5:31 PM Ariel Luaces wrote: > BIPs are already the Bazaar style of evolution that simultaneously > allows flexibility and coordination/interoperability (since anyone can > create a BIP and they create an environment of discussion). > > BOLTs are essentially one big BIP in the sense that they started as a > place for discussion but are now more rigid. BOLTs must be followed > strictly to ensure a node is interoperable with the network. And BOLTs > should be rigid, as rigid as any widely used BIP like 32 for example. > Even though BOLTs were flexible when being drafted their purpose has > changed from descriptive to prescriptive. > Any alternatives, or optional features should be extracted out of > BOLTs, written as BIPs. The BIP should then reference the BOLT and the > required flags set, messages sent, or alterations made to signal that > the BIP's feature is enabled. > > A BOLT may at some point organically change to reference a BIP. For > example if a BIP was drafted as an optional feature but then becomes > more widespread and then turns out to be crucial for the proper > operation of the network then a BOLT can be changed to just reference > the BIP as mandatory. There isn't anything wrong with this. > > All of the above would work exactly the same if there was a bLIP > repository instead. I don't see the value in having both bLIPs and > BIPs since AFAICT they seem to be functionally equivalent and BIPs are > not restricted to exclude lightning, and never have been. > > I believe the reason this move to BIPs hasn't happened organically is > because many still perceive the BOLTs available for editing, so > changes continue to be made. If instead BOLTs were perceived as more > "consensus critical", not subject to change, and more people were > strongly encouraged to write specs for new lightning features > elsewhere (like the BIP repo) then you would see this issue of growing > BOLTs resolved. > > Cheers > Ariel Lorenzo-Luaces > > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun > wrote: > > > > > That being said I think all the points that are addressed in Ryan's > mail > > > could very well be formalized into BOLTs but maybe we just need to > rethink > > > the current process of the BOLTs to make it more accessible for new > ideas > > > to find their way into the BOLTs? > > > > I think part of what bLIPs are trying to solve here is promoting more > loosely > > coupled evolution of the network. I think the BOLTs do a good job > currently of > > specifying what _base_ functionality is required for a routing node in a > > prescriptive manner (you must forward an HTLC like this, etc). However > there's > > a rather large gap in describing functionality that has emerged over > time due > > to progressive evolution, and aren't absolutely necessary, but enhance > > node/wallet operation. > > > > Examples of include things like: path finding heuristics (BOLTs just > say you > > should get from Alice to Bob, but provides no recommendations w.r.t > _how_ to do > > so), fee bumping heuristics, breach retribution handling, channel > management, > > rebalancing, custom records usage (like the podcast index meta-data, > messaging, > > etc), JIT channel opening, hosted channels, randomized channel IDs, fee > > optimization, initial channel boostrapping, etc. > > > > All these examples are effectively optional as they aren't required for > base > > node operation, but they've organically evolved over time as node > > implementations and wallet seek to solve UX and operational problems for > > their users. bLIPs can be a _descriptive_ (this is
Re: [Lightning-dev] Turbo channels spec?
Thanks! On 6/29/21 01:34, Rusty Russell wrote: Hi all! John Carvalo recently pointed out that not every implementation accepts zero-conf channels, but they are useful. Roasbeef also recently noted that they're not spec'd. How do you all do it? Here's a strawman proposal: 1. Assign a new feature bit "I accept zeroconf channels". 2. If both negotiate this, you can send update_add_htlc (etc) *before* funding_locked without the peer getting upset. Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance. 3. Nodes are advised *not* to forward HTLCs from an unconfirmed channel unless they have explicit reason to trust that node (they can still send *out* that channel, because that's not their problem!). It's a pretty simple change, TBH (this zeroconf feature would also create a new set of channel_types, altering that PR). I can draft something this week? Thanks! Rusty. ___ 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] bLIPs: A proposal for community-driven app layer and protocol extension standardization
Here's another feature which just appeared and would benefit from a bLIP for compatibility: https://twitter.com/SimpleBtcWallet/status/1410506889545359365 Atomic splitting of bills. A very small thing, but also very cool. I can't imagine it fitting in the BOLTs at all. 2021-06-30 09:10 (GMT-05:00), Ryan Gentry via Lightning-dev said: > Hi all, > The recent thread around zero-conf channels [1] provides an opportunity to > discuss how the BOLT process handles features and best practices that arise in > the wild vs. originating within the process itself. Zero-conf channels are one > of many LN innovations on the app layer that have struggled to make their way > into the spec. John Carvalho and Bitrefill launched Turbo channels in April > 2019 [2], Breez posted their solution to the mailing list for feedback in > August 2020 [3], and we know at least ACINQ and Muun (amongst others) have > their own implementations. In an ideal world there would be a descriptive > design document that the app layer implementers had collaborated on over the > years that the spec group could then pick up and merge into the BOLTs now that > the feature is deemed spec-worthy. > Over the last couple of months, we have discussed the idea of adding a > BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various > members > of the community, and have received positive feedback from both app layer and > protocol devs. This would not affect the existing BOLT process at all, but > simply add a place for app layer best practices to be succinctly described and > organized, especially those that require coordination. These features are > being > built outside of the BOLT process today anyways, so ideally a bLIP process > would bring them into the fold instead of leaving them buried in old ML posts > or not documented at all. > Some potential bLIP ideas that people have mentioned include: each lnurl > variant, on-the-fly channel opens, AMP, dynamic commitments, podcast payment > metadata, p2p messaging formats, new pathfinding heuristics, remote node > connection standards, etc. > If the community is interested in moving forward, we've started a branch [5] > describing such a process. It's based on BIP-0002, so not trying to reinvent > any wheels. It would be great to have developers from various implementations > and from the broader app layer ecosystem volunteer to be listed as editors > (basically the same role as in the BIPs). > Looking forward to hearing your thoughts! > Best, > Ryan > [1] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html > [2] > https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster > [3] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html > [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK = Standardization > of Protocols at the Request of the Kommunity (h/t fiatjaf) > [5] > https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki___ > 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] bLIPs: A proposal for community-driven app layer and protocol extension standardization
Thanks for starting that discussion. In my opinion, what we're really trying to address here are the two following points (at least from the point of view of someone who works on the spec and an implementation): - Implementers get frustrated when they've worked on something that they think is useful and they can't get it into the BOLTs (the spec PR isn't reviewed, it progresses too slowly or there isn't enough agreement to merge it) - Implementers expect other implementers to specify the optional features they ship: we don't want to have to reverse-engineer a sub-protocol when users want our implementation to provide support for feature XXX Note that these are two very different concerns. bLIPs/SPARKS/BIPs clearly address the second point, which is good. But they don't address the first point at all, they instead work around it. To be fair, I don't think we can completely address that first point: properly reviewing spec proposals takes a lot of effort and accepting complex changes to the BOLTs shouldn't be done lightly. I am mostly in favor of this solution, but I want to highlight that it isn't only rainbows and unicorns: it will add fragmentation to the network, it will add maintenance costs and backwards-compatibility issues, many bLIPs will be sub-optimal solutions to the problem they try to solve and some bLIPs will be simply insecure and may put users' funds at risk (L2 protocols are hard and have subtle issues that can be easily missed). On the other hand, it allows for real world experimentation and iteration, and it's easier to amend a bLIP than the BOLTs. On the nuts-and-bolts (see the pun?) side, bLIPs cannot embrace a fully bazaar style of evolution. Most of them will need: - to assign feature bit(s) - to insert new tlv fields in existing messages - to create new messages We can't have collisions on any of these three things. bLIP XXX cannot use the same tlv types as bLIP YYY otherwise we're creating network incompatibilities. So they really need to be centralized, and we need a process to assign these and ensure they don't collide. It's not a hard problem, but we need to be clear about the process around those. Regarding the details of where they live, I don't have a strong opinion, but I think they must be easy to find and browse, and I think it's easier for readers if they're inside the spec repository. We already have PRs that use a dedicated "proposals" folder (e.g. [1], [2]). Cheers, Bastien [1] https://github.com/lightningnetwork/lightning-rfc/pull/829 [2] https://github.com/lightningnetwork/lightning-rfc/pull/854 Le jeu. 1 juil. 2021 à 02:31, Ariel Luaces a écrit : > BIPs are already the Bazaar style of evolution that simultaneously > allows flexibility and coordination/interoperability (since anyone can > create a BIP and they create an environment of discussion). > > BOLTs are essentially one big BIP in the sense that they started as a > place for discussion but are now more rigid. BOLTs must be followed > strictly to ensure a node is interoperable with the network. And BOLTs > should be rigid, as rigid as any widely used BIP like 32 for example. > Even though BOLTs were flexible when being drafted their purpose has > changed from descriptive to prescriptive. > Any alternatives, or optional features should be extracted out of > BOLTs, written as BIPs. The BIP should then reference the BOLT and the > required flags set, messages sent, or alterations made to signal that > the BIP's feature is enabled. > > A BOLT may at some point organically change to reference a BIP. For > example if a BIP was drafted as an optional feature but then becomes > more widespread and then turns out to be crucial for the proper > operation of the network then a BOLT can be changed to just reference > the BIP as mandatory. There isn't anything wrong with this. > > All of the above would work exactly the same if there was a bLIP > repository instead. I don't see the value in having both bLIPs and > BIPs since AFAICT they seem to be functionally equivalent and BIPs are > not restricted to exclude lightning, and never have been. > > I believe the reason this move to BIPs hasn't happened organically is > because many still perceive the BOLTs available for editing, so > changes continue to be made. If instead BOLTs were perceived as more > "consensus critical", not subject to change, and more people were > strongly encouraged to write specs for new lightning features > elsewhere (like the BIP repo) then you would see this issue of growing > BOLTs resolved. > > Cheers > Ariel Lorenzo-Luaces > > On Wed, Jun 30, 2021 at 1:16 PM Olaoluwa Osuntokun > wrote: > > > > > That being said I think all the points that are addressed in Ryan's > mail > > > could very well be formalized into BOLTs but maybe we just need to > rethink > > > the current process of the BOLTs to make it more accessible for new > ideas > > > to find their way into the BOLTs? > > > > I think part of what bLIPs are trying to solve here
