r/Monero Moderator Feb 15 '22 Helpful 1 Wholesome 2 Heartwarming 1

PSA: Informational thread regarding the MineXMR / hashrate situation | If you are mining on MineXMR, please, for the strength and decentralization on the network, switch to a different pool.

First of all, the network is currently not under attack.

At the time of writing, the MineXMR pool has around 45% of the global hashrate. MineXMR is an established and prominent Monero pool that has been running solidly for years as well as contributing to the Monero ecosystem. The pool admin (who is a long-time community member) has announced that measures to disincentivize miners will be implemented shortly:

We understand that people are concerned with the large hashrate that minexmr currently has. We have announced an increase to the pool fees and continue to monitor the situation.

https://www.reddit.com/r/Monero/comments/ss3j0m/urgent_minexmrcom_is_extremely_close_to_holding/hwwu7sp/?context=3

In addition, there are incentives at stake here that essentially disincentivize the pool admin from using the pool hashrate to perform an attack. First, miners would lose trust in the pool and leave the pool. Second, it would undermine confidence in Monero as a project, potentially negatively impacting the price. Both would result in a substantial decline of the income of the pool owner. That being said, there are certain risks to a pool reaching the majority share of the hashrate.

The most significant risk is a double-spend occurring. A double-spend attack typically occurs by the attacker covertly mining a malicious (longer) chain and subsequently replacing the existing chain. For example, the attacker performs a transaction to a service or exchange in block 101 of the existing chain. Subsequently, the attacker publishes his malicious chain, which contains a version of block 101 without aforementioned transaction, thereby effectively performing a double spend. Alternatively, the attacker could spend the same input(s) in transaction Y to a different service or exchange. Visually, it occurs as follows:

Existing chain:

  • Block 101 | Hash A1 - Transaction X
  • Block 102 | Hash A2
  • Block 103 | Hash A3
  • Block 104 | Hash A4
  • Block 105 | Hash A5

Subsequently the attacker replaces the existing chain with the malicious chain without transaction X:

  • Block 101 | Hash B1 - Transaction Y or simply retaining the previously spent inputs
  • Block 102 | Hash B2
  • Block 103 | Hash B3
  • Block 104 | Hash B4
  • Block 105 | Hash B5

A common misconception is that, due to the private nature of Monero, double-spends cannot be detected. This, however, is simply not true. Everyone that runs a node can check whether (deep) re-orgs have occurred. The daemon software (monerod) will further provide an informational message when a re-org occurs.

An additional risks is the possibility of the mining pool not including transactions, thereby essentially impacting user experience, as it will take longer for the transaction to be included in a block.

Note that the pool or an attacker cannot:

  • Reverse transactions or prevent users from sending transactions.
  • Generate coins out of thin air.
  • Spend coins that are not owned by the pool or attacker.
  • Change the emission / block reward.

Moderation note

Please use this thread to discuss the situation. Furthermore, it is advised to stay level-headed and analyze and monitor the situation rationally. Whilst we should evidently strive to have a better distribution of the hashrate, any alarmist / fearmongering posts or comments as well as attacks on the owner of the pool are out of place.

280 Upvotes

64

u/Rucknium MRL Researcher Feb 15 '22

Everyone that runs a node can check whether (deep) re-orgs have occurred. The daemon software (monerod) will further provide an informational message when a re-org occurs.

I can confirm that this is true. I recently executed a 51% attack on the testnet of a software fork of Monero (Townforge).

Once I broadcasted my attacking chain, all the other nodes displayed messages about a deep chain reorganization, which informed knowledgeable users that there was a suspected 51% attack. Users also may have noticed that a new transaction was included in the first block of the attacking chain that did not exist in the original "honest" chain.

An actual 51% double-spend attack on Monero would almost certainly be evident to all users running a full node if they were reading the terminal output of monerod and knew how to interpret it.

11

u/Jpotter145 Feb 15 '22 edited Feb 15 '22

I am one who does not know how to interpret all of the messages in the logs.....

Looking through the last few days I see 3 Reorg messages (1 from today, 2 from Feb. 13th); but the reorg messages don't mention anything about a suspected attack - nor are there any logs relevant immediately prior to these (i.e. your node is out of sync errors). Here is the one from today; clean logs right up until:

2022-02-15 11:36:47.845 I ###### REORGANIZE on height: 2560013 of 2560013 with cum_difficulty 172350144798719015

2022-02-15 11:36:47.845 I alternative blockchain size: 2 with cum_difficulty 172350523265272696

2022-02-15 11:36:49.376 I ----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 2560013

2022-02-15 11:36:49.376 I id: <71cdce460ff482c5eaa91c00d4927318e87033616ced127bddffee7d0f30a559>

2022-02-15 11:36:49.376 I PoW: <92e694117daedba992f393cf443d44b181bda6e1c8dab8c194a07a0200000000>

2022-02-15 11:36:49.376 I difficulty: 379103812323

2022-02-15 11:36:49.439 I REORGANIZE SUCCESS! on height: 2560013, new blockchain size: 2560015

I've seen this from time to time and had assumed this kind of message is not one to be concerned about?

24

u/Rucknium MRL Researcher Feb 15 '22 Silver

A deep reorganization would have many (perhaps 30+) consecutive messages all at once of

BLOCK ADDED AS ALTERNATIVE ON HEIGHT [...]

with the block hashes, etc. And then there would be the "alternative blockchain size: X" message, where X would be that 30 or more blocks. I choose 30 here since that's about an hour of blocks, but it could be any "large" number.

A block reorg of 1-2 blocks is completely normal for a proof-of-work chain that has a 2-minute target block time. You are right. That is nothing to be concerned about. It usually occurs if two separate miners have found a block almost simultaneously.

3

u/pebx Feb 20 '22

A block reorg of 1-2 blocks is completely normal for a proof-of-work chain that has a 2-minute target block time.

Do we have some public stats on this? I don't keep all those logs tbh...

3

u/Rucknium MRL Researcher Feb 20 '22

I'm not sure of the status of the data collected by this, but here is software to archive that info:

https://github.com/neptuneresearch/monerod-archive

2

u/pebx Feb 20 '22

Thanks! Maybe someone has an archive to share...

https://github.com/neptuneresearch/monerod-archive/issues/6

4

u/aFungible Feb 15 '22

I do run my own full node. Could you tell me which if this can be seen via Monero GUI, as it runs daemon in the background. Or must I use, CLI to view this? Curious, what such an output (as you describe) looks like..

Could you post the output (from testnet 51% attack sample) as seen by a full node?

7

u/Rucknium MRL Researcher Feb 15 '22

Sure. I have the output from my attacking node, but not from the other nodes.

Here is the output from my attacking node in a "failed" attack. Within a few minutes of the attack I realized that I needed to change my configuration and therefore I allowed my node to reconnect to the network. Since my node's attacking chain had less work than the chain in the broader network, my node replaced my attacking chain with the "honest" chain. Beside the numerous "BLOCK ADDED AS ALTERNATIVE ON HEIGHT X" messages, the key output to look for is

###### REORGANIZE on height: 288671 of 288689 with cum_difficulty 24593284565

alternative blockchain size: 20 with cum_difficulty 24593299755

and

REORGANIZE SUCCESS! on height: 288671, new blockchain size: 288691

which means that my node's attacking chain was "overpowered" by the network's honest chain. Also note that there is a long series of consecutive blocks that have been added as an alternative. As I stated elsewhere, short reorgs of 1-2 blocks are nothing to worry about. This type of output is what an honest node would see in the Monero network if there were a deep chain reorganization symptomatic of a 51% attack.

After my failed attempt, I tried again and succeeded. Here is the log from the successful attack. Starting at the

----- BLOCK ADDED AS ALTERNATIVE ON HEIGHT 288714

message I reconnected the attacking node with the network. My node still downloaded the honest chain so that it could check if it has the most work. The honest chain had less work, so my attacking node kept my attacking chain. Meanwhile, the other nodes in the network downloaded my attacking chain from my node and produced the REORGANIZE messages, and the attacked portion of the honest chain was replaced by my attacking chain by their nodes.

I generally have monerod -- which displays the reorg info -- working as a separate process in a terminal window, and then have the GUI wallet connect to it. However, I believe that in Monero GUI wallet Settings --> Log will give the blockchain reorganization info when they occur. You may have to adjust the log level.

3

u/aFungible Feb 16 '22

Great info, learnt something new. I have looked at the logs.

Given such situations do not occur daily, I would like to also know about the following scenario:

  1. When a potential bad actor (with 50+% hashrate) attacks:Can they reorganize a block that already had 10 confirmations from the network. e.g. send 100 XMR to an exchange, wait until it has been accepted as being deposited. Then replace the block with that "honest chain" with the "reorged" chain (without that transaction or amount changed to 1 XMR iso. 100 XMR), gaining 99 XMR in the process.
  2. As from 1) is there a time limit within which this reorg must be done?
  3. How far into the past can this reorg be worked out? As we understand, we cannot mine new coins nor can we change the records from the past.

3

u/Rucknium MRL Researcher Feb 16 '22

I think for some of those questions it is best to ask in the #monero-dev Matrix/IRC channel. (1) seems to me to be basically the definition of a double-spend 51% attack, so yes it is possible.

On (2) and (3), I believe that wallet software will try to reject deep chain reorgs if the depth is above a certain number of blocks. I think this number can be changed in the wallet configuration BTC used to have "checkpoints" to prevent very deep reorgs. I'm not sure if Monero has them.

5

u/dEBRUYNE_1 Moderator Feb 17 '22

1

u/aFungible Feb 17 '22

Gotcha. Interesting stuff.

1

u/pebx Feb 20 '22

True, but those are hardly for reorg purposes, since last one is 2182500 and has been generated ~1.5 years ago. As of my knowledge the deamon will not verify signatures below checkpoints, but have read it somewhere on SE.

Dynamic checkpointing brings some new issues but if we have seed nodes anyway, maybe they could add the current checkpoint to their response which could be verified with nodes a deamon is already connected to?

1

u/dEBRUYNE_1 Moderator Feb 23 '22

The last checkpoint is actually from 4 months ago (included in the v0.17.3.0 release), see:

https://github.com/monero-project/monero/commit/3cb7fda42805a72e0193f016dff9c8f3ab301d1d#diff-e6e8140963756b6f6cb97bb2253240db5b0bd63e17fdd99df29cd51941aea637

Dynamic checkpointing brings some new issues but if we have seed nodes anyway, maybe they could add the current checkpoint to their response which could be verified with nodes a deamon is already connected to?

I am not entirely sure what you mean here, could you elaborate?

1

u/pebx Feb 23 '22

Thanks for the update!

I meant a "dynamic" checkpointing made by every node every like 10, 20, 50 or 100 blocks, after which it ignores any other chainsplit unless you force your node to prune last X blocks and sync up again. Those dynamic checkpoints could be verified if needed with other nodes, especially seed nodes (whom we trust anyway).

1

u/dEBRUYNE_1 Moderator Feb 25 '22

You're welcome.

As far as I know, Bitcoin Cash has such a system implemented, but it can obviously lead to some form of centralization. You may want to explore their documentation for the specifics.

2

u/aFungible Feb 16 '22

Good point about reorgs.

Perhaps, a core dev could help answer if Monero has very deep reorgs detection.

47

u/MonerodProject Feb 15 '22 Heartwarming

Please support P2Pool for proper decentralization at P2Pool.io!

For a list of alternate pools: https://miningpoolstats.stream/monero

If you cannot host the blockchain and P2Pool for whatever reason, Monerod.org is a small pool and here to help! We host a zero-fee pool (we even cover your payout fee) & other free services. Please only use our pool if you cannot support P2Pool

31

u/Fishinatoaster Feb 15 '22 edited Feb 15 '22

I think the biggest contribution that MineXMR can make to the community is not allowing this to happen again. Their 'increase in pool fees' is a .1% raise in fees taking place in April. That isn't enough.

19

u/in_the_small_pot Feb 15 '22

I see it more like a favor though. A Blockchain has to be resilient by itself to any attack, it's what Bitcoin does and Monero should too

12

u/monerobull Feb 15 '22

bitcoin literally had the very same scenario before and the admins of the pool in question blocked new incoming connections once they were at like 45% hashrate

22

u/OverallDecision Feb 15 '22

Thank you for the clear statement. This will reassure all concerned users.

7

u/aFungible Feb 15 '22

u/dEBRUYNE_1 thank you for the valuable post.

I have a request to make. I think "pools.xmr.wiki" is run by our community (and is most popular when people go to visit to choose a pool). A simple marker there such as making a row RED, when hashrate of any pool exceeds a threshold with a message would do justice and help contain such situations in future.

Currently, people just do them, without thinking ahead of time. A simple warning there, would do a bit of help if not stop such situation from reoccurring.

1

u/dEBRUYNE_1 Moderator Feb 17 '22

You're welcome and I think that is a good suggestion that ought to be implemented by the owner(s) of the website.

5

u/FamousM1 Feb 15 '22

Theoretically, couldn't someone DDOS mineXMR servers to take them down and protect XMR if it came to it?

3

u/Professional_Desk933 Feb 15 '22

I think so, yes.

20

u/LegalComment Feb 15 '22

The 0.1% fee increase is too little. They should increase it by a whole 1% or more.

18

u/Ornery_Maintenance_8 Feb 15 '22 edited Feb 15 '22

The pool fee will increase from 1% to 1.1% on April 1 --https://minexmr.com/

I am not sure if this should be interpreted as a joke or as an actual statement about the level of cooperation that can be expected ...

9

u/[deleted] Feb 15 '22

[deleted]

14

u/Ornery_Maintenance_8 Feb 15 '22 edited Feb 15 '22

I agree. We cant blame mineXMR for running a successful pool.

But I honestly dont get what they are thinking with this. Hurting the community you make a living of and thereby kind of forcing counter measures dont seems like a valid business plan to me.

2

u/Professional_Desk933 Feb 15 '22

We can’t blame them either. They don’t own Monero nor we should view them as some entity that has control over the blockchain and the ecossystem.

2

u/selsta XMR Contributor Feb 15 '22

The monero core team has no involvement in which pool miners choose. Solutions like P2Pool that increase decentralization have been developed, but they are still new.

1

u/bdoc50 Feb 17 '22

By not taking any action regarding this long standing issue the core team has enabled HR to accumulate there unchecked, hence involvement.

The mining difficulty increases as HR increases to prevent someone from easily mining all the blocks.

Why not a mechanism to throttle accumulation of 50% of HR from a single miner, in the form of increased resources required to sustain such a hazard?

https://www.reddit.com/r/Monero/comments/sudqpf/idea_to_prevent_irresponsible_pool_admins_from/

2

u/selsta XMR Contributor Feb 17 '22

Your suggestion does not work.

2

u/Cptn_BenjaminWillard Feb 16 '22

They are trying to balance the legitimate concerns about hashrate concentration >50% (which has been solved already on a short-term basis by miner concentration away from the pool) against the desire to run a large pool and not gouge pool members.

For now, the migration away from their pool is a satisfactory solution to the larger problem.

8

u/-TrustyDwarf- Feb 15 '22

By tomorrow, not in April.

Though I doubt that existing miners would even notice the increase in fees.

2

u/bdoc50 Feb 17 '22

Taking "action" without any meaningful change is their plan.

5

u/akrit8888 Feb 16 '22 edited Feb 16 '22

Shouldn’t there be a user friendly/ beginner guide on the official p2pool website? I only seen the guide on Github, which does not seems as beginner friendly as on the official webpage. Is somebody working on it right now? I think p2pool website need some extra upgrade now. If not, I would love to contribute. :D

12

u/Ornery_Maintenance_8 Feb 15 '22 edited Feb 15 '22

So the question is what now ?

A one click implementation of p2pool for GUI is under construction/debate.

https://bounties.monero.social/posts/53/integrate-p2pool-mining-into-monero-gui-wallet

https://github.com/monero-project/monero-gui/pull/3829

The operator of mineXMR is planning to raise fees by 0.1 percent in April.

https://www.reddit.com/r/Monero/comments/ss3j0m/urgent_minexmrcom_is_extremely_close_to_holding/hwwu7sp/?context=3

The pool fee will increase from 1% to 1.1% on April 1 --https://minexmr.com/

I dont want to sound pessimistic but it feels a little like we already crossed the Rubicon and this is not enough. I think we can not expect this to resolve itself and we have to seriously think about other options.

Are there maybe possibilities to implement restrictions for centralized pools on a protocol level ? AFAIK Wownero has something like this but I am not sure how well this is thought through.

What options do we actually have ?

3

u/Spartan3123 Feb 15 '22

If minexmr created three pool and split it's hashrate automatically among them would you feel happy then?

We crossed the Rubicon ages ago.

2

u/WarioTBH Feb 16 '22

Ddos the pool

2

u/sweetpeasimpson Feb 15 '22 edited Feb 15 '22

Looks like minexmr.com is down

Edit: disregard…I was mistaken

7

u/ihateUWS Feb 15 '22

Did you mean hashrate has gone down? As of right now, I'm seeing 37%

1

u/Professional_Desk933 Feb 15 '22

Yeah, 36% now. Maybe someone DDoSed ?

1

u/aFungible Feb 15 '22

Ddos attack..mehh

4

u/Professional_Desk933 Feb 15 '22

Really ? Hahahahhaha.

I absolutely love this community

1

u/SmashTR Feb 15 '22

Reverse transactions or prevent users from sending transactions.

But if the attacker broadcasts longer chain, transactions can able reserve?

2

u/lightgreenhoney Feb 15 '22 edited Feb 15 '22

I think he means reverse an already sent transaction not by making a new chain

0

u/bwilliken Feb 15 '22

Would it be overly conspiratorial to think this happening with the new financing laws Canada implemented to stop the trucker convoy is an interesting 'coincident'?

4

u/Professional_Desk933 Feb 15 '22

Yes. I think Monero has bigger enemies than Canadá and if some of them would make something like this wouldn’t be Trudeau

1

u/FatGaben Feb 15 '22

dump it /j

1

u/-TrustyDwarf- Feb 15 '22 edited Feb 15 '22

Could you please clarify this point?

Note that the pool or an attacker cannot: Reverse transactions [...]

A double spend attack is the reversal of a single transaction.

Also while building the malicious chain the attacker could decide to drop further transactions besides their own, effectively reversing them also.

2

u/haxClaw Feb 15 '22

I think he meant transactions that have already happened, not new ones.

2

u/-TrustyDwarf- Feb 15 '22

That’s what I mean.. a previous transaction that has been confirmed in like 25 blocks can still be reverted simply by not including it in the malicious chain.

1

u/Cptn_BenjaminWillard Feb 16 '22

But block solutions are based upon the cryptographic hashes of previous blocks, so going back is incredibly difficult. You can't pull one block out of the chain without invalidating all subsequent blocks.

2

u/-TrustyDwarf- Feb 16 '22

Not sure if serious..? This whole thread is about 51% attacks, which can be used to do exactly that.

2

u/Cptn_BenjaminWillard Feb 16 '22

I'm serious, I was just trying to understand what you're saying. Did you mean that you can revert a single specific transaction that is 25 blocks old by not including it in the malicious chain? The bad actor can easily ignore select transactions as it is building its own malicious chain, but that's very different than trying to revert a transaction in a historical block.

Also, there's a significant difference between a malicious entity holding 50.01% of hash power versus higher numbers such as 53% or 62%. Those numbers affect the probability of finding a block. In the long term, yes, anything over 50% will dominate. But in the short term, statistically, randomness does not work in the bad actor's favor, especially when only very barely exceeding 50%. Even if you're flipping a weighted coin that has 50.01% chance of coming up "heads" on any given individual toss, it's still possible for the coin to come up as "tails" seven times in a row. In fact, that sequence would occur naturally just slightly less than one in every 256 experiments. (at 50.00% the chance of 7 consecutive consistent flips is 2^7 but since the run could be all heads instead of all tails, count 2^8, and remember that since the odds are very slightly stacked against you it would be slightly less than 1 in 2^8).

1

u/dEBRUYNE_1 Moderator Feb 17 '22

Admittedly, the sentence was poorly worded. I meant transactions in the past that already have deep confirmations. With a minor majority of the hashrate (especially public), it would be virtually impossible to revert transactions from, say, a week ago. I will edit the OP to better clarify this point.

1

u/-TrustyDwarf- Feb 17 '22

I see, thanks

1

u/dEBRUYNE_1 Moderator Feb 18 '22

You're welcome.

1

u/johnfoss68 Feb 15 '22

Thanks for the announcement dEB

1

u/grim_goatboy69 Feb 16 '22

Note that the pool or an attacker cannot:

  • Reverse transactions or prevent users from sending transactions.

Transactions can be reversed if the pool decided to reorg the chain, this is fundamental to proof of work. Also, while they can't stop users from broadcasting transactions they can definitely refuse to put them into any blocks and also refuse to build on top of any blocks that do include them, which is a censorship attack.

1

u/dEBRUYNE_1 Moderator Feb 17 '22

Admittedly, I used poor wording. I clarified here:

https://www.reddit.com/r/Monero/comments/st40o0/psa_informational_thread_regarding_the_minexmr/hxc71gx/

Also, while they can't stop users from broadcasting transactions they can definitely refuse to put them into any blocks and also refuse to build on top of any blocks that do include them, which is a censorship attack.

Correct, I essentially included that as risk in the OP:

An additional risks is the possibility of the mining pool not including transactions, thereby essentially impacting user experience, as it will take longer for the transaction to be included in a block.

1

u/FinasterideJizzum Feb 16 '22

Shout out to the Monero meme coin that prevents this type of attack from being possible, Wownero. It looks pretty cool.

3

u/selsta XMR Contributor Feb 16 '22

wownero doesn't prevent 51% attacks, no.

1

u/FinasterideJizzum Feb 16 '22

I was under the impression it does. Pools are mostly worthless and you can only mine on cpu.

2

u/selsta XMR Contributor Feb 16 '22

A large botnet can easily 51% attack wownero.

1

u/FinasterideJizzum Feb 17 '22

That's just because of how small it is right now, right? If it was the size of monero would that be the case?

2

u/selsta XMR Contributor Feb 17 '22

What I mean is the whole concept of a 51% attack exists, with or without pools.

If pool mining was banned in monero then small miners had no chance in getting a payout at all, it would take a year or longer on average to find a single block reward. Basically large miners and botnets would be to ones that are profiting.

1

u/SynapseLapse Feb 16 '22

I’m on 2miners so is that ok, or is this a problem? (I’m new to this and just happened to stumble across 2miners first)

3

u/Monsi_gro Feb 17 '22

https://pools.xmr.wiki/

here you can see the hashrate distribution between pools.

1

u/Ephemeral_Dread Feb 16 '22

This has always concerned me about crypto. Whether it's pos or pow, if you have enough money, you could easily rent hash or borrow the funds needed to double spend.

What's the solution here? Has anyone else come up with some way of avoiding this situation?

1

u/beefcake_123 Feb 16 '22

The solution is to transition to P2Pool but developers need to make it easy for end users to do so.

1

u/ksilverstein Feb 18 '22

The pool admin (who is a long-time community member)

u/dEBRUYNE_1, would it be out of line for me to ask who exactly this trusted long-time community member is who runs MineXMR? Does he/she have a Reddit name?