code for pNode (concerned about what the pNode would be doing on my network if I bought a Node Tree which was my plan:
code relevant to the Provide funding (so we know where and how the Provide PRV is sent)
code for bridges (so we know what’s actually happening and so we can help make more)
I’m having trouble with seeing proof on what happens when you stake in Provide as well as what is running on a pNode. Since it’s all open source, maybe someone can just point me to the right spot.
Hey @int1 not all aspects of the network is open-sourced yet, but @aaron works on an article that can bring more clarity for info on which parts aren’t open sourced yet, why, and when to be open-sourced.
Unfortunately, those 3 major things, are currently things we are still pushing to get more transparency with. With the upcoming audit I think things will be more clear.
Code for pNode - Currently closed source, but vNode’s are opensource. There’s a bunch of fancy code in the pNode to make it plug and play. People have voiced their concerns about what the node does on their network because it’s not opensource, but the best I can offer is to go to town packet sniffing.
code relevant to the Provide funding - That is also currently closed source. The Provide feature was supposed to be temporary anyways. But with defi you kind of want to know the code behind it. Adding liquidity normally is open source though.
code for bridges - Also closed source and currently not decentralized, but the code behind creating of a bridge isn’t to complicated to work out. The decentralization is being worked on now, so hopefully this will all change soon.
pNode: I’m not sure I follow on why “fancy code” to make it “plug and play” is a reason to close the source code. Can you explain further on the rationale there as you understand it? Well…some people HAVE gone to town packet sniffing and uncovered what appears to be constant DoS attacks being launched from the pNode like it’s in a botnet so…that’s why we need the source code. I think you’re just validating my concern on this one.
Provide: Yes. Adding liquidity is normally open source, like you said. But not with Incognito? Here, as far as I can tell, the pCoin/PRV just goes…somewhere. Into someone’s pocket? 100% to pDEX? Nodes? Who knows. We just blindly trust and hope it doesn’t vanish, pretty much. Not sure the upside to closing the source on this one. Even if it’s temporary, I’m not following the rationale on anti-open-source. on this one, either.
Bridges: If the code isn’t too complicated to work out…what is the upside to keeping it closed? I know I’m asking the same question for all three points, sorry. I don’t care that it’s not decentralized or that Provide isn’t decentralized. I know that will come with time and development. What I do care about is how critical pieces are being intentionally hidden from users. That’s dangerous on top of showing the mindset of the team. So I’m giving benefit of the doubt and just asking, so the users can know and make judgements for themselves on agree/disagree, why not share the code for things like the bridges?
The Incognito team makes money from selling the pNodes, so the software it runs is based off of the open source stuff, the rest is just proprietary. I agree that we should definitely have some sort of rigorous testing for things like this. But, the fact is, you don’t really have to buy a pNode.
Provide is closed source and the Incognito Team are the ones moving the money around with their own proprietary software. Provide is “Single Sided Liquidity” and isn’t the normal way of adding liquidity. Adding liquidity through “Add” is known and isn’t proprietary. Here is the github, and if you want to find the code for the pDex itself, use this link.
(The ETH bridge is public and located here)
Initially the idea was for crypto communities to host their own bridges because they are “Trusted” bridges and not completely decentralized. The thought was that crypto communities would feel that the bridge was safer if the community organized the construction of the bridge themselves, and not Incognito. However as more members joined Incognito, the devs were pushed to be custodians, and make more bridges. Since this is major infrastructure for the Incognito network, making it public without an audit could cause a problem. If someone found a bug in the code and was able to exploit it, people’s assets could lose significant value. I believe there was talk about making the bridges opensource after the audit. We are definitely fighting for more transparency, and the devs are working on ways to do that with public view keys.
As decentralization happens, this would be less of an issue, which is exactly why I’ve been pushing so hard for decentralization.
Fair point on not having to buy a pNode, and I have absolutely no problem with the team making money from pNodes. That’s awesome. My point is more about building trust, especially when it launches DoS-like traffic. People will still buy pNodes when it’s open source. They are marketed to people who want plug and play and wouldn’t compile code anyway. Just a matter of not hiding what you’re doing. Some industries don’t need it, but this one looks for it. I’m not saying that it needs rigorous testing, just be more open from the start and let users be the judge of the testing level it needs.
Again, trust building. Provide basically means we send money to the Incognito team with no guarantee of getting it back since it’s off-chain. Just a one-way trip for our money in hopes of a return. No proof of where it goes. No idea if it’s being used for something good, bad, sketchy, etc. I appreciate your responses, but I’m still missing the “why” of making these things being hidden. I see that they are proprietary. I don’t know why they are.
Now this I can work with a little. Thank you. This one has rationale! I disagree with the rationale as a justification for closing the source for bridges, but at least there is a reason being provided that can actually be debated among users and developers. My reason for disagreement: bugs/flaws can be found whether it’s closed or open. Yes, open makes it easier, of course, which is why I feel the proper procedure for a project that relies on transparency from the ground up is to develop a bridge, put it on the testnet, let people see the code and test it. Once it’s accepted, functional, and secure enough, move it to mainnet. Closing the source code is not an acceptable solution to potentially insecure code. Open source lets us look at it and test it before it gets added as well as identify and fix flaws. My personal perspective.
Basically, my belief is that when you are making a system that is centered around trustlessness, transparency, privacy, etc. you have to start with a groundwork of those things and add the rest as you go. You can’t sacrifice transparency on the altar of “safety” and then put what you believe to be potentially unsafe code into production and just say it’s safe because the code isn’t released. Then you’re making suspect safety choices while also losing trust of users. There are ways to be fully transparent AND build things safely. You don’t have to add unaudited, open source code that isn’t safe yet to the mainnet.
Anyway, just my two cents. Thanks for the explanation on the last of the three points. Glad there’s at least a reason. Still curious to hear the rationale for the pNode and Provide source closing, as I think those two are way more trust destroying. One makes people question what shady activity is happening on their networks and why they won’t share how the node works. Oh, and people have unplugged their nodes and still make returns on it, making people wonder if it’s actually validating transactions on the network…would love someone to explain the DoS traffic and how a pNode validates transactions without power or internet connection. The Provide issue makes people question what the team is doing with all that money they get sent. Really, there’s nothing stopping the team from grossly abusing the Provide system, and we’d never know. Makes you wonder what’s to hide. Not saying that’s what is happening, but that is the criticism you open yourself up to when you choose to put up a curtain and ask people to throw money under it and also claim to be all about transparency. Tons and tons of highly successful cyber privacy projects have been 100% open source from the start, despite being in fields that would be equally damaged by security exploits. It can be done, has been done, and should not be done any other way.
What has been accomplished is fantastic. It’s something of which to be proud, but if it goes any farther without making everything transparent, it is going to cause problems among your target audience/market. I’m not talking about decentralization (which is important and needs to come in due time), I’m just talking about transparency. One priority at a time.
I completely agree, I’ve been in the Incognito community for a while and the reason I’m still here is because of the potential. We have grown a lot and added many features but it’s still a work in progress. At some points we had to do quick fixes and temporary solutions to keep things working smoothly. At the end of the day, we are still here. I’m comfortable keeping my money in the platform because I feel like I have influence over how the platform grows. If somethings off, or somethings wrong, I’d be the first to know. There aren’t many investment opportunities that allow something like that. If I lose my money it’s my fault for not making enough noise about potential issues
This is a community, and everyone’s views on things only help strengthen the network.
I myself have been pushing for more transparency but personally I focus more on decentralization because you can’t decentralize without being completely transparent. I’ve been working on getting community representation in the Incognito DAO, so we can guide the direction of the platform more effectively, this has been a work in progress, and with the next builder rewards, I believe we will start to see more transparent flows of operations. There are a lot of issues to fix and many things to prioritize.
The core framework of Incognito is open sourced. The things that are closed source are the things that make the platform more user friendly and usable, like one sided liquidity providing, or plug and play pNodes. They are added features that aren’t really necessary for the functionality of the platform. Bridges on the other hand are necessary, and that situation will hopefully be fixed soon.
I honestly think the reasoning behind not open-sourcing those things from the start is because it seems like priority on projects get’s switched around a lot. For a long while we didn’t have any documentation on the SDK’s and what not. Currently we have some documentation, but it is still a little shotty (It’s definitely usable though).
Provide was a feature quickly made out of necessity (So I honestly don’t expect the code to be the best ). Liquidity earning rates went down, which made the Incognito in app Node staking rates more profitable then having money in liquidity. You wouldn’t earn anything from liquidity because you would get hit hard by the Impermanent or Divergent losses. The price of PRV started to tank because of it. Provide was more or less a quick patch to fix the problem, it’s actually not really sustainable. But people became happy when it was implemented, and the price of PRV went up. Right now Provide v2 is getting worked on to fix the issues we currently have and it will most likely come out pretty soon. It was a temporary solution so they could work on a better system. Open sourcing things takes more time which wasn’t available in this particular scenario. Why continue to work on something that’s good enough when it’s more productive to work on the actual solution. At least that’s how I view it.
Open sourcing things takes more time which wasn’t available in this particular scenario.
I was going to reply to a lot more on this post but decided the massive back and forth would just lose a lot in the process plus it seems like we basically agree about everything else except I think it’s more of a problem. Anyway, I’m just responding to the quoted piece above.
Open sourcing doesn’t take time. It adds maybe a few extra seconds. They already have a GitHub account and clearly know how to sync with git, so I’m not really sure what you mean that it takes more time. When something is created, it has to go on GitHub first and then get released. They go hand-in-hand. This concept of releasing something, expecting everyone to just blindly use it without having any clue what it does, and then maybe they will consider showing us what we’ve been using all this time on down the road is really…well that’s not how privacy projects should go.
The thing is, I don’t think anyone disagrees with you, including those of us from the core team
There has been discussion about this countless times already, but I’ll sum it up:
Provide is and was always a temporary solution to liquidity, it’s closed source to make sure your funds are safe. Yes, that means you have to trust us, which is not ideal, so we’re replacing provide with a decentralized incentive structure soon (more detailed announcement coming this week).
pNodes are basically Intel computers with vNode scripts, and a bit of proprietary software. We’ve completely stopped producing and offering Nodes, however, so this is no longer an issue.
Bridges are the only functionally important part of this project that are closed source, since the blockchain itself and about everything else is open. The end goal is having every bridge to Incognito be trustless and open-source, but it’s quite a process. We’re working on it though. That’s what this project shift was about.
TLDR; we agree, and announced steps to solve all of that last week. Hope this helps!
). Liquidity earning rates went down, which made the Incognito in app Node staking rates more profitable then having money in liquidity. You wouldn’t earn anything from liquidity because you would get hit hard by the Impermanent or Divergent losses. The price of PRV started to tank because of it. Provide was more or less a quick patch to fix the problem, it’s actually not really sustainable. But people became happy when it was implemented, and the price of PRV went up. Right now Provide v2 is getting worked on to fix the issues we currently have and it will most likely come out pretty soon. It was a temporary solution so they could work on a better system. Open sourcing things takes more time which wasn’t available in this particular scenario. Why continue to work on something that’s good enough when it’s more productive to work on the actual solution. At least that’s how I view it.
plus it seems like we basically agree about everything else except I think it’s more of a problem. Anyway, I’m just responding to the quoted piece above.