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

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

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.

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

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.

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


seems to be stuck there...

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.
Anyone else?
Help?

I'd better mention http:\\cryptonotepool.org.uk\ has been updated to the latest version now, still keeping fee at 1% plus 0.05% for pool dev Zone117x.

Stick with a pool with a proven track record for reliability, run on private high availability hardware in a dedicated datacentre, not shared on someone's cloud.

We understand that there are small profit margins in mining nowadays and miners need to make every % count.

Support regularly available in IRC #monero or by email, whether for new miners getting setup or old ones with special requirements.

At http://pool.cryptoescrow.eu 2014.06.28 Significant Pool Updates were made:

• Up & Running again.
• DDOS protected
• Fees changed: 0.8% pool fee and 0.2% goes for pool development
• Added minimum payout of 0.5XMR

We are sad to see Wolf0 leave our pool's team, but we are up and running again.
Wolf, thanks for all your input and good luck!

We had help from zone117x, he will also help us in the future regarding the pool set up

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

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?