BoscoMurray



Offline



Activity: 450

Merit: 250







Sr. MemberActivity: 450Merit: 250 Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 09:34:19 PM #12921 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

Bitcoin mining is now a specialized and very risky industry, just like gold mining. Amateur miners are unlikely to make much money, and may even lose money. Bitcoin is much more than just mining, though! tised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertised sitesare not endorsedby the BitcoinForum.They maybe unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

EGStrategies



Offline



Activity: 80

Merit: 10







MemberActivity: 80Merit: 10 Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 09:39:16 PM #12923 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





binaryFate



Offline



Activity: 1456

Merit: 1001





Still wild and free







LegendaryActivity: 1456Merit: 1001Still wild and free Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 09:40:27 PM #12924



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.

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. Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's.

This makes Monero a better candidate to deserve the term "digital cash".

tacotime



Offline



Activity: 1484

Merit: 1004









LegendaryActivity: 1484Merit: 1004 Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 09:45:09 PM

Last edit: September 04, 2014, 10:12:45 PM by tacotime #12926



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. 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.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 202612Fork 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 202614Fork 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. Code: XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns

coins101



Offline



Activity: 1456

Merit: 1000









LegendaryActivity: 1456Merit: 1000 Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 09:53:11 PM #12927 Quote from: tacotime on September 04, 2014, 09:45:09 PM 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. 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.

coins101



Offline



Activity: 1456

Merit: 1000









LegendaryActivity: 1456Merit: 1000 Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 10:01:01 PM #12932 Quote from: fluffypony on September 04, 2014, 09:56:43 PM Quote from: coins101 on September 04, 2014, 09:53:11 PM 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.

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

findftp



Offline



Activity: 1022

Merit: 1000



Delusional crypto obsessionist







LegendaryActivity: 1022Merit: 1000Delusional crypto obsessionist Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 10:02:56 PM #12934 Quote from: fluffypony on September 04, 2014, 09:56:43 PM Quote from: coins101 on September 04, 2014, 09:53:11 PM 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,

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?





Quote 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

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

binaryFate



Offline



Activity: 1456

Merit: 1001





Still wild and free







LegendaryActivity: 1456Merit: 1001Still wild and free Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 10:06:27 PM

Last edit: September 04, 2014, 10:53:26 PM by binaryFate #12937 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.

Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's.

This makes Monero a better candidate to deserve the term "digital cash".

tacotime



Offline



Activity: 1484

Merit: 1004









LegendaryActivity: 1484Merit: 1004 Re: [XMR] Monero - A secure, private, untraceable cryptocurrency (mandatory upgrade) September 04, 2014, 10:08:42 PM #12938 Quote from: canonsburg on September 04, 2014, 10:01:18 PM 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). 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). Code: XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns