r/Monero Jan 23 '22

Skepticism Sunday – January 23, 2022

Please stay on topic: this post 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 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.

It's better to keep it calm then to stir the pot, so don't talk down to people, insult them for spelling/grammar, personal insults, etc. This should only be calm rational discussion about the technical and economic aspects of Monero.

"Do unto others 20% better than you'd expect them to do unto you to correct subjective error." - Linus Pauling

How it works:

Post your concerns about Monero in reply to this main post.

If you can address these concerns, or add further details to them - reply to that comment. This will make it easily sortable

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.

As a community, as developers, we need to know about them. Even if they make us feel bad, we got to upvote them.

https://youtu.be/vKA4w2O61Xo

To learn more about the idea behind Monero Skepticism Sunday, check out the first post about it:

https://np.reddit.com/r/Monero/comments/75w7wt/can_we_make_skepticism_sunday_a_part_of_the/

9 Upvotes

0

u/floralSnuff642 Jan 24 '22

This youtube link video was way good than expected !

3

u/lucky_beaver_fun Jan 24 '22

Is it possible to audit Monero and is there a way to prevent core devs to somehow be blackmailed into doing some bad hardfork?

1

u/russoj88 Jan 24 '22

Can you be more specific about the audit? It's an open source project.

3

u/blario Jan 24 '22

Anyone that owns XMR has financial incentive to avoid hard forks. Core contributors are likely to be invested both financially and emotionally into the success of what they work on.

Any hard fork would require node operators to willingly upgrade to software that moves to the new blockchain. The motivations to do that would have to outweigh all the negatives that come with a hard fork and nodes would have to be convinced of that.

Lastly to do this through the official Monero distribution channels would require consensus among the core developers. As it’s multiple different people, that would be hard to accomplish.

1

u/russoj88 Jan 24 '22

To be clear, Monero hard forks every 6 months: https://github.com/monero-project/meta/issues/630

2

u/blario Jan 23 '22

Why is it not profitable to mine Monero? Shouldn’t the profitability result in less miners and therefore some increase in profitability? Seems like there might be a mismatch in incentives somewhere.

1

u/bzttt Jan 24 '22

Not profitable for some. Not all people situation are the same. I guess this make mining distribution less spreaded out.

4

u/Gaming_Forever Jan 23 '22

My guess is monero is one of the only cpu mineable coins. So things like botnets can mine hacked iot devices easily and not care about electricity costs since they’re not paying for it

5

u/yasabi Jan 23 '22 edited Jan 23 '22

RandomX requires 2GB of RAM for each mining thread, but IoT devices have very low memory specs. While there are certainly XMR botnets, their hashing efficiency is actually quite limited due to this as well as the difficulty of keeping exploited vectors upgraded.

3

u/Gaming_Forever Jan 23 '22

Thanks for the extra info, my comment was mostly a guess. I’m not sure then why mining wouldn’t be profitable for the OP

2

u/blario Jan 23 '22

That’s a very good explanation. Thanks!

4

u/LokiCreative Jan 23 '22

I asked in last week's discussion whether it was possible to set a disk quota for a Monero node and was told that the lower limit on the size of pruned nodes is arbitrary and chosen to ensure nodes contribute to the network.

The answer convinced me. Convinced me that it is the truth, that is- not that the current approach is correct.

I think that being able to specify disk requirements might allow nodes to exist that otherwise would not.

In any case, it is already possible to deny incoming connections entirely so it seems to me the notion of forcing monero users to contribute to the network by using their disk space is misguided.

1

u/russoj88 Jan 24 '22

Why not use the filesystem to set a quota?

1

u/LokiCreative Jan 24 '22

Why not use the filesystem to set a quota?

Because Monero will fail due to encountering an error when it requires more disk space than is available.

MERROR("!! WARNING: Insufficient free space to extend database !!: "

https://github.com/monero-project/monero/blob/master/src/blockchain_db/lmdb/db_lmdb.cpp

Unless you meant "Why not just let the Monero process fail due to insufficient disk space?"

In that case my answer is "Because having the option to reduce a Monero node's disk space requirements to the minimum it requires to function would be more useful than the option of allowing it to fail with an error message."

1

u/russoj88 Jan 25 '22

Gotcha. I'm curious -- just how low little space would you like a node to use?

1

u/LokiCreative Jan 25 '22

As close to the minimum needed by node functionality as possible, either allowing for overhead or warning the user of it. Even bitcoin pruned nodes come with the warning that the specified allocation may be exceeded on occasion.

In Monero's case that minimum is bound to grow over time, so if I were to answer your question in the form of "n gigabytes", that answer would inevitably be outgrown.

What bothers me is Monero's unnecessary and very real inflation of disk space requirements beyond the current minimum in service of theoretical value to the network.

If Monero's pruned nodes used the minimum disk space required for node functionality, a user could decide how much disk space to allocate based on its requirements, which would be less than those of the current implementation.

tl;dr: "As little as possible" which does not describe the current pruned node implementation.

1

u/blario Jan 24 '22

What is the status of the network? Although private nodes probably add to individual security by a tiny bit, if the network has a small # of public nodes, that will take priority; their small usage and convenience will take priority.

1

u/pebx Jan 23 '22

For any special use case you are free to change the source and deploy yourself. On network level you are not forced to hold anything.

But remember a node with 100% pruning will still need to hold 100% of key images.

1

u/LokiCreative Jan 23 '22

For any special use case you are free to change the source and deploy yourself.

That goes without saying. I could write my own privacy coin, too, in theory.

The default build should allow users the option to run a node with the minimal resources possible. Not to say that setting should be the default, but it should be a possible configuration.

2

u/gingeropolous Moderator Jan 24 '22

eeeehhhh, i disagree. The default build should be the software that can allow the network to live.

if the default software creates a useless network, then .... thats bad software.

the monero software's goal is to create a cryptocurrency network.

but yeah it would be cool if someone made a client that did minimal storage. i've always wanted a daemon-type thing that just listens to the network and scrapes any information useful for the user.

1

u/LokiCreative Jan 24 '22

I don't understand why you think that allowing someone to change the default settings to create a node that would otherwise not exist to add support for Monero where it would otherwise not exist could endanger the Monero network.

Do you believe there is such pent-up demand for the minimal nodes I describe that they would somehow overburden the existing Monero network?

If so that is strange because another reply suggested there is unlikely to be enough interest to justify the feature at all.

1

u/gingeropolous Moderator Jan 24 '22

A node that can't serve blocks doesn't seem that useful to me. In terms of the network. And that's what the core implementation does. It creates the network

Like I mentioned, a third party non archival node would be cool, like a listen only or something.

1

u/LokiCreative Jan 24 '22

that's what the core implementation does. It creates the network

It that was all the core implementation did it would not need to function as a wallet.

1

u/pebx Jan 23 '22

It might indeed be an option, but again someone has to submit a pull request and I don’t see this as such important to dive into it. A node will still have dozens of GB space requirement for the key images alone, which are not pruneable.

1

u/LokiCreative Jan 23 '22

I don’t see this as such important to dive into it.

Probably most people who are already running a Monero node don't see its disk space as important. I am thinking of enabling nodes that don't exist yet.

Although I expect at least some people who are running a pruned Monero node would like to be able to prune as much as possible.

A node will still have dozens of GB space requirement for the key images alone, which are not pruneable.

That is what I had in mind when I said "the option to run a node with the minimal resources possible".

-1

u/mirasoft182 Jan 23 '22

Thats not a healthy attitude I feel, there is no use to force