Author

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

sr. member
Activity: 308
Merit: 250
Where is a current windows blockchain? The one in the op is over a month old.
jr. member
Activity: 38
Merit: 14



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

Quote

rio@i2f14fd0fZ0a40Z:~/bitmonero/bitmonero$ git pull
Already up-to-date.
rio@i2f14fd0fZ0a40Z:~/bitmonero/bitmonero$ make
mkdir -p build/release
cd build/release && cmake -D CMAKE_BUILD_TYPE=Release ../..
-- Found Git: /usr/bin/git
-- Configuring done
-- Generating done
-- Build files have been written to: /home/rio/bitmonero/bitmonero/build/release
cd build/release && make
make[1]: Entering directory `/home/rio/bitmonero/bitmonero/build/release'
make[2]: Entering directory `/home/rio/bitmonero/bitmonero/build/release'
make[3]: Entering directory `/home/rio/bitmonero/bitmonero/build/release'
make[3]: Leaving directory `/home/rio/bitmonero/bitmonero/build/release'
make[3]: Entering directory `/home/rio/bitmonero/bitmonero/build/release'
fatal: No names found, cannot describe anything.
CMake Warning at src/version.cmake:3 (message):
  Cannot determine current revision.  Make sure that you are building either
  from a Git working tree or from a source archive.


make[3]: Leaving directory `/home/rio/bitmonero/bitmonero/build/release'
[  0%] Built target version
make[3]: Entering directory `/home/rio/bitmonero/bitmonero/build/release'
make[3]: Leaving directory `/home/rio/bitmonero/bitmonero/build/release'
make[3]: Entering directory `/home/rio/bitmonero/bitmonero/build/release'
[  1%] Building C object external/miniupnpc/CMakeFiles/upnpc-static.dir/igd_desc_parse.c.o
cc1: error: -Werror=maybe-uninitialized: no option -Wmaybe-uninitialized
cc1: error: unrecognized command line option ?std=c11?
make[3]: *** [external/miniupnpc/CMakeFiles/upnpc-static.dir/igd_desc_parse.c.o] Error 1
make[3]: Leaving directory `/home/rio/bitmonero/bitmonero/build/release'
make[2]: *** [external/miniupnpc/CMakeFiles/upnpc-static.dir/all] Error 2
make[2]: Leaving directory `/home/rio/bitmonero/bitmonero/build/release'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/rio/bitmonero/bitmonero/build/release'
make: *** [build-release] Error 2
rio@i2f14fd0fZ0a40Z:~/bitmonero/bitmonero$


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


hero member
Activity: 529
Merit: 505
I'm on drugs, what's your excuse?
Together we survive   


 
One dies both Die


Jon  Cool
legendary
Activity: 2968
Merit: 1198
The 66 XMR fee tx is nowhere to be seen, so no idea where that is even coming from.

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.

legendary
Activity: 1484
Merit: 1005
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?

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:
Code:
2014-Sep-05 01:10:17.257000 Pool state:
id:
blob_size: 2506
fee: 0.100000000000
kept_by_block: T
max_used_block_height: 202620
max_used_block_id: <0000000000000000000000000000000000000000000000000000000000000000>
last_failed_height: 203416
last_failed_id:
id: <9c0e2dd3adbb08e047567042ca0465d0979ecd2c00bb437cddfa83c3d121d3c5>
blob_size: 2079
fee: 0.100000000000
kept_by_block: T
max_used_block_height: 202617
max_used_block_id: <0000000000000000000000000000000000000000000000000000000000000000>
last_failed_height: 203126
last_failed_id: <87115ebd63abfbc812d762159dfc374c704acde531d429431915ec1616762289>
id: <38f731e69b37850efd27fcd281e3890ac7801e35f73c69f24a6099cf8f6ae152>
blob_size: 24057
fee: 0.100000000000
kept_by_block: T
max_used_block_height: 0
max_used_block_id: <0000000000000000000000000000000000000000000000000000000000000000>
last_failed_height: 0
last_failed_id: <0000000000000000000000000000000000000000000000000000000000000000>
id: <8ce209d697018eb4bc964c52f7e970059fe06531d009b950d9e8056f05cda934>
blob_size: 1393
fee: 0.005831060000
kept_by_block: T
max_used_block_height: 202729
max_used_block_id: <0000000000000000000000000000000000000000000000000000000000000000>
last_failed_height: 202975
last_failed_id: <1fd43b901c3970dce25b1c0930130af6951ea2d5d9a0fe0e4095d1cb0c2bf219>
id:
blob_size: 1942
fee: 0.100000000000
kept_by_block: T
max_used_block_height: 0
max_used_block_id: <0000000000000000000000000000000000000000000000000000000000000000>
last_failed_height: 202798
last_failed_id:
id:
blob_size: 1942
fee: 0.100000000000
kept_by_block: T
max_used_block_height: 0
max_used_block_id: <0000000000000000000000000000000000000000000000000000000000000000>
last_failed_height: 202798
last_failed_id:

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:
Code:
[P2P6]Transaction verification impossible:
sr. member
Activity: 252
Merit: 250
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.
sr. member
Activity: 263
Merit: 250
Are the first two legal? They use nonstrandard denomination. Maybe that is the attack? Unmixable txo?

Is there any meaningful raw data in the corrupted tx? I don't know any way to access it.

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

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?
legendary
Activity: 1456
Merit: 1000
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?
legendary
Activity: 1484
Merit: 1005
Are the first two legal? They use nonstrandard denomination. Maybe that is the attack? Unmixable txo?

Is there any meaningful raw data in the corrupted tx? I don't know any way to access it.

Non-standard denominations are allowed. They are spending from the two overflow attack transactions in block 202612.
sr. member
Activity: 263
Merit: 250
Two tx from the attackers are now present in the mempool and are waiting to enter a block. They spend the outputs from the overflow tx.

http://chainradar.com/xmr/transaction/e3b94625d8eb5513dbc98b599a86a3b8622a23dce0124334f5b9982b656c59c5
http://chainradar.com/xmr/transaction/f7a2c4d0c4ccbfae37d550253c5f032156d9e8d0897d76137e26ea5fa8a92f44

Additionally, there is a tx in the mempool that is corrupt for 66 XMR.

http://chainradar.com/xmr/txpool

No clue what the intention of these are.

Are the first two legal? They use nonstrandard denomination. Maybe that is the attack? Unmixable txo?

Is there any meaningful raw data in the corrupted tx? I don't know any way to access it.
hero member
Activity: 529
Merit: 505
I'm on drugs, what's your excuse?
I suspect the NSA or other government agency.......crypto is heading into worm hole and if it makes there going to have hell of a time tracing the wealth. Attack the biggest cyrptonote first try and start war between it and BBR. This would not be the first time that this tactic has been used  Divide and Conquer. There has even been a post over at BBR warning of potential regulatory intervention if James rolls out Supernet IPO on Poloniex. Rather than Fud each other, its time to work together. If we can't do it then they win. I don't care who started this attack on XMR all I can say to them is FUCK YOU. People bitching about code this code that
all code is a work in progress if it isn't then its dead or perfect and there isn't much perfection in the world.

Jon  Angry
hero member
Activity: 509
Merit: 500
I don't know if this is related, but I basically reset everything out of fear. I'm all synced up, but i'm missing XMR. Not a lot, but 17 XMR difference from this morning to right now. The bad part is that I never saved the TX Id. Any way of getting/finding the missing xmr?
legendary
Activity: 1484
Merit: 1005
Two tx from the attackers are now present in the mempool and are waiting to enter a block. They spend the outputs from the overflow tx.

http://chainradar.com/xmr/transaction/e3b94625d8eb5513dbc98b599a86a3b8622a23dce0124334f5b9982b656c59c5
http://chainradar.com/xmr/transaction/f7a2c4d0c4ccbfae37d550253c5f032156d9e8d0897d76137e26ea5fa8a92f44

Additionally, there is a tx in the mempool that is corrupt for 66 XMR.

http://chainradar.com/xmr/txpool

No clue what the intention of these are.
legendary
Activity: 2282
Merit: 1050
Monero Core Team
please help how can i know that my wallet is in the right fork? i have bitmonero v 0.8.8.2  and the last block was 203753
thanks in advance...

You are on the right chain as far as I can see. See below:

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.
full member
Activity: 149
Merit: 100
I would like to say a big THANK YOU to the Monero Devs and its community

Devs
*Quickly identifying, releasing and sharing a fix
*Forum updates / damage control
*Exchange notification

Community
*Exchange notification
*Buy walls
*Donations

--edit--
adding BTC to the buy wall!
legendary
Activity: 1456
Merit: 1000
How many blocks have your servers found since the attack, relative to an average of what they normally find?

The usually count +/-, nothing unusual

But found another interesting thing.
They are some hidden pool with ca. 7-9 Mhs (easy to find, just network-hashrate - all known pool speeds)
And daily difficulty waves depends on this hidden pool.
What now? Today wave is broken (see diff-picture on my pool) and all pools found more blocks this time )))
I think hidden pool on the wrong chain.

Why would he use a third party pool at all?

edit

yeah, difficulty looks down, blocks look up, relative to the diff drop?
member
Activity: 91
Merit: 10
please help how can i know that my wallet is in the right fork? i have bitmonero v 0.8.8.2  and the last block was 203753
thanks in advance...
legendary
Activity: 1456
Merit: 1000
Quote
If you're trying to remain anonymous....be careful not to reveal any information linking your bitcoin addresses to your identity. Satoshi, 2010

great satoshi, would love to hear his opinion on Monero...

Who says he isn't here already?

He's mining drk as we speak. lol.
legendary
Activity: 1176
Merit: 1134

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


I agree. What about using foreknowledge of this to trade (assuming people will panic).

Forks cause exchanges to freeze up. That would be too risky.

Maybe you think you are going to just kill the coin outright or close to it. If you can manage to arrange a short, you don't relay care about exchanges. You short, it goes to zero, you make money.

rpitilla has been selling OTC options. Any unusual put orders?


how could any organization smart enough to conduct this attack be stupid enough to think it would kill a coin?
What if they botched it? too many moving parts and they tried to shove a bunch of premade blocks and get N blocks ahead of the real chain. Then they could just feed in new blocks if the main chain ever got close and so with 1% of mining power actually needed get all the XMR from here to forever.

is that possible. It seems they did tack on a new block without mining it, so they just need to mine one block make a fork, shove in a decent sized chain and keep the rest of the thousands of pregenerated blocks in reserve.

I know, way too elaborate, but considering what they did...

anyway I am no expert on all this mining and blocks stuff, so just throwing out silly theories hoping someone that actually knows this in details might see the answer. I just have this feeling there is something else to find

James
hero member
Activity: 770
Merit: 500
Quote
If you're trying to remain anonymous....be careful not to reveal any information linking your bitcoin addresses to your identity. Satoshi, 2010

great satoshi, would love to hear his opinion on Monero...

Who says he isn't here already?
Jump to: