Wolf's (AES-NI): https://github.com/moneromooo/cpuminer-multi
Tsiv's (GPU, nvidia): https://github.com/moneromooo/ccminer-cryptonight
Lucas Jones' (CPUs without AES-NI): https://github.com/iamsmooth/cpuminer-multi

exciter0: update your daemon (if you can compile it, I'm not sure if there's a binary with the latest source). I've just checked the source and the diff change was done only recently.

Arux: in pages/home.html, find the line:

updateText('networkHashrate', getReadableHashRateString(lastStats.network.difficulty / 60) + '/sec')

and replace 60 with 240 (new block target).

Just a note to say that the bonus for the july hashrate rally was received (thanks dNote!) and all miners' bonus have now been paid. Interestingly, I had to decrease mixin from 3 as some large denominations did not have enough outputs on the blockchain to mix with (going by what can throw such an exception in the code).

Shouldn't matter for just one off like that. The stats on the pool can be late by like half a minute (the stats thread gathering data and refreshing the compressed bundle every N seconds, the web page's timer downloading that bundle every N seconds, etc).

Yes, it's as Myagui said. Last block 40 minutes ago. Blocks are now targetted a 4 minutes, and I've lost about half of the miner hash from people who haven't updated yet, so block finding rate on the pool has gone down a lot. On the plus side, we get 40 AEON per block instead of 10

I've seen the not-refreshing-problem, no idea what it is about as I'm not super clued in to Javascript/browser tech.

I just disabled banning on my pool, and will reenable it some time after the fork. This should let people switch a bit before or after without issues caused by temporary bad hashes.

Additionally, the difficulty will go up, so the pool settings will have to adapt too as it does (mostly starting diff I guess).

You can look at the outout of "top". Near the top, you should see a line starting with "%Cpu(s):
If you get a high % in the wa field, you're waiting on I/O. If you get lots in us, it's busy CPU crunching in user space.

It's 15 minutes on my pool. Maybe something else was wrong. Usually it's a bad address passed to -u.
You don't get banned at first bad share by the way. It can happen normally for overheating GPUs. But I regularly see bursts of bad shares in the log and it's hard to say if it's a transient problem or some jerk trying to cheat their way into more aeon.

That's all you need to do, unless you're mining, in which case you have to switch from cryptonight to cryptonight-light mining at block 592000. The switch should happen in about 18 hours IIRC, and should be automatic if you have the new daemon running.
You might see messages about blocks not accepted, etc, etc, these are fine if they're from non updated daemons you are connected to.

About the block reward's effect on coinbase tx size, for the next CN fork, it's possible to get the best of both worlds: a "guiding" smooth emission curve, but with the actual rewards quantized. The "less smooth" effect should not matter. The block reward penalty would still apply, but it too might be quantized (on the upside, I guess). I believe the XDN one isn't quantized anyway, and I've not seen it happen much recently so it's unclear it matters much.

For non coinbase txes, I think XDN's best off for two reasons: because it did not have the period of mining with dusty pool payouts, so payments don't spend old dust; and because a ducknote is worth very little so pretty much all amounts chosen by a person (as oipposed to automatically calculated) are above the dust level anyway.

Last, block time could be adaptive, with a similar algorithm to difficulty, but based on number and size of transactions. Given a quantized block reward, smoothly varying targets should not cause block rewards to go dusty as they adapt to keep the emission curve close to the ideal.

Would need studying to make sure those can't get gamed by large hash miners though.

Offtopic, but for the record: 0.01 monero per kB. Typo, I guess.
(It used to be less, but had to be bumped because blockchain spammers too advantage)

If you can't mine, describe your problem more precisely (ie, any error messages, you see, what miner you use).

Also, make sure you are using an Aeon address. Some GUI package miners create a Monero address by default, and that's not going to work.

The actual prefix length is per language, so you're free to have 4 letter prefix if you mark the list as such.

I'm a bit worried about adding another consensus system on top of PoW. Darkcoin's is fatally flawed (masternodes deciding among themselves over the rest of the network), but Vanilla's is decentralized, and seems to make sense from the little I've seen. However, I can't see how it can handle network partitions rejoining if a couple blocks have passed. I'll have to go read their whitepaper when I get time, as it does seem like an interesting coin.

Why not ?
That's kind of the point of this command: get the view key from the cold wallet, copy it to the less safe machine, and use it there.
Or did I misunderstand the question ?

If it's your own address, you can type "viewkey" in simplewallet.

I'd say try running the line manually, to make sure you get the same error, and then try running the same, with an extra ../contrib/libepee.a inserted just after libserialization.a and see if that helps.

You are correct.

Since my last post on the topic, here's an overview of the main changes pushed to bitmonero master:

- Russian and German word lists are now available for seeds.

- An option in simplewallet to always confirm a transfer with the user (currently, it only does if the transfer needs to be split in more than one tx). To use: set always-confirm-transfers 1. You will need to supply your wallet password, as this is a persistent option that gets saved to the wallet.

- An experimental new tx construction algorithm, which should fix problems when trying to send a large part of one's balance. It's a new simplewallet command (transfer_new), so the usual transfer command still works as it used to. Please report any problems with it if you try it. Note that using it is safe if you set always-confirm-transfers 1, since you can always say no. set_log 1 will log the new transactions to simplewallet.log regardless.

And last, a number of smaller fixes went in: from unit tests to word list tweaks, build system issues, and misc cleanup.

I wouldn't really want github to get in the business of deciding what gets censored or not. How would they determine if a claim is valid ? What if both projects took code from a third one which they don't know about, for instance ? Besides, only the attribution/copyright thing is wrong. Removing comments is perfectly fine, as long as the copyright notice is retained.