Bitcoin Forum
December 16, 2018, 09:42:35 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 ... 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 [651] 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 ... 2021 »
  Print  
Author Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency  (Read 4464482 times)
rdnkjdi
Legendary
*
Offline Offline

Activity: 1064
Merit: 1000


View Profile
September 04, 2014, 10:05:59 PM
 #13001

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

PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1544953355
Hero Member
*
Offline Offline

Posts: 1544953355

View Profile Personal Message (Offline)

Ignore
1544953355
Reply with quote  #2

1544953355
Report to moderator
binaryFate
Legendary
*
Offline Offline

Activity: 1372
Merit: 1001


Still wild and free


View Profile
September 04, 2014, 10:06:27 PM
 #13002

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
Legendary
*
Offline Offline

Activity: 1484
Merit: 1000



View Profile
September 04, 2014, 10:08:42 PM
 #13003

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

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
villabacho
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
September 04, 2014, 10:08:48 PM
 #13004

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
Legendary
*
Offline Offline

Activity: 1988
Merit: 1065



View Profile
September 04, 2014, 10:15:18 PM
 #13005

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
Full Member
***
Offline Offline

Activity: 198
Merit: 100



View Profile
September 04, 2014, 10:16:24 PM
 #13006

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
Hero Member
*****
Offline Offline

Activity: 737
Merit: 511


View Profile WWW
September 04, 2014, 10:19:32 PM
 #13007

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
Legendary
*
Offline Offline

Activity: 1456
Merit: 1000



View Profile
September 04, 2014, 10:19:37 PM
 #13008

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
Legendary
*
Offline Offline

Activity: 1484
Merit: 1000



View Profile
September 04, 2014, 10:20:52 PM
 #13009

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

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
smooth
Legendary
*
Offline Offline

Activity: 1988
Merit: 1065



View Profile
September 04, 2014, 10:21:28 PM
 #13010

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.

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.



TheKoziTwo
Legendary
*
Offline Offline

Activity: 1547
Merit: 1001



View Profile
September 04, 2014, 10:21:39 PM
 #13011

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.



Here:
Quote
Donations for general development

XMR:
Code:
46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em
viewkey: e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703

BTC:
Code:
1FhnVJi2V1k4MqXm2nHoEbY5LV7FPai7bb

Monero Community Hall of Fame
It's also in first post.

coins101
Legendary
*
Offline Offline

Activity: 1456
Merit: 1000



View Profile
September 04, 2014, 10:36:53 PM
 #13012

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

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?

Atrides
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


Admin of DwarfPool.com


View Profile WWW
September 04, 2014, 10:37:03 PM
 #13013

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)
Code:
202614,1237676319,'ed4eea6109a1b662cf4a3bb372ed4bdee588160b0ac371c2ad78c5e603b8f2ac',1409805725

Moria:
Code:
202614,1237676319,'c29e3dc37d8da3e72e506e31a213a58771b24450144305bcba9e70fa4d6ea6fb',1409804768

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?


DwarfPool Quality you can trust! http://DwarfPool.com Reliable Monero, Zcash and ETH Pool Monero Proxy
Anonymous pool with failover servers and PPS, Profit Calculator and Price chart: [XMR][ETH][ZEC]... Support thread
MoneroClub - free P2P Exchange Platform www.MoneroClub.com
Mumbles
Newbie
*
Offline Offline

Activity: 50
Merit: 0


View Profile
September 04, 2014, 10:43:14 PM
 #13014

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.


Further we will be restructuring, refactoring, and/or replacing some of the code in order to further increase its robustness and trustworthiness (removing obfuscation for example).


Rias
Sr. Member
****
Offline Offline

Activity: 373
Merit: 250


View Profile
September 04, 2014, 10:52:40 PM
 #13015

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.
smooth
Legendary
*
Offline Offline

Activity: 1988
Merit: 1065



View Profile
September 04, 2014, 10:55:30 PM
 #13016

And who found blocks 202612?

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.

Febo
Legendary
*
Offline Offline

Activity: 1624
Merit: 1065



View Profile
September 04, 2014, 11:03:23 PM
 #13017

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

Am I under personal attack or something? Smiley


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.

.BitDice.               ▄▄███▄▄
           ▄▄██▀▀ ▄ ▀▀██▄▄
      ▄▄█ ▀▀  ▄▄█████▄▄  ▀▀ █▄▄
  ▄▄██▀▀     ▀▀ █████ ▀▀     ▀▀██▄▄
██▀▀ ▄▄██▀      ▀███▀      ▀██▄▄ ▀▀██
██  ████▄▄       ███       ▄▄████  ██
██  █▀▀████▄▄  ▄█████▄  ▄▄████▀▀█  ██
██  ▀     ▀▀▀███████████▀▀▀     ▀  ██
             ███████████
██  ▄     ▄▄▄███████████▄▄▄     ▄  ██
██  █▄▄████▀▀  ▀█████▀  ▀▀████▄▄█  ██
██  ████▀▀       ███       ▀▀████  ██
██▄▄ ▀▀██▄      ▄███▄      ▄██▀▀ ▄▄██
  ▀▀██▄▄     ▄▄ █████ ▄▄     ▄▄██▀▀
      ▀▀█ ▄▄  ▀▀█████▀▀  ▄▄ █▀▀
           ▀▀██▄▄ ▀ ▄▄██▀▀
               ▀▀███▀▀
        ▄▄███████▄▄
     ▄███████████████▄
    ████▀▀       ▀▀████
   ████▀           ▀████
   ████             ████
   ████ ▄▄▄▄▄▄▄▄▄▄▄ ████
▄█████████████████████████▄
██████████▀▀▀▀▀▀▀██████████
████                   ████
████                   ████
████                   ████
████                   ████
████                   ████
████▄                 ▄████
████████▄▄▄     ▄▄▄████████
  ▀▀▀█████████████████▀▀▀
        ▀▀▀█████▀▀▀
▄▄████████████████████████████████▄▄
██████████████████████████████████████
█████                            █████
█████                            █████
█████                            █████
█████                            █████
█████                     ▄▄▄▄▄▄▄▄▄▄
█████                   ▄█▀▀▀▀▀▀▀▀▀▀█▄
█████                   ██          ██
█████                   ██          ██
█████                   ██          ██
██████████████████▀▀███ ██          ██
 ████████████████▄  ▄██ ██          ██
   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ██          ██
             ██████████ ██          ██
           ▄███████████ ██████▀▀██████
          █████████████  ▀████▄▄████▀
[/]
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
September 04, 2014, 11:05:12 PM
 #13018

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
fluffypony
Donator
Legendary
*
Offline Offline

Activity: 1260
Merit: 1019


GetMonero.org / MyMonero.com


View Profile WWW
September 04, 2014, 11:12:54 PM
 #13019

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

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.

darkota
Hero Member
*****
Offline Offline

Activity: 770
Merit: 500


View Profile
September 04, 2014, 11:19:38 PM
 #13020

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.



Pages: « 1 ... 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 [651] 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 ... 2021 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!