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

[findftp]

Just made my first ever XMR purchase - 5 minutes of XMR dev time for attack mitigation and security.

Thanks, devs!!

This kind of post is such good news.  Today made the coin, and community, incalculably stronger :-)

Well, I also just made my first purchase, but they are locked on BTER because I can't withdraw.
Very good first impression!

(1) Don't buy XMR on BTER, and

Too late, I just deposit some satoshis, did a market buy monero and went for withdrawal, basically a hit and run.

Can someone advise me on a place where I can do a hit and run which actually works? I don't want to have them locked up somewhere online.

Poloniex. I never hold funds on exchanges.

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

Am I under personal attack or something?

[1713968015]

1713968015

[1713968015]

1713968015

[1713968015]

1713968015

[tacotime]

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):

Code:

index 512 2a58f802202db09cbd1377630ae73becff1eaff52e8969980672496dc39a5f6f	1.999999999999	622
index 513 57ce3aab446d75726221c908a4bf6ac2f67485cab80a2e2bedfe5519cabd8848	1.999999999999	622

Fork 2 (chainradar, minergate):

Code:

index 512 d59297784bfea414885d710918c1b91bce0568550cd1538311dd3f2c71edf570	1.999999999999	622
index 513 d2d714c86291781bb86df24404754df7d9811025f659c34d3c67af3634b79da6	1.999999999999	622

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):

Code:

index 2 d59297784bfea414885d710918c1b91bce0568550cd1538311dd3f2c71edf570	1.999999999999	622
index 3 d2d714c86291781bb86df24404754df7d9811025f659c34d3c67af3634b79da6	1.999999999999	622

Fork 2 (chainradar, minergate):

Code:

index 2 2a58f802202db09cbd1377630ae73becff1eaff52e8969980672496dc39a5f6f	1.999999999999	622
index 3 57ce3aab446d75726221c908a4bf6ac2f67485cab80a2e2bedfe5519cabd8848	1.999999999999	622

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:

Code:

[P2P6]Block with id: <c29e3dc37d8da3e72e506e31a213a58771b24450144305bcba9e70fa4d6ea6fb>have at least one unknown transaction with id:\ <57ce3aab446d75726221c908a4bf6ac2f67485cab80a2e2bedfe5519cabd8848>
[P2P6]Removed transaction from blockchain history:<e0d8f60983f90bbf8030f166cfe151c9ee45fe2e5bdc19abb32d80bfeaf1b368>
[P2P6]Removed transaction from blockchain history:<227ec7670f47107c45a8d096510d385ffbd09aa59f47f60f98f915b079f48d8e>
[P2P6]Block verification failed, dropping connection

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.

[coins101]

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.

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.

[Xdragon]

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

[fluffypony]

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.

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.

[tacotime]

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.

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.

[TheKoziTwo]

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'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.

[coins101]

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.

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.

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.

[canonsburg]

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.

[findftp]

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.

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,

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?

and with the hike in fees to mitigate the previous attack I can only imagine that this would've cost them a pretty penny.

Same as the above

[Bittrex-Rami]

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

R.

[rdnkjdi]

...
Not surprising XMR gets attacked and will continue to be a target with such vitriol towards their own father, that made their birth possible.. constantly referring to them as scamdevs and acting as if XMR is the immaculate conception
...

[binaryFate]

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.

[tacotime]

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.

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).

[villabacho]

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!

[smooth]

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.

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.

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.

[bigj]

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.

[dga]

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.

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.

[coins101]

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.

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.

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.

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.

[tacotime]

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.

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.

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).