Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1480. (Read 4670622 times)

As many others have done already, I also want to thank the devs (and everyone else who contributed) for the prompt and professional reaction on this attack. This makes me very confident for the future of Monero. I've read the comment from Peter Todd about the code quality, and although I have to admit that he has a valid point (being a C and C++ programmer myself), I value the skill of the dev team higher than the current state in terms of code quality. The recent events and all the other activity that you can see on github demonstrate that the team behind Monero is up to the task, and I'm sure they'll improve code quality over time. Sure, that'll be a long process, but today they showed again that they can be damn fast in fixing bugs even though its not their own code originally. I've a lot of respect for that!

That's the thing about this, they didn't actually have to be synchronous for the second blocks and the first blocks they generated the two variants of for free because they just edited the content without changing the block header hash (then submitted the variants to different subsets of peers).

Once the first second block was submitted, the network immediately forked, so at that point they could make the other one at leisure (and give it the same timestamp if they wanted).

This is impressive indeed. Generating 2 blocks roughly at the same time (the 202614 ones), only 2 blocks after the initial exploit (202612)... means they had an enormous amount of hash power.

EDIT: Actually they didn't need to mine the blocks 202612 (just send tx), so that is already much more feasible.

This episode should put the testnet functionality slightly higher on the todo list... Some tests with high numbers of tx per block would have been useful here.

Ok, just caught up.  The analysis makes sense and we are comfortable enough to bring XMR back online.  Crisis averted, happy trading!

R.

No monetary gain for the attacker?
What if they consider monero to be a potential bitcoin killer and they have vast interest in the succes of bitcoin?



Same as the above

So how did the attacker know both how to exploit AND have enough firepower to submit consecutive blocks?

Must be some mighty sophisticated malicious agents.

So they were testing the dev team?

If that is the case, the attack has simply proved to be an advert for the devs.

Congratulations, XMR community.

I'm very impressed by how you guys dealt with this, from notifying the exchanges to solving the attack. Will be making a donation today. Thanks for your great work.

The intention was to fork the blockchain, and possibly to cause a doublespend at poloniex as busoni had noted several suspicious deposits earlier in the day.

The fork was as intentional as it could possibly be -- everything going into this was very, very precise.

The fork was the intention and the net-effect. They would have had to mine two of those blocks in parallel and dump them both on the network. It's such a bizarre, unknown, unidentified edge-case that I can't imagine someone stumbling across this AND figuring out how to exploit it (and to what end??). There's no monetary gain to the attacker, and with the hike in fees to mitigate the previous attack I can only imagine that this would've cost them a pretty penny.

Is it OK to use latest wallet?  Do we have to update something?

But the fork, was that the purpose of the attack or accidental? Was he relying on the fact that it would be a while before anyone noticed?

Sounds to me as though mayhem was the intention.

So, I think figured out today how the attack worked.

Throughout the day, the chain was spammed with "mimic" pool payout transactions. This was to enlarge the median blocksize.

Then, when the block size hit the required size for the attack, the merkle tree hashing code was overflowed by including >511 tx (these were tiny tx with one input and no outputs) followed by two unique transactions with inputs and outputs. The last two transaction hashes in the tx merkle tree (512, 513) could be replaced with anything so long as they were valid tx hashes, as they didn't actually factor into the block hash. This was due to a bug in tree-hash.c. This was block 202612.

The net effect of this was that you could swap in any tx into the block at positions 512 and 513 so long as they were the same size and were valid.

Here's the interesting part: When the attacker mined 202612, he transmitted two different blocks to the network, both of which had valid block headers, and both of which contained different transactions in index 512 and 513.

Block 202612
Fork 1 (monerochain):

Fork 2 (chainradar, minergate):

Note that both of these above blocks have the same header hash, because the merkle tree code simply ignored including these tx into the tree. If it had, the block header hash would have been different.

So, now half the network had one block, and half had the other, but they both thought they were valid and exactly the same even though they weren't.

Now, here's how the attacker forked the network. Two blocks later, at height 202614, the attacker generated and submitted two new blocks. These blocks contained the transactions below:

Block 202614
Fork 1 (monerochain):

Fork 2 (chainradar, minergate):

Noticed that these two new blocks both contain tx which the other chain already had -- at this point the network forked, because for each network one of these blocks would be invalid because it contained a doublespend of transactions that were already included.

Here's some output from a daemon on the forked network (fork 1, monerochain), from exactly when it hit the fork point:

This has been the most elaborate attack on a cryptocurrency I've ever seen -- it required incredible coordination and took great lengths to hide itself from being see from casual users of the network until it was too late. Of course, we were watching and could tell something was up, so we caught the fork immediately and were able to protect our users by notifying them and the exchanges of it. Still, I'm frankly amazed at the lengths the attackers went to to conduct this attack, and the complexity of it.

I cannot create an account.
The website is stuck at:
https://poloniex.com/signup_validate.php

Am I under personal attack or something?

Kudos to all those who were involved in the quick investigation&fix, core team of course but also the few programmers revolving around. Thank you guys, really!

Kudos to the whole XMR community for the way it reacted, especially considering the amount of trolling against us. In cryptoland, we look like one of the few wise grown-up adults communities in a world of stupid children.

I find it extremely funny to think that the suckers behind the attack were trying to obtain a financial gain from it, and at this point it seems to be a *complete* fail.

Seems polo is trading, huge volumes over last hour back to the low mid 400s after taking a dive.

Wonder why Bittrex is still down?

O well, been working all day and didn't worry once as a holder of XMR here. I did expect to lose more liq. value though, the market looks really strong. I'm not thinking about the short term either way with XMR but I'd be lying to say I'm not happy to see the market response on polo after trading resumed.

Great job monero dev(s) with the way you handled this

XMR deposit is disabled 因技术维护，虚拟币充值暂停，感谢您谅解和支持。

translated:
XMR deposit is disabled due to technical maintenance, the virtual currency recharge pause, thank you for your understanding and support.

I'm trying to withdraw 2 digits of XMR.

I downloaded the Windows x64 blockchain yesterday and have synced up to 202656. Stuck there for hours now so I must be on the wrong chain.

I downloaded it again this evening, but the file size suggests to me it's the same as yesterdays and I don't want to end up in the same position again.

Could the OP be updated with the correct Windows blockchain ASAP please! Ta

Poloniex. I never hold funds on exchanges.