Add ability to select "Splinter" instances #1073
Conversation
There is no "current fragmentation". There is exactly one network that is actually live. |
|
The only funds that a network is able to "drain" are funds that are in open offers and requires a rogue arb to make a puppet buyer account, take the offer and then get selected by the maker as the arb so they would have 2/3 keys. Sure, a scammer absolutely could set up a network where they are the only arbitrator and they could then rug all offers that are posted. However, I do not believe we can coddle users if they lose their funds from not doing the proper research then that is their fault. Being your own bank and doing things for yourself requires due diligence. |
|
And yet there is zero reason to add this without a second network even existing. All it does is introduce incentives for scammers to spin up fake networks with fake offers to bait people into taking them. As it stands, this would introduce an attack vector with absolutely ZERO upside. I can honestly not comprehend why you guys are gunning so hard for this, it doesn't make any sense. |
|
While it is not there currently (I won't be "beautifying" the PR until I fix more pressing issues with it) I plan on there being a very strong warning to users that they should ensure that they are using information from a proper source. As for the argument regarding multiple splinters not existing, that is currently correct. That will likely end up changing in the near future, perhaps even by the time that this PR is fully ready for a merge. All that Reto, or any other splinters, will need to do is make a config file and have a method of distributing said file. In the long term, this PR will also open the door to allowing multiple splinters to be listed concurrently in the same order book, if that is a desirable goal in the future. Addendum: it also just occurred to me that a malicious splinter could take advantage of the lack of a multi-network client to create one themselves and then use the client in any number of malicious attack scenarios. |
So your idea is that the official mainnet client is released by haveno-dex and the networks release a config file? We should definitely do that later. We can't stop anyone from opening further Haveno networks. I think we should first have a stable network before taking the step to a distributed network. |
|
How is Reto planning on vetting arbitrators and seed nodes? Haveno was originally built with the assumption that "infrastructure" like arbitrators and seed nodes would be put under heavy and transparent scrutiny. I agree that there is confusion from having haveno and Haveno-Reto separate. Much of this confusion stems from the fact that the current client in haveno-dex is currently unusable by end users, requiring the project to be forked to add another network. Haveno-dex is currently a template and testing ground for developers. This PR will change it into a functional client. It will be incredibly difficult for any other splinter to gain ground at all if there isn't a central client. Creating a distributed network spanning multiple splinters will be borderline impossible if they are all forced to run independent clients, especially if the clients start adding additional modifications not present in upstream. |
|
And as for the scamming risk (which is a valid concern): A successfully fraudulent splinter would harm Haveno. But if Reto were the only "stable" splinter and it was compromised, the effect would be disastrous for Haveno. Same goes for if any other network were to become "the main Haveno" |
I can tell you that that is simply not true at all.
i don't think that is a bad thing. the more you fragment liquidity, the less usable haveno becomes. ironically, fragmenting haveno liquidity across multiple "splinters" (man i hate that word, it doesn't fit at all, just go with "instance") makes it more likely that any given network would try and exit scam. think about it: you don't exit scam if you get a ton of fees but if you only have 100 XMR on the books and make 10 cents of fees a day, the thought of draining those and starting a new instance becomes a lot more appealing. there is also still a massive difference between "i got scammed after downloading the ABC-haveno-client" vs "i got scammed after downloading haveno". one of these is arguably a lot worse PR for haveno as a whole. you all act like other networks are just around the corner, yet it's been over a month and the only attempt at another network was very strange and quickly vanished. Unless preland plans to launch their own network and knows they can't compete with reto under the current setup, which would of course explain everything. |
To be honest, I don't know. Tinted and m will definitely choose the arbs carefully, they don't want to ruin their network. But they will definitely be people they already know or are known in the Monero or Haveno community.
Personally, I would like to download the official Haveno mainnet client from Haveno-dex. But that brings you developers back into the focus of the fed's. Therefore, you should decide on your own because that is your risk. |
I don't think so because they would not be distributing the network file. They would just be distributing the software and you would then have to put your own network file into it. |
|
Yes; the Haveno client is just that: a client, entirely divorced from any running splinter. To be absolutely clear, I have absolutely no intention to run a splinter-you could offer me 100+ XMR to do it and I'd still say no. I also have no intention to behave in such a way that would directly enable any network to thwart any other. |
Only for the records: |
|
This needs to be done if for no other reason than allowing people to download executables from Haveno directly rather than 3rd party repos. Some people think you have to build it from source in that there are no executable files as evidenced by this reddit comment |
|
And those people would 100% get baited into adding some scam network that has an official sounding domain, they get drained and now "Haveno is a scam, use this OFAC sanctioned, centralized, custodial exchange instead".... or you could just point them towards the repo of a legit network at which point they might even get curious enough to ask why things are this way.
and this is absolutely correct. multiple networks fragment liquidity all over the place and confuse people even more. it is already decentralized software. in my opinion, at this point the goal should be to rapidly decentralize reto as much as possible instead of opening the door for scam instances. one network with 100 seednodes is infinitely better than 100 networks with 1 seednode, in any and all aspects. |
|
I will wait and see what woodser has to say regarding this, as neither the scenario that I have discussed nor the scenario that others have discussed was the original intended design of Haveno. |
I have to disagree with this line of thinking. The average Haveno user can barely figure out how to install and use the app. So it's not hard to imagine cases where a person simply does not realize they are connecting to a malicious network (even with their best intentions and due diligence) and can you imagine the fallout that will arise for Haveno (in general) should a scam occur do to this change. Also, if there are multiple concurrent networks won't that segregate the makers? So instead of a maker creating 1 offer on 1 network for everyone, lets say there are 10 different networks, the maker would have to create 10 identical offers? |
I am entering this discussion, because I was affected by it. I think the problem for me was to understand the basic concept of a network and how it is used in haveno. I did not feel informed enough about this separation. This knowledge gap lays the foundation for more confusion. What networks are out there? Are these networks equally trustworthy as the creators of haveno? Who is responsible for issues? Where to report? What is the difference in client for different networks? Why does the network decide about which feature will come and when? Are offers valid in all networks? Generally. I think the "network" must be better discribed. When issues occur using a network (in conjuction with haveno), a small percentage of users probably will do report issues in github. Others will simply stop using the software. I think being able to select or configure the network would do good to all groups of people. For people that do report issues, a single project would be much clearer to report issues to. In the end there will be always some effort to distinguish between network and haveno issues. This is unavoidable. For average users, selecting a different network could be a last chance to stick with haveno. For network operators the effort to maintain code will be reduced. They dont need to keep merging code and they can focus on operation. I guess it was not intended that networks will introduce their own features, right? |
Only reto, making your whole point about a user experiencing issues going somewhere else instead of quitting moot.
The intended design was to have exactly one haveno network. |
This PR, once matured, will allow a user to download the main client, input the information of their desired "Splinter", or independent Haveno instance, into the client (this information, along with the information of all other splinters, will be saved), and then select said splinter and connect to their network. Information can be inputted either by hand using a form, by passing in a config file, or by inputting a URL (the url would simply be a link to the config file, hosted by the splinter).
Motivation:
Reduce the current "fragmentation" of Haveno. In order to use Haveno currently, you have to install a client that is directly vendored by the instance. This results in newer features being "locked" from users until the clients update to upstream. Speaking of locks, forcing users to install a different client for each network encourages "lock-in" among instances. It is also incredibly wasteful, as the only meaningful difference between "splinters" is less than 40 lines of code, all of which are variable changes.
Notes on the PR (valid as of the creation of the PR, subject to change)
This PR currently just adds a form which you can input info into. It is not pretty, and it will throw errors at you as you input it in, but it will connect properly (tested with Haveno Reto). It should be noted that the maker/taker fee prompts do not actually do anything yet, so Reto cannot be properly used for transactions yet.
Assuming I can keep my attention on this, it should be ready for merge within the next few weeks