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

You havent run out of space on your local drive have you, the blockchain needs about 1.5GB now, and the logs can get big if you are writing everything to a log file.

Also, FYI, the [P2Px] indicates each peer to peer connection, it will make up to ten of them usually but the peers are always reliable - you can get ones sending incorrect blocks or just disconnecting which will generate various messages from bitmonerod. As long as you have at least a couple of working P2P connections which are up to date then they will win out over the random incorrect ones.

Guys, do not use 32-bit Monero binaries at all. While devs do not use embedded database, currently, all the blockchain.bin is loaded into memory. It is 1.3Gb now - it is dangeriously close to 2 to 3Gb virtual address space of a process on 32-bit operating systems.

How to easily switch to 64-bit binaries? I simply delete file wallet.bin, but keep other wallet.* files, and type at command prompt (64-bit binary):
simplewallet --wallet-file wallet.bin (that is just deleted).

Also, 64-bit blockchain.bin one can download from 1st sticky page of this thread. Simply put it in your monero directory (Windows):
C:\Users\Asus\AppData\Roaming\bitmonero, and start bitmonerod.exe.

Agreed.  That is a separate problem.  I would only encourage brainstorming solutions to that problem as well.  Being a globally distributed team supporting an open-source product does provide a high degree of defense in itself, but without some protocols it is definitely not sufficient in itself.  But I would prefer to deal with one of these at a time, personally, because I think progress is more likely that way.

I would also point out that if more mundane and immediate threat scenarios are at such low ebb that we can actually think about these remote and theoretical (for the moment) issues, then we are in a very happy place.  (But then neither of us are active contributors, and hence may be blissfully unaware of code vulnerabilities which are a much more immediate and practical problem.)

Here is error message from daemon while tries to update:

2014-Jun-28 19:17:01.866210 [P2P1][76.16.120.82:18080 OUT]Sync data returned unknown top block: 105314 -> 105583 [269 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Jun-28 19:17:02.200195 [P2P9]tx with id: <7498d444287287aac613fdc3fc46443dcca9834090659fd72d44397522059aaa> in block id: already in blockchain
2014-Jun-28 19:17:02.216796 [P2P9]Block with id: failed to add transaction to blockchain storage
2014-Jun-28 19:17:02.232421 [P2P9][79.169.141.249:18080 OUT]Block verification failed, dropping connection

Not sure, I think it is hardcored in pool script and that script transfer that automatically to pool developers.
And as soon we achive better hashrate, we will donate to Monero developers as well.

You are intelligent and foreseeing with your musings on the future of XMR.  

When you begin to mention the 3-letter organizations, nation-states, and famous leaders, it makes me think.  I cannot help but agree with you about the relative simplicity involved in changing algos.  But, when these types of organizations and leaders are involved, the resources at their disposal will of course be nearly infinite, in comparison to regular folks.  At that point, who is to say that the developer team would not be under their influence/thumb(s)?  In such a situation, as crypto-apocalyptic as it seems today, the simple act of forking the blockchain and changing the algo will definitely no longer be simple.

Seems we would likely have bigger problems at that point (war), likely waged quite stealthily and with extreme precision toward the intended targets.

Could someone post binaries that works on amazon EC2 instance running ubuntu 64bit? I'm behind firewall and that's the only option to get ports open necessary to make my wallet sync. The syncing just keeps getting stuck otherwise. I cannot compile on Amazon, it kills the process, nor can I use the linux 64 binaries because of some illegal instruction.

Also, in the rare even the linux libraries actually work, THEY ARE COMPILED AGAINST LIBBOOST1.55 whereas most distros use libboost 1.54. If you don't have root privileges, which is quite likely, then you can't use the binaries

It is usually related with the binaries not being compatible with  your platform.

Compile by following these instructions: http://monero.cc/getting-started/#install_source

I get Illegal instruction (core dumped) with the linux binaries, running 64 bit ubuntu. Any solution?

^I don't have this problem. For me it's syncing just fine.

I'm running v0.8.8.1.
And, yes, I deleted that 2 files (stored in \AppData\Roaming\bitmonero) and the problem is still present. Not moving from block 105314.
Is it me only, or anyone else have the same problem?

You are correct of course.  I should always do my math on paper.  But even a factor of 40 is noise relative to the strategic point:  Reliance on a single algorithm (barring some feature of the algorithm which we have not anticipated here) will always be defeasible by NSA-scale resources.  It is not unreasonable to anticipate a warfare-scale budget being applied to the problem, if it were perceived as an existential threat.

If you have ever read about men such as Hoover, Nixon, Honecker, Cheney, Stalin, Kim Il-Sung (and these just a small sample from the span of a few short decades), you will understand why I say it is prudent to plan for the possibility that XMR may be considered an existential threat.  If XMR can scale to become the dominant provider of global networked private liquidity, it must cope with such threats.  If it can't, then why bother?

Have you deleted your p2pstate.bin and poolstate.bin? They will be found with you blockchain.bin file and will be recreated upon re-opening the wallet/daemon. Also, are you using the latest daemon in the OP?

No - please see above.  It's not 2000, it's 50.

Continuing that, if you were to build a dedicated device on 22nm using the same size as Intel's haswell chips (1.4B transistors), you could get at most 14 scratchpads.  Realistically, that's 12 when you make some allowances for the ALU, AES, control, etc.

In contrast, the haswell can fit 4.

The points I raised above about the increased efficiency of a special purpose chip stand, so that 3x advantage in # scratchpads would be multiplied by some other advantages, but it's still likely to only be a factor of 10, with probably a factor of 20-30 total energy advantage.

At present.  But we will get to finer processes than that, eventually.  2000-way on-chip parallelism may be feasible at 12/10nm nodes, with a 200 chip/wafer yield.  A single wafer would be roughly equal to 5,000 e5s, and global foundry capacity at least 5 million 18" wafers/month by 2020.  An attacker able to command 1% of foundry yield  could field about 25 CN-ghps each month. You'll never be able to field a sustained attack by the NSA if they have a warfare-scale budget for it, relying on cryptonight alone.  1% of fab capacity wouldn't be enough to harm the global economy significantly, so it is feasible for a nation-state, and it's like adding a hundred million computers to the network each month.

Of course this is something of a science fiction exercise at this point:  I'm using industry projections; but they are actual future projections by professionals used for business planning.  My numbers are very round.  But the point is that an NSA-scale attack will overwhelm the current system, unless there is a plan for evading the brute force.  A good strategy for dealing with a hash attack should definitely involve changing hash functions.  It is simple and cheap.  The process of implementing a new hash in silicon is a slow one, much slower even than the process of propagating a hash function change throughout a global p2p network, so it is also effective. 

The best approach I see is to incorporate various hash functions, at high diversity, into the software in advance.  The planned emergency broadcast system can be used to mandate a hash change at a given block, and core software can incorporate an simple mechanism for local operators to honor or dishonor such a broadcast at their discretion.

Yes, but I cannot sync to receive payments.

Donation: for now, the destination address is hardcoded to zone117x's address. It may change later.
We do not show closed-source because there is enough open-source pools (contrary to miners)

MoneroPool.org has been donating 20% of our earnings for core devs for a while now... fees are 0% now because of the DDoS and outages. but on July 1 our fees will be 1% again.

Since you will donate straight to the core team, you now are at the top

Same problem here. Tried just now, and stucked on 145 blocks behind.
Daemon is running, but lots of errors like:

- Block verification failed, dropping connection
and
- failed to add transaction to blockchain storage

It is running SYNC, but it is not syncing.
===================================

^bump^