The way it would work would be that an arbitrator would create a bot to take the offers and then use the key from the taker bot and their arbitrator key to steal the escrow which contains the seller's Monero plus their security deposit.
It seems like the two ways to avoid this would be to either
A: have a bunch of arbitrators so that any one arbitrator is not chosen for the vast majority of the offers
or
B: make offer taking a request process instead of a demand process.
Not that I think it's likely that this might occur any time soon. Nevertheless would be good to see more discussion around tbis topic and risk mitigation code or strategies.
I've already brought it up to the developer, Woodser, and we will see what he thinks. Because to me, it seems like a valid criticism, and valid criticisms need to be looked at.
My thought would be that since zero deposit offers already currently generate a random password client side that must be given to the taker that it could be used for all offers instead of just zero deposit offers.
Now, that requires being able to contact the seller in order to get the password, and in version 1.0.19, that functionality has been added, and it is going to be a required update anyway. So, potentially, it could get put in to version 1.0.19.
What I am unsure of is how you go about upgrading already published existing offers that don't have contact information. I guess you could force delete them and have them be recreated after the update, which while a paint in the ass would be worth it.
woodsers response:
> Would you mind reading through this and giving your response?
a malicious arbitrator could attempt to take offers, hoping to be assigned trades and then unfairly award funds to themselves. however this risk can be mitigated by:
- a sufficient number of arbitrators - the best way to mitigate this risk is to have a sufficient number of honest arbitrators, so a dishonest arbitrator is unlikely to be assigned a trade before being detected and banned. this creates an economic incentive for arbitrators to act honestly and earn trade fees rather than risk exclusion
- arbitrator selection by the maker - the maker can select an arbitrator from a trusted list rather than relying on random assignment (the current default)
- trade limits per client - restricting the number of active trades or funds at risk per client further reduces potential damage from a dishonest arbitrator
in contrast, centralized exchanges like localmonero, openmonero, etc require full trust in the platform operators, because:
- they take full custody of traded funds and can easily steal them at that time
- reputation can be easily faked, so does not provide any guarantee of trustworthiness in trade partners
- they can collect and store sensitive trade details across all traders
- they're more likely to be shut down due to legal compliance, and you're left to find a new service
ultimately users should consider the trustworthiness of the haveno network they're using and its arbitrators, but these networks provide greater decentralization, privacy, and control of funds than centralized services, which are a single point of failure
link to woodser's response to prove i didnt make it up: https://matrix.to/#/!UuoWQWMGvPBHkIgWGJ:monero.social/$bVIMNjW1yEbdIHK-yEPuN-H2fXVmqEaXXLe4lgtuk68?via=monero.social&via=matrix.org&via=catgirl.cloud
OpenMonero response to Woodser haveno dev (haveno rug pull scenario)
> a malicious arbitrator could attempt to take offers, hoping to be assigned trades and then unfairly award funds to themselves. however this risk can be mitigated by:
> a sufficient number of arbitrators - the best way to mitigate this risk is to have a sufficient number of honest arbitrators, so a dishonest arbitrator is unlikely to be assigned a trade before being detected and banned. this creates an economic incentive for arbitrators to act honestly and earn trade fees rather than risk exclusion
I totally agree that individual arbiters need to act honestly so they don't get banned by the network operator. But honestly, that's not the main issue here. The real risk of a rug pull attack (or exit scam) doesn’t come from those individual arbiters, but from the network operator, whom we’ll call "Reto." Reto has the power to assign arbiter roles, which is where the problem lies.
The network operator is a single point of failure because he can create as many arbiter roles as he wants since he holds the admin key. Sure, Reto might give a few trusted individuals arbiter roles to make things look decentralized and transparent. But he could just as easily assign a bunch of roles to bots he controls. Plus, Reto would be in charge of all the taker bots, since anyone can jump in and be a taker. This setup lets Reto secure a two-thirds majority in any disputes that come up.
So, when it comes to pulling off an attack in this scenario, the odds are nearly 99.99% in favor of success. That’s because, when the attack happens, most of the arbiters and takers will likely be bots, all under Reto's control, making them the real weak link in the system.
> arbitrator selection by the maker - the maker can select an arbitrator from a trusted list rather than relying on random assignment (the current default)
The network operator is probably going to kick out all the human arbiters before they carry out the rug pull. This means the makers won’t have any choice but to use arbiter bots. Plus, the makers won’t really have a chance to dispute anything because a taker bot will just send a fake "I have paid" message even though they haven't actually paid. Then, that taker bot will start a dispute, leaning on the arbiter bot to back them up and go after the maker's funds unfairly.
In the end, the arbiter will take the 15% security deposit from the maker, while the taker bot walks away with the trading funds and its own 15% security deposit. The key thing to remember here is that both the taker and arbiter bots are under the control of the network operator, so all that money ends up in their hands, leaving the maker with nothing.
> trade limits per client - restricting the number of active trades or funds at risk per client further reduces potential damage from a dishonest arbitrator
If you try to limit how many active trades takers can have, it won’t really make a difference because anyone can be a taker. So, the network operator (or reto admin) could just set up as many taker bots as they need to get around those limits.
> in contrast, centralized exchanges like localmonero, lm, etc require full trust in the platform operators, because they take full custody of traded funds and can easily steal them at that time
I totally agree with you that most p2p platforms (like centralized exchanges) usually hold full custody of the funds since they require pre-funding for trades. But OpenMonero is different because it doesn’t need sellers to fully fund their trades upfront thanks to its self-custodial trade funding setup. The platform can’t access all of the liquidity at once unless every seller decided to post their bonds at the same time, which is statistically improbable.
It’s also worth mentioning that LocalMonero used to lack the self-custodial trade funding option, meaning that seller funds were always at risk while they waited for trade requests. Right now, OpenMonero can only tap into a maximum of 2% of the total liquidity at any given time, unless every seller posts their externally funded bond at the same time, which remains statistically improbable.
So, we can say that OpenMonero acts like a centralized exchange, but the liquidity is actually decentralized thanks to the self-custodial trade settlements for buyers and self-custodial trade funding for sellers. I suggest checking out the examples on simplifiedprivacy.com for more insights, especially if you’re looking into advanced examples.
> reputation can be easily faked, so does not provide any guarantee of trustworthiness in trade partners
No system is perfect, but it's fair to say that having a reputation system is definitely better than having no verification at all. It’s worth mentioning that faking a reputation system isn’t easy and it requires a lot of money and time. Sure, someone could try to create fake trades on OpenMonero, but the system can pick up on that pretty quickly (for ex, if someone makes 1000 trades in a short period, that would definitely raise some eyebrows)
Sellers/Buyers can also check users' Telegram handles through trusted sites like localmonero.co or confirm PGP keys from reliable sources, including LocalMonero and imported profiles.
Plus, you can’t do coin-locking on OpenMonero since sellers need to fund trades manually. It’s not an automated process like on networks like Haveno, which really helps to reduce the chances of exit scams. When it comes to offers on OpenMonero, they’re not fully funded right away. You only need 0.35 XMR to list an ad in the search results. This is mainly to fend off spam listings, but it can also help fund smaller trades. If a trade is bigger, sellers have the option to use an external, fully isolated wallet to fund the transaction and keep themselves safe from any potential scams right from the start.
> they can collect and store sensitive trade details across all traders
I don’t have an admin panel to keep track of trades or messages, and users can set up self-destructing messages right after a trade or completely delete their accounts. This kind of feature probably wouldn’t work in decentralized systems since all data is saved on multiple nodes. Also, the OpenMonero wallet creates a new address every time you make a deposit to help keep your privacy intact.
> they're more likely to be shut down due to legal compliance, and you're left to find a new service
My identity is kept private, and OpenMonero vendors don’t have to go through any KYC checks, which means we can totally work outside of regulations. This works because the platform isn't custodial, it's open-source, and you can access it via Tor hidden services and I2P. So, even if the clearnet domain gets taken down by the authorities, the exchange would still run smoothly. Anyone can self-host the frontend or even fork the code to make their own OpenMonero version. Plus, we’re working on a Nostr-based version that lets anyone become an escrow provider or self-host the frontend without needing any backend. This would make it super resistant to censorship. Check out the interview for more details!
> ultimately users should consider the trustworthiness of the haveno network they're using and its arbitrators, but these networks provide greater decentralization, privacy, and control of funds than centralized services, which are a single point of failure
Most of my vendors don’t really need to trust me because they don’t have to download any software or put down trading funds upfront to get trade requests (unlike Haveno). This really cuts down the chances of exit scams right from the start, and it keeps their personal files safe from malicious access. The OpenMonero web app runs smoothly in any browser and doesn’t connect to the user’s system, which is way different from Haveno that needs to be installed and has a daemon running all the time on your computer (definitely a recipe for keyloggers and shady auto updates). Plus, the built-in non-custodial wallet in Haveno isn’t very secure since malicious updates could come with keyloggers to snag your private keys. But with OpenMonero, vendors can fund their bonds using totally isolated wallets like Cake Wallet, Moneroju, Monero Wallet CLI, Feather Wallet, Trezor, and more.
The Haveno platform mainly looks out for the network operators, but it doesn’t really do much to protect market makers. This leaves them open to the risk of exit scams since the liquidity, the most important asset, is fully controlled by the network operator.
Also, let’s be clear: Haveno isn't truly decentralized. Accounts and order books don’t get shared between different Haveno instances, which creates a fragmented setup that’s kind of like a local network. The system would work a lot better if there was one big network where accounts and offers were merged from various instances instead of just having this isolated system run by a single operator. That’s not how decentralization should work.
When we talk about fund security, decentralization isn’t the most important factor. What really matters are things like how quickly trades get finalized, self-custodial trade settlements and self-custodial funding, along with a solid reputation system. Without a reputation system, there’s no trust between trading partners. Plus, if we don’t have self-custodial settlements or funding, the admin could easily run off with all the liquidity.
I’d love to keep the conversation going if you have any other points you want to bring up. I think Haveno does a pretty good job of protecting network operators, and I really appreciate that it’s open-source!
However I think OpenMonero is more safe (multi-sig vs self-custodial) and has 98% less risk of total liquidity being jeopardized at all times. The occurrence of exit scams is relatively low within this model.
Reference: https://archive.ph/GsDsn
Interview: https://simplifiedprivacy.com/openmonero-interview-with-the-dev/compared-to-reto.html
#Privacy #Markets #HiddenService #News #Work #Monero #Crypto #Hacking #HarmReduction #Guides #Bisq #cakewallet #haveno #retoswap #trading #p2p #escrow #localmonero #dex
great thread y'all
thanks for hashing through this.
I am actually considering using both. The zero-deposit offers on Haveno would not be subject to taker bots because a password is generated on the client side that must be entered before the offer can be taken which would make them immune to the bot issue you bring up. OpenMonero has a UX advantage since there is no software needed and it just runs in a browser like LocalMonero did. It seems to me the best solution is not one or the other. It's both.
Seems correct to me
Basically, the haveno network operator can give admin roles to both taker and arbiter bots as well, which lets them ignore any rules in place. This speeds up things a lot since there’s no need to put down a security deposit for each taker bot, allowing all maker funds to be unlocked right away. These bots only work on the API level, so they don't mess with the user interface.
Because of this, it doesn’t really matter if you set up limitations on the frontend or the public API; the admin bots will always be able to access the protected API endpoints. This access is key to getting around rules like security deposits, rate limits, or any other client-side requirements for takers or arbiters.
The admin bots won’t use the public API, since developers would catch any shady changes to it. Instead, they’ll send requests to a protected API run by the network operator on a low-cost VPS for about $5 USD. Only the admin bots (taker and arbiter) will have the keys to access this protected API. This API will basically look like the public API but will have tweaks to bypass all those rules. So, only the maker will use the public API and will have to follow its rules.
To make things work, all you really need is the admin key, a protected API, and a few VPS servers for the taker and arbiter bots. These taker bots will throw the admin keys into the headers of their requests. If a normal taker tries to hit up the protected API without the admin keys, the request won't work. It’s actually pretty simple, and it might have been overlooked because of that.
Also, it’s good to remember that multi-signature setups only make sense when there’s no admin or network operator. The operator is always a single point of failure and can sidestep any limits on the API using their admin keys.
If anyone has a solid reason why this wouldn’t actually work, I’d love to hear it. When someone has the admin keys for their network, they can pretty much do whatever they want and set the rules while everyone else has to follow along.
To wrap it up, everyone in the haveno network, the taker, the arbiter, and the maker will get a key in the multi-sig trade. But there's also a fourth key, called the "magic key" that can do a bunch of powerful things, some of which could be a bit risky.
Reference: https://archive.ph/GsDsn
Thread: https://primal.net/e/nevent1qvzqqqqqqyqzqpg8r34v5d5z4ecxmc0c749cwjalaw4xu2ttpnh8zms0lhfepg450s7qlk
Interview: https://simplifiedprivacy.com/openmonero-interview-with-the-dev/compared-to-reto.html
#Privacy #Markets #HiddenService #News #Work #Monero #Crypto #Hacking #HarmReduction #Guides #Bisq #cakewallet #haveno #retoswap #trading #p2p #escrow #localmonero #dex
I've been using RetoSwap since it came out earlier last year and have had no problems. But it still seems like good points you bring up.
Any ideas on what could improve Haveno in this regard?
What would you say are some downsides of using OpenMonero vs Haveno?
I'm open to using OpenMonero, but seems very new. I just think you guys need more time to build trust and reputation with the community at large. It seems like you guys are also a similar model to LocalMonero so have the same centralized point of failure(which I hoped we could get away from). Maybe the only difference being you're operating somewhat anonymously?(true?)
Let's be real, nothing comes for free. The fact that there are no arbitration fees on the retoswap network might make you think that users are actually the product. If you dig a little deeper, you'll find a bunch of issues, with the risk of exit scams being a big one.
A decentralized node network is only secure if there's no admin who can circumvent the rules. To address the exit scam issue, either eliminate the admin or remove the liquidity.
People want to trade online without the hassle of installing software, which can threaten their privacy. Trusting someone to keep your computer safe isn’t easy, and even open-source code can have hidden risks since most don’t compile it themselves. With OpenMonero, you can avoid those worries because it’s just a website that doesn’t need permissions.
The built-in non-custodial wallet for haveno funds isn’t very secure either, since private keys could be logged, and the project isn’t truly decentralized. The GitHub repo isn’t easy to fork, it’s built in Java and is pretty complicated. The more complex the code is, the tougher it gets for developers to spot vulnerabilities or malicious code.
Haveno is better at resisting censorship than OpenMonero, but this mainly benefits the admin. Without a reputation system, vendors can't import any stats to other platforms, leaving their accounts on Haveno fairly low in value. It’s unlikely that any former LocalMonero vendor, who has built up their reputation over the years, would want to use this system.
OpenMonero launched in June 2024, and I've recently started promoting it on social media. I encourage you to check out our list of over 150 verified vendors, including respected LocalMonero traders. If these vendors have confidence in the platform, users are likely to feel the same way.
Vendor list: https://nojs.openmonero.com/guides/how-to-import-reputation#cachedUserList
Reference: https://simplifiedprivacy.com/openmonero-interview-with-the-dev/compared-to-reto.html
Reference: https://primal.net/e/nevent1qqsq2pcudt9rdq4wwpk7r784fwr5h0lt4fhzj6cvaeckurla6wg29dqkrrz7a
#Privacy #Markets #HiddenService #News #Work #Monero #Crypto #Hacking #HarmReduction #Guides #Bisq #cakewallet #haveno #retoswap #trading #p2p #escrow #localmonero #dex #cex #moneroju #xmrbaazar #security #agorism #cypherphunk
There will be fees on Reto again after December of 2025. The only reason there are not fees currently is because there is an agreement in place with some people from the Monero community who are funding it until there is more volume. Ask in the SimpleX room.
