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

I've reed some of your posts, but I'll click on the ignore link for some time in order to filter non-useful posts - nothing personal. I could miss a lot while most of this thread posts are ignored users, but at least It'll take me reasonable time to read this thread. Anyone - feel free to update me in PM if you have a life changing event to share - I have some too.

I think its possible it didn't quite work right. As you point out it was elaborate and had a lot of parts. Maybe it malfunctioned a bit. That would fit with the stealthiness that doesn't really serve any other purpose other than to exploit something once it kicked in.

Or it wasn't (directly) economically motivated to attack an exchange, perhaps to simply attack the coin directly (especially if they underestimated us and didn't think we could fix it).

But we are still just guessing.

As for the fork it is completely dead. We will put in a checkpoint on the valid fork so no chance of ever bringing that one back to life.

As for other bugs/exploits, as I said a page or two back, we can never rule that out. All we can do is work to improve the code.

then this makes no rational sense....
They clearly really understand the codebase
This indicates they wrote it or they have studied it extensively, I cant see anyone just randomly finding this and making elaborate attack.

Is there some "cascade" issue that having this fork could trigger?
Like dominos, the fork is the first and that makes an opening for another edge case?

It just seems like 100x more effort for just making a temporary fork. Any chance that a many blocks could have been mined consecutively without actually mining due to this fork, directly or indirectly.

There just has to be a financial motive for this. only thing makes sense

James

How many blocks have your servers found since the attack, relative to an average of what they normally find?

Forking a coin is so stupid Lol. Why would anyone would waste their own money just to fork a coin? Makes no sense...but this is cryptoland, where people waste their entire life savings on stupid shit.

Nope - bear in mind that basically without any action from us the "bad" fork died after 35 minutes. It still exists, it's just stuck at block 202647 and won't proceed. This would have happened even if we hadn't noticed it, so there's little they could have done to have any long-lived attack.

The scope of this attack clearly makes it an organized effort. While it is possible that some lone guy is figuring out the flaw and how to take advantage of it, the fact we are needing more than one skillset and resources more indicates a team is involved.

Theoretically if you guys didnt notice the strange stuff on the blockchain and polo went on a fork, could they have just made many small withdraws over a week and drained the polo acct? The timeframe and resources required for this doesnt seem like some statment attack to cause a fork and go "ha ha", but where financial gain is involved.

If so, the list if suspects as being involved in this would be polo accts that were involved in accumulating recently (which I remember seeing talked about) and probably these were also trying to do the double spend while on the fork.

So, maybe the attack was against polo?

James

I remember when i registred on Poloniex everything also worked so slow, like it will never load. But then i realized it is only their home page such, when you move to exchange tab is was and it is all fine.

We had assumed they mined themselves but with your revelation one must ask the question of whether they somehow used a pool. We're investigating.

Congratulations to Monero devs and community and well done! I guess aside from all the stress, you've made a really great step forward today.

Really glad to see this statement. Based on the code I have seen, the only way to be 100% safe is to rewrite the critical functions in modern code, with clear variables and functions, and well documented with comments. The current core code is indeed horrible. That predates Monero of course. Current devs are doing the best they can with what they have inherited, but in the end the only way to really be safe is to rewrite the major pieces. That happened with BTC over the years as well.

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.