[XMR] Monero - A secure, private, untraceable cryptocurrency

[smooth]

Nice try from the attackers. Very fast answer, thanks to everyone who worked on the fix.
No harm done I believe.

No harm done ? Look at the net hash rate, it has halved...

So what, it had just doubled. Although that could have been the attacks. Any dev input on this?

No apparent connection

What was the timeframe of the attack?

The block that caused the network to fork was 913193

This must be why withdrawals are locked on bittrex, are they locked on all exchanges?

We notified exchanges as soon as possible. How they responded is a function of their own operations.

[smooth]

There was no fucking attack, it was just a bug!

Oh really? Where did the version 2 block come from?

Buggy code!

OK, which line?

[GingerAle]

NB: https://forum.getmonero.org/1/news-announcements-and-editorials/2452/monero-network-malicious-fork-from-block-913193-updates-and-resolution

From that post (which will be kept updated) -

Hi all,

The Monero network was (once again) the subject of an attack. Due to an error during the development of 0.9, Hydrogen Helix, we omitted a check that allowed for v2 blocks to be added to the network prior to the hard fork block height. Thus instead of forking on March 20, at block height 1009827, a v2 block was added to the network at block height 913193.

This is obviously problematic as not all services have updated to 0.9, and the bulk of the network hash rate is still on 0.8.x. We are preparing a point release to 0.9 that resolves this, but in the meantime only if you are running 0.9 you can do the following as a quick patch:

Shut down your Monero daemon
Grab a checkpoints.json file from getmonero: https://downloads.getmonero.org/checkpoints.json
Put the file in your bitmonero working directory (eg. ~/.bitmonero or C:\ProgramData\bitmonero)
Restart the daemon
As soon as the patched point release is out you can remove the checkpoints.json file, if you wish, and run the updated version. The checkpoints.json patch is a quick fix and does not prevent the attacker from replaying their attack at a later block.

After all this time on testnet I'm surprised to hear this, isn't there anyone on the team adept at at debugging and exploit testing?
Does anyone actually have a position that actively attack testnet before release? If not there are those out there that relish in this and do it for the accolades.
Not trying to be insulting hear as I know how hard you guys work on this but alpha/beta stages are there for a reason and really this is a simple expliot that should have been on the first error checks before release. I wish I it was 16 years ago, as I would have jumped on this just for the lulz.

Also are all the devs listed active? Did they all check this prior to release?  What is the list that signed off on this?

While I agree with your frustration, I think its continuously important to remember the big 0 in front of the version number of Monero (and hell, of bitcoin). Even at the active on-the-mainchain state, all of this software is beta. (of course, we're at 0.9 now... so, we gonna be seeing a lot more decimals put in? I don't know how versioning works. It always fails me when I write manuscripts).

And having been witness to all of the work that went into 0.9, shits gonna happen and your never going to reach perfection in the lab. And at some point you just push things so they *do* break.

Like I said, this kind of stuff can be frustrating and disappointing... but your other option is to wait for a big 1 to go in front of the version number, when the developers feel that their code is really ready for production.

For instance, if some alien entity came to us and said "hey, we don't use currency, but we kind of like how it helps your civilization work. How can we implement it?" We wouldn't try to "sell" them on our experimental new technology. We'd introduce them to our incredibly arcane (but functioning) central banking system and say "yeah we know it sucks, so we're working on version 2" and then show them cryptocurrencies.

[c789]

I don't know of any major software that doesn't need patches or updates. Look at Bitcoin or Windows for obvious examples. So just because there was an issue is not the big deal since that happens with 99% of software. The main point is that the devs jumped on it quickly, provided a patch, and are continuously providing updates...that should be the focus imho.

[boolberry]

I don't know of any major software that doesn't need patches or updates. Look at Bitcoin or Windows for obvious examples. So just because there was an issue is not the big deal since that happens with 99% of software. The main point is that the devs jumped on it quickly, provided a patch, and are continuously providing updates...that should be the focus imho.

Absolutely. If anything the community should have more trust (not less) in the Monero development team after this.

[binaryFate]

No harm done ? Look at the net hash rate, it has halved...

No apparent connection

Isn't the time window for the complexity small enough that the chain forking in two would have a visible impact on the computed hashrate?
If the miners work equally on each fork forever, the computed hashrate on each side is half of the initial one.

[smooth]

No harm done ? Look at the net hash rate, it has halved...

No apparent connection

Isn't the time window for the complexity small enough that the chain forking in two would have a visible impact on the computed hashrate?
If the miners work equally on each fork forever, the computed hashrate on each side is half of the initial one.

The quoting above is misleading. I was responding to:

So what, it had just doubled. Although that could have been the attacks. Any dev input on this?

There was no apparent connection to the increase in the hash rate earlier in the week.

[binaryFate]

The quoting above is misleading.

Sorry, I tried to clarify and messed up. 

[dEBRUYNE]

** IMPORTANT **

Everyone that is running 0.9 needs to mandatory upgrade to 0.9.1!!

https://github.com/monero-project/bitmonero/releases/tag/v0.9.1

Again, mandatory upgrade for everyone that is running 0.9

This resolves the issues caused by the malicious fork which is described here -> https://forum.getmonero.org/1/news-announcements-and-editorials/2452/monero-network-malicious-fork-from-block-913193-updates-and-resolution



EDIT: All pools listed here seem to be on the correct chain -> https://monerohash.com/#network

[digicoin]

Nice. Thanks. Upgraded

[medusa13]

thanks for the fix. my node was stuck too.
give it some time, network will recover fast.

no matter how good the devs are, bugs will happen. i can imagine how it happend.


if you forget something you forget something..if you are unlucky, it was something important.

also i think its important to mention one of the testing principles here: testing can only show the presence of bugs, but never proove their absence

so the right amount of testing is always hard to find.


but i agree, its a mistake in a place where there definetely should not be one.

[wpalczynski]

NB: https://forum.getmonero.org/1/news-announcements-and-editorials/2452/monero-network-malicious-fork-from-block-913193-updates-and-resolution

From that post (which will be kept updated) -

Hi all,

The Monero network was (once again) the subject of an attack. Due to an error during the development of 0.9, Hydrogen Helix, we omitted a check that allowed for v2 blocks to be added to the network prior to the hard fork block height. Thus instead of forking on March 20, at block height 1009827, a v2 block was added to the network at block height 913193.

This is obviously problematic as not all services have updated to 0.9, and the bulk of the network hash rate is still on 0.8.x. We are preparing a point release to 0.9 that resolves this, but in the meantime only if you are running 0.9 you can do the following as a quick patch:

Shut down your Monero daemon
Grab a checkpoints.json file from getmonero: https://downloads.getmonero.org/checkpoints.json
Put the file in your bitmonero working directory (eg. ~/.bitmonero or C:\ProgramData\bitmonero)
Restart the daemon
As soon as the patched point release is out you can remove the checkpoints.json file, if you wish, and run the updated version. The checkpoints.json patch is a quick fix and does not prevent the attacker from replaying their attack at a later block.

After all this time on testnet I'm surprised to hear this, isn't there anyone on the team adept at at debugging and exploit testing?
Does anyone actually have a position that actively attack testnet before release? If not there are those out there that relish in this and do it for the accolades.
Not trying to be insulting hear as I know how hard you guys work on this but alpha/beta stages are there for a reason and really this is a simple expliot that should have been on the first error checks before release. I wish I it was 16 years ago, as I would have jumped on this just for the lulz.

Also are all the devs listed active? Did they all check this prior to release?  What is the list that signed off on this?

If you can round up such people I am sure the dev team would be more than willing to accommodate their "testing/hacking" of testnet versions before release.  Do you know such volunteers that would do it for the accolades?

[fluffypony]

After all this time on testnet I'm surprised to hear this, isn't there anyone on the team adept at at debugging and exploit testing?
Does anyone actually have a position that actively attack testnet before release? If not there are those out there that relish in this and do it for the accolades.
Not trying to be insulting hear as I know how hard you guys work on this but alpha/beta stages are there for a reason and really this is a simple expliot that should have been on the first error checks before release. I wish I it was 16 years ago, as I would have jumped on this just for the lulz.

Also are all the devs listed active? Did they all check this prior to release?  What is the list that signed off on this?

We have a pretty comprehensive test suite, and this was an oversight in the tests - we missed adding one for this edge-case.

As always, this is an open-source project, feel free to submit a pull-request to expand the unit tests and core tests.

To get you started, here are all the unit tests: https://github.com/monero-project/bitmonero/tree/master/tests/unit_tests

And here are the hard fork unit tests we've created: https://github.com/monero-project/bitmonero/blob/master/tests/unit_tests/hardfork.cpp

I look forward to your first pull request, and thanks for offering to help!

[Drhiggins]

Thanks for the fast fix.  Updated here. 

[Hueristic]

...
If you can round up such people I am sure the dev team would be more than willing to accommodate their "testing/hacking" of testnet versions before release.  Do you know such volunteers that would do it for the accolades?

Possibly, I don't doubt a thread looking for a security position on the team would not go unfilled. Maybe we should ask BTCExpress?

...
I look forward to your first pull request, and thanks for offering to help!

Nice to see you back in the thread, been awhile. I know it's frustrating after all the work you guys put in but this edge case seems so basic. I'm guessing you guys don't have someone that's position is Project Manager? I can see how many people working on various parts of a project can allow these things to slip through but this is not a website we are talking about where people are buying tic-tacs. This has been in the works and delayed for quite awhile and the reason for that was because Of the testing going on, correct? AFA helping, well that's not possible, 20 years ago yes but not these days unfortunately. Could you answer my question on which devs are actively participating in the project currently?

BTW, does anyone have that link for voting on craptsy? I think it's about time we got added right?

Ohh and good job on the quick response guys.

[dEBRUYNE]

...
If you can round up such people I am sure the dev team would be more than willing to accommodate their "testing/hacking" of testnet versions before release.  Do you know such volunteers that would do it for the accolades?

Possibly, I don't doubt a thread looking for a security position on the team would not go unfilled. Maybe we should ask BTCExpress?

...
I look forward to your first pull request, and thanks for offering to help!

Nice to see you back in the thread, been awhile. I know it's frustrating after all the work you guys put in but this edge case seems so basic. I'm guessing you guys don't have someone that's position is Project Manager? I can see how many people working on various parts of a project can allow these things to slip through but this is not a website we are talking about where people are buying tic-tacs. This has been in the works and delayed for quite awhile and the reason for that was because Of the testing going on, correct? AFA helping, well that's not possible, 20 years ago yes but not these days unfortunately. Could you answer my question on which devs are actively participating in the project currently?

BTW, does anyone have that link for voting on craptsy? I think it's about time we got added right?

Ohh and good job on the quick response guys.

We got added a while ago lol -> https://www.cryptsy.com/markets/view/XMR_BTC

Also, as a general remark to your post, bear in mind that most people working on Monero are merely volunteers and got day jobs, and/or companies to run as well. Therefore, their time is mostly limited. On top of that, resources are kind of limited.

[smooth]

I think the question on who is active is valid.

In addition to the commits you see on github (mostly moneromooo, fluffypony, recently some from hyc, occ. others), other people regularly involved with testing, code reviews, debugging, and design decisions are myself, warptangent, tacotime, luigi, and othe, plus occ. others. Shen is actively developing the ringCT stuff (currently working on C++ code for it). NoodleDoodle does, well, whatever amazing things he feels like doing such as a the massive optimization rework that took months. He seems to prefer working independently. Wolf recently did some miner development but I think that is winding down. Finally, tewinget is doing or did some work on cleanup and documentation.

All are welcome.

EDIT: added tewinget's cleanup and documentation work.

[dEBRUYNE]

I think the question on who is active is valid.

In addition to the commits you see on github (mostly moneromooo, fluffypony, recently some from hyc, occ. others), other people regularly involved with testing, code reviews, debugging, and design decisions are myself, warptangent, tacotime, luigi, and othe, plus occ. others. Shen is actively developing the ringCT stuff (currently working on C++ code for it). NoodleDoodle does, well, whatever amazing things he feels like doing such as a the massive optimization rework that took months. He seems to prefer working independently. Wolf recently did some miner development but I think that is winding down.

All are welcome.

I agree it is a valid question, just posted a general remark. Wolf's miner development is nearly done as far as I know, his unofficial (not pushed on github yet) miner even outperforms that of claymore if I recall correctly. Also, I think tewinget is doing or did some work on cleanup and documentation.

[smooth]

Also, I think tewinget is doing or did some work on cleanup and documentation.

Thanks, forgot that one, but added it above.

[john-connor]

There was no fucking attack, it was just a bug!

Yes it was a bug that allowed the v2 block to enter the blockchain too soon. The code was exploited not attacked and this caused the network consensus to fail and split into several blockchains. There needn't be any debate on what happened. A bug was at fault not an attacker.