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

So, I have also researched this fork from pool side.

I think the attacker doesn't need so much power because they used power from existing pools.

I have found that 202614 on both forks were found by my servers:

Erebor1: (height,difficulty,bhash,timesec)

Moria:

And time difference is ca. 15 minutes, so therefore forks happens before. After that Erebor1 was on wrong chain some time.

But how he has organized bad TX's I don't known. And who found blocks 202612?

How was he able to mine the next block?

Is Smooth correct, that there is another possible and non-obvious purpose here? I don't want to start a conspiracy chain of discussion, but you have just added another dimension which, in the context of the sophistication of the attack, might suggest something else is going on?

Here:
It's also in first post.

In some sense we can only speculate at the intent.

But more broadly the intent was clearly for no one to notice right away. The attacker spammed slowly, and made the spams look like pool payouts. This had the effect of slowly increasing the block size and not filling up the mempool which would have delayed other transactions and caused alarm (as with the previous spam attack).

If it were purely to cause a chain fork -- and do nothing else -- there was no need for stealth. It could have done more crudely and probably more quickly. So very likely the intent was to cause far more damage in some unknown manner, but that was prevented since we detected the attack immediately and alerted the community.

Correct.

edit: Though I will note that these tx had non-standard fees of 0.000000000001, which no mining node on the network would have included using any version of the reference code, so the attacker did for some reason mine the second block on both forks (to what end I'm not sure, maybe just to impress us).

Sorry, I didn't explain myself correctly.

I didn't mean to suggest that the fork could have been accidental. I was wondering if the intention was to test out double spending in order to keep doing it, but he was caught out by an accidental fork.

I think the analysis is right, this was intended to create a fork and cause as much mayhem as possible.

If I'm reading tacotime's analysis correctly, it's not clear that the *attacker* would have had to solve the second block(s) after finding the first one.  To wit:

If half the network accepted the block with TX_1 and TX_2 (block A, accepted by set 1),  and the other half had accepted TX_3 and TX_4 (block B, accepted by set 2),

then couldn't the attacker simply generate the corresponding *transactions*, and let some other miner(s) generate blocks that contained them?  The fork happened as soon as the nodes in the network had accepted conflicting sets of transactions.  Block A would not be accepted by nodes in set 2, because they had a double-spend and so those nodes would keep trying to mine their own block.  Those nodes in set 2 would only include TX_3 and TX_4 in a block they tried to mine, because TX_1 and TX_2 are invalid.

Thus, the normal process of mining would automatically finish things up once the evil block and the four subsequent transactions had been introduced.

If that's the case, the firepower is easy - it's just money on Amazon, or your favorite botnet.  It takes about 560 nodes for an hour to find a block.  That's about $40 on AWS.

The tricky part is the coding required to execute this attack, and whatever prep work they had to do to get the median tx size large enough.  And finding the bug in the first place.  Unlike the earlier attacks with high mixin counts which could be implemented by hitting "up arrow" a lot, this one's pretty sophisticated.

Likewise from my side: My big thank you goes to all the Monero devs!

For the sake of simplicity, please post your XMR/BTC/XYZ adresses here, so everyone can quickly send you some goodies.

I think it was mentioned in one tacotime's earlier posts that the setup for this started at least 4 days earlier. There is no question that it was intentional, well-planned, and carefully executed.

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.