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

If I recall correctly, this was not approved by the devs.

I am trying to sync my 12-day old windows x64 blockchain. It ended up on the wrong fork the first time but I'm trying again. If it syncs properly I'll upload it for everyone.

That one's a month old. You still have to sync the rest and you might still end up on the wrong fork, I did.
Best to wait for an official update from the devs.

Try this for windows

http://monero.rs/blockchain/windows64/blockchain.bin

Same here
And I'm on windows... can I use linux blockchain?!

Download this blockchain

https://bitcointalksearch.org/topic/m.8668429

I'm have a problem with sync.

Seem to be stuck on 202656 so wrong fork i guess.

I have deleted the 'blockchain.bin', downloaded one from 30 odd days ago (from the OP of this topic) and allowed everything to catch up. However, it is still stuck on 202656.

Any suggestions would be appreciated!

Do we (miners) need to download new daemon&wallet ?

https://mega.co.nz/#!rbggbrgbrgbrgbLINKTRASHEDBrbrgbrgbrgbgrjw win64 blockchain #203437 block

Both users are relative small with 4 and 8 khs. First user started 30th Aug and other 1th Sep. And they are on the pool still.
I don't think they belongs to attacker. They were random blocks-hashes.

Attacker just send prepared bad TXs.

I think we are all waiting patiently.  The devs need some sleep 

Where is a current windows blockchain? The one in the op is over a month old.

I can't successly compile wallet&bitmonerod  from github source code now.
following is information by make :

anyone had encountered that and  found  a solution?
who can give some help for me?

Fee is just (inputs - outputs). So if there are no outputs the entire input becomes a fee. That was used for the tiny transactions in the overflow block too.

They entered the mempool a very long time ago, about 11 hours ago, a while after the initial attack.

Below is a current mempool state:

The 66 XMR fee tx is nowhere to be seen, so no idea where that is even coming from.

It looks like those weird "45" tx are being invalidated because the inputs are considered invalid:

In case anyone is wondering, I dont believe the attacker would require a massive amount of hash power to achieve this attack or a relatively large amount of XMR, but there are some other interesting things to consider about how they did it:

It looks like they prepared for the attack from around 1200 blocks before, injecting their large txes with the 0.1XMR fee each time, so even if there was one tx per block that's still only 120XMR expended. Suggests they were running a system with some code to automate the generation of those txes and send them into the network via a normal bitmonerod.

Tacotime's analysis points out they must have mined the naughty block 202612 on their own custom daemon because it includes tiny tx fees (if they mined it themselves they would have got the fees back so I guess there was another reason for keeping the fee so low), but once they had the blockchain "prepared" they would only need 0.5MH/s on their own pool to have a 50/50 chance of mining their next block within an hour. We've already figured out that they have some code for crafting custom txes, so it probably isnt tricky for them to have customised a bitmonerod to include their specially crafted tx set when one of their miners finds a block. Must be a reason why they generated two slightly different blocks tho?

The block which then causes the fork, 202614 was apparently mined on Dwarfpool (both of them), so they werent using their pool for that. They dont really need to though, as this time they just wanted to inject their duplicate txes, so they can use their custom tx generator and send them out to the network that way.


Getting hypothetical now, I'm wondering if their usage of Dwarfpool was deliberate - I notice that they have two mining servers in different parts of the world so perhaps they realised they could leverage that and Dwarfpool's hashpower. First they transmit one version of block 202612 to DwarfEU and the other version to DwarfUSA - the block header matches so the controlling server accepts everything, but the individual daemons are now on different forks without realising it. Then by sending their custom txes to the Dwarf servers they know it will only take a few minutes to cause a fork. Havent yet figured out how that would result in a major fork though, rather than just causing a small portion of the network to diverge.

Assuming I havent made any major errors in the above (pls correct me if so), then its certainly a clever attack - from finding the flaw in the code to execution, but by no means beyond the capability of a single individual or small group who thought they could gain from it.

I'm too tired to compute time differences now, when did they enter the mempool (relative to the timeline of the attack)? Was it around peak crisis management, at the darkest hour?

The 66 XMR fee tx is the wildcard. What's inside? No outputs? Why is it so 151byte-small and why is it in the mempool?

Could you create a chain > amend some blocks to steal small amounts from a number (hundreds or targeted) of wallets > join one or several pools to hide among others > increase your hash rate > cause a fork > use your increased hash to force everyone to join your rogue chain?

Non-standard denominations are allowed. They are spending from the two overflow attack transactions in block 202612.