[XMR] Monero - A secure, private, untraceable cryptocurrency

[ltcnim]

Is there a problem with the blockchain? I can't sync anymore:

Code:

2014-Jun-28 17:24:52.224447 [P2P2]Block with id: <eac894117fe2c709e50b7e9f22a7d5a18f77c1865fbcb3b40b9ff4631444015f> failed to add transaction to blockchain storage

seems to be stuck there...

[aminorex]

Cache is amortized over the number of alus you pack in.  

the scratchpad is constructed (as a function of the block and nonce).

ah, thanks.  i stand corrected.

but 2MB is pretty small.  5bn transistors on a 22nm phi.  you can put roughly 2000 of those scratchpads on a single 14 nm die.

[surfer43]

Is donation to zone117x really relevant? Is there any reason not to show closed source pools?

[dga]

Cache is amortized over the number of alus you pack in.  

the scratchpad is constructed (as a function of the block and nonce).

ah, thanks.  i stand corrected.

but 2MB is pretty small.  5bn transistors on a 22nm phi.  you can put roughly 2000 of those scratchpads on a single 14 nm die.

Oh goodness, no.

Putting aside for the moment the horrible expense of a 5b transistor chip (you're much better off making 5 1b chips, but that's easy with crypto), the math is still incorrect:

- An SRAM cell holds 1 bit.
- An SRAM cell requires 6 transistors (in the most common design)
- The scratchpad is 2 mega*bytes*.
- There are 8 bits in a byte.

So one scratchpad requires 2*2^20 * 8 * 6 = 100M transistors.

Not counting any area devoted to control, AES, 64 bit ALUs to handle that nasty little multiply in the second part of the iteration, etc., that's at most 50 such scratchpads on a hugely expensive chip.

[liteon]

I am exploring (and mining!) Monero more then one month, so i am familiar with save, exit, refresh commands in daemon. Just yesterday tried to sync blockchain, and stuck at  block 98929 and nothing helps. First i deleted blockchain from %AppData% and synced - same. Now then i am waiting for Your help with download, trying a trick (maybe that will help)  - deleted bitmonerod.txt from C:\Monero & blockchain from %AppData% once again.

One thing i am worried now is here in pix:


Why so much "Connect failed"? :|

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^

[David Latapie]

Updated. And since you are donating, I put you on top of the list (other can do the same, of course). I suppose the 0.1% is for 45Jmf8PnJKziGyrLouJMeBFw2yVyX1QB52sKEQ4S1VSU2NVsaVGPNu4bWKkaHaeZ6tWCepP6iceZk8X hTLzDaEVa72QrtVh, right?

monero.crypto-pool.fr will donnate 10% of our earnings for core devs.
(fees will be taken from us and not from users).

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

[surfer43]

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.

[David Latapie]

Is donation to zone117x really relevant? Is there any reason not to show closed source pools?

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)

[liteon]

Why so much "Connect failed"? :|


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^

For me -> (33 days) behind - > lulz

Yes, but I cannot sync to receive payments.

[aminorex]

but 2MB is pretty small.  5bn transistors on a 22nm phi.  you can put roughly 2000 of those scratchpads on a single 14 nm die.

14nm - and nobody but Intel has the paper to be able to put out 14nm stuff.

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.

[dga]

but 2MB is pretty small.  5bn transistors on a 22nm phi.  you can put roughly 2000 of those scratchpads on a single 14 nm die.

14nm - and nobody but Intel has the paper to be able to put out 14nm stuff.

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

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.

[kbm]

Why so much "Connect failed"? :|


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^

For me -> (33 days) behind - > lulz

Yes, but I cannot sync to receive payments.

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?

[aminorex]

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

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?

[liteon]

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?

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?

[equipoise]

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

[tistoni]

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

[David Latapie]

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

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

[tistoni]

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

[5w00p]

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

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?

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.

[ntesic]

New pool, http://www.moneropool.net
Strong real dedicated server (not Amazon instance or so), 2% fee, no downtime, DDOS protected

Location? Payout treshold? admin's IRC nickname?

Server is located in Czech Republic, EU (100 mbps for now, upgradeable to much more, Tier1 Premium BW). Payout treshold is 0.1. You can reach me on same IRC nickname as on forum.
Latest pool software, latest daemon.

Actually, fee is 1.9% + 0.1% for developers.

Updated. And since you are donating, I put you on top of the list (other can do the same, of course). I suppose the 0.1% is for 45Jmf8PnJKziGyrLouJMeBFw2yVyX1QB52sKEQ4S1VSU2NVsaVGPNu4bWKkaHaeZ6tWCepP6iceZk8X hTLzDaEVa72QrtVh, right?

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.