Stay on topic:
- This thread is only for comments discussing the uncertainties, shortcomings, and concerns some may have about Monero.
- NOT the positive aspects of it.
- Discussion can relate to the technology itself or its economics.
- Talk about community and price is not wanted, but some discussion about it maybe allowed if it relates well.
- Be as respectful and nice as possible. This discussion has potential to be more emotionally charged as it may bring up issues that are extremely upsetting: many people are not only financially but emotionally invested in the ideas and tools around Monero.
How it works:
- Post your concerns about Monero in reply to this thread.
- If you can address these concerns, or add further details to them – reply to that comment. This will make it easily sort-able.
- Upvote the comments that are the most valid criticisms of it that have few or no real honest solutions/answers to them.
- The comment that mentions the biggest problems of Monero should have the most karma.
Previous:
The first principle is that you must not fool yourself — and you are the easiest person to fool.
Governance
What’s the plan when the assault against the monero devs is launched?
The timeline is moving, the arrestation of Durov is a good marker of that.
Some devs are anonymous but that’s not a plan, just countermeasures.
The fact that I am asking is a sign that the community does not know how it it will deal with the governance attacks coming up.
Remember, they got BTC via its governance.
Notice that Signal isn’t attacked (at least not yet). Telegram is optionally end to end encrypted and it is a for profit company. Those are two vectors that Durov was attacked on. It’s the same reason Samurai Wallet was attacked on and Tornado Cash. Going after Monero would be much harder. It is not a for profit company (or even DAO). It’s privacy is part of the protocol, like SSH and when ring signatures are gone the final legal potential weakness will be gone. Legally, there is no clear way to attack Monero since if Monero is attacked, any privacy technology like VPNs and SSH and HTTPS could also be attacked and that would have a major industry backlash. It is far more likely that if an attack happens, the infrastructure would be attacked (e.g. getting Monero off github, etc) by putting pressure on the web hosts, but there are already several projects that work on GIT over TOR so this is more an inconvenience than a threat. At the moment, I’m not worried. If Signal and ZCash are attacked, then I’d start to be more worried.
Good points, I also think that they have easier fish to fry right now but that time will come, and the project needs to be ready for that. And when we start worrying is not a good time to start thinking about what to do.
I am a bit uncomfortable about the lack of shared knowledge about what are the attack vectors, when should we start to worrying about this or that, etc.
What’s the plan when the assault against the monero devs is launched?
Some devs are anonymous but that’s not a plan, just countermeasures.
What such a plan could look like? I don’t see other options except for staying anonymous…
I don’t know exactly right now what the plan should look like. We could ask the general fund to have someone at least look at it and give recommendations. Someone in opsec, systems design or the likes would do.
The way I see it, a good way to neutralize monero is to first identity as many important participants as possible and then take the opportunity of the next ‘crisis’ to bash them very hard and associate them with the worst possible terrorists in the public opinion.
By important participants I don’t mean just the core devs. I am talking about people like rbrunner, Justin, Rucknium, etc. All those that are the 5% making the 95% of impact in the ecosystem (compared to us consumers of their marvelous work). They currently don’t think their threat level is very high, they should not have to hide anyway. But the issue is that when they will find monero keys for whatever CP ring they can seize that opportunity to frame all our ecosystem as supporters of CP and terrorism. Remember, it doesn’t need to be true, just to be repeated again and again to the masses. After that you can just jail a few core devs, a few Dex operators and some event organizers to scare the little bunch back to their caves.
BTW the point is not to find a countermeasure yet but to put ourselves in the shoes of the adversaries and consider their options. The plan will itself come up after considering these points.
Tldr: let’s ask the general fund to review our strategic opsec as a project.
it’s not complicated, make sure that anonymity is maintained for all developers (like they do all their work from inside a whonix VM let’s say), and that you have copies of all the important monero mirrors somewhere (on a gitea instance accessible via .onion or something similar), in case if monero gets the tornadocash treatment.
that way they can’t go after the developers’ freedom of speech, and even if they take the repositories down from github, the show can go on elsewhere.
i’ll pitch in to advise people if opsec is brought up
Good! It would be nice to have that written somewhere accessible for all.
In case of Tornado Cash treatment everyone would also need a way to verify the signatures and authenticity for repos, links etc. That’s not trivial either.
Nah that’s easy too. you need to make sure the developers use PGP keys to confirm their identity. https://blog.nowhere.moe/opsec/pgp/index.html + https://blog.nowhere.moe/opsec/whonixqemuvms/index.html
but yeah the idea is to have a Disaster recovery plan, kind of idea, totally makes sense.
Great articles btw!
Nice! A disaster recovery plan would fit the bill nicely.
Unrelated, I have personally started switching from pgp to minisign (for signing stuff and confirming it’s indeed from me) and age (for encryption, when I don’t want prying eyes on my stuff, https://github.com/FiloSottile/age).
Basic OPSEC is not very hard but needs investment in terms of time and money. Running something like Qubes with Whonix/I2P routers should do well enough in terms of traffic obfuscation, and backup and encryption strategies for keys should be the next level.
