@ Ziftr team:

I've been missing a proper block explorer. Seeing as the original one looks to be down (and was rather limited in functionality), please consider reaching out to a more comprehensive explorer service.

One that I really like and has some very interesting statistics, is BlockTree. I have no affiliation with this explorer, just ran across it through a previous altcoin experience. IIRC, the hoster/owner is bitcointalk member Ethought.

There are most definitely a bunch of other good providers out there.
It just feels to me that such a critical service should not be neglected.

Awesome, thanks Smooth & Mooo.
I'm happy either way as I'm still at it solo style, pool stats worry me not 
Heck, I'll be solo'ing even if block-finds get spaced by many days for me, as the point is also to run a contributing node.

Mooo: I figure it would make most sense for miners on your pool, if the nethash estimate was derived from the same input data that you are using for the fee calculation. This would allow your miners to make more sense of the dynamic fee at any particular time.

In other words: switch to a nethash estimation based on the time that it took to find the last 60 blocks (as that is the sample size for the dynamic fee calculation). The only downside I'm seeing is that you'd no longer display the same estimated nethash as the other pools, though your estimation would perhaps be the more accurate one.

Cheers!

I guess that a code review is generally a good thing, but personally, I do not care at all for this.
One example that simply summarizes why I have this opinion.

Here's the brief on a recent coin review from this same person:
Code Quality Grade: A
This coin has pretty much perfect code quality, no apparent network problems and the only issues, if any, are minor nitpicks.

Great success, we have a winner, right? Far from it.
The coin in this example went on to show that it had no developer at all, or had a hired gun that quickly abandoned the project and moved on to whatever else was earning him/her more BTC. That coin has been quite strongly manipulated by the people running the main bitcointalk account for the OP, has plummeted into virtually worthless, and is drifting without any plans or purpose moving forward. A code review does absolutely nothing to prevent this...

In contrast, here we have Genesys, a coin that:
- delivered right at the opening of the ICO (in-wallet demos and game),
- developers are around and shown quite good process towards other roadmap items,
- currently holds the insignificant market cap around 60 (or 65?) BTC, massive upshot potential
- actually has a business model, a purpose.

What I think would benefit Genesys coin the most, is attracting a wider audience. This can - and certainly will - be achieved by word of mouth, community engagement, reaching a few more development milestones, running some promotion initiatives.

I only even care for another exchange, for the simple fact that many people will stay well clear of YOBIT (and to a lesser degree, Empoex), for reasons completely unrelated to Genesys, and that don't really belong in this discussion. Poloniex would be absolutely awesome, but I'd be happy even with Bittrex or Cryptsy (and I'm not saying either of them is perfect).

Unfortunately, I don't have much time that would allow me to contribute here, but maybe I get an opportunity to do so later on. For the moment, I'll just enjoy the staking/hoarding phase, and eagerly wait for what is ahead. Cheers!

Note: this is one such time where the conditions are producing a poor instant estimation of nethash. Right now, if one only reads the stats on Moo's pool, one will think that it has 100% of the nethash, at about 150KH/s. In fact, there are 70KH/s at Arux pool at the moment as well, so the hashrate distribution right now is not particularly terrible.

I second this, and add the suggestion of trying out solo mining if using a high'ish-end CPU.
I'm still solo'ing on the daemon with a single i7 4770 and I think there has not been a single day that I don't hit at least one block.
Some days I get two, so, double-yay! 

Absolutely. The reason is that, the network hashrate is purely an estimation, based on the time that it took to find the last X blocks and their relative difficulty over that period.

In a similar sense, the pool hashrate is also just an estimation, since it is simply adding up the number of shares that it receives from miners over a certain period, and their relative share difficulty.

If you throw 100 KH/s at the pool right now, the pool stats will quickly update due to the massive influx of shares, while the network hashrate will take a good while longer to reflect the added hashrate, as the necessary sample data is much larger and the estimation takes much longer to settle after a drastic change.

Not sure I was able to come up with a half-decent description on this... Well, I tried 

Since Bob will have read through the basics of the currency that he is using as payment method, Bob will most certainly know that he can optionally expose the necessary information so that Alice (or any 3rd party) can decode the transaction.

Sidenote: I just realized that Bob and Alice are most definitely the largest Monero whales in existence!

Reservado. Venha daí discussão 

---

---

 

---

 
 

 

---

---

 

Seeing as release 0.9.4.0 also requires a full resync, though possibly aided by one of the bootstraps on the OP, I've sync'ed a full node on this version have a bootstrap to share. Please note that due to daily bandwidth limitations, this particular download link might not always be available.
If it becomes too complicated for me to host this file with the current provider (Dropbox), I'll see if I can work out an alternative one.

The bootstrap is current as of a couple hours ago, and can only be used in Windows x64 systems.
Aeon-Win-x64-bootstrap-2015-09-03

Cheers!

BTW: Smooth & Mooo, great job at spotting the issue so quickly, getting the pool back online, as well as the lightning speed at which the new releases were made available! Rock on! 

Open and Unlocked-for-Staking (if encrypted).
Happy Staking!

Here are Win binaries for anyone interested.
Mind the usual cautionary notes as these are unofficial, community provided.

Stable Full Node Release: Aeon-Win-x64-0.9.4.0
Testing Light Node Release: Aeon-Win-x64-0.9.4.0-light-node

I haven't run either of these myself yet, but will switch to the updated light-node version shortly.
My previous Aeon release download links are now broken (purposefully), but if anyone needs one of those older versions let me know as I do have the files archived anyhow.

Do remember to read the release details from Smooth, quoted just below!
Cheers!

@djm34:
I think the logic proposed was that some trusted party/escrow was holding the bounty, so that any dev could come up and claim it with a working faster version. Was not so much about trusting the dev, as it was about allowing multiple devs to compete for the collected funds.

Personally, I'm not sure it is a great idea, since it brings even more developer competition into the table, instead of focusing on collaboration. I dunno, maybe I'm just a dreamer...  

Edit: I stand by my suggestion from the other day. I thought it would at least garner some comments, but I take it that it was not interesting in other people's views. Oh well... 

So I had a moment to run 0.9.3.0, and it used up ~4.1Gb on my Win-8 box, while 0.9.2.0 used up 4.25Gb, which contrasts with your findings. This was not strictly 0.9.2.0 in my case, it was the light-node version running in archive mode (full node). I don't think small differences can be taken as representation of anything much, since these look to vary along with the network conditions, transaction pool, etc.

Perhaps keep an eye on memory usage and see if it settles at some lower amount eventually?

I'm back on testing with just the light-node though, seeing as that is the 1st major release on the horizon (and just 2.6Gb of memory usage is also neat)    Thank you everyone for the feedback btw!

Here you go Mr. Break-It-All  
Unofficial win binaries, caution advised, etc, etc:
Link Pulled as a Precautionary measure - see Smooth's posts further below.
Note: I haven't tested these myself yet. Just picked up fresh from git and compiled as before.

Quoted from Smooth's instructions:
Upgrade note: Shut down your existing node, delete your poolstate.bin file, then restart using this new version.

Happy Testing!

I'm familiar enough with the constraints of pool and mining software to know why many of the presented approaches to developer funding/rewarding do not work. Will not post at length about this now as it would take more time than I'm willing to afford right now, but I'd like to pitch in something.

I do have one suggestion, admittedly of moderate return potential, but importantly, it should not be too costly to implement and would be worth trying out:
- Many people do not know or care to compile, and so will run whatever binaries are made available.
- Many of those that do know how to compile/code, would still uphold fee system, if the set fee is small enough and reasonable.
- Nicehash is by far the most popular service for set-and-forget mining with BTC payout.

So, how about coding a fee system, that only kicks in when mining at Nicehash/Westhash, and mines 1% or 2% of the time to a hardcoded BTC developer fund address?
The destination fund address could be:
- global and individual - if say, sp_ would hardcode his own address in his fork for example, regardless of the algorithm selected, or
- global and shared - if say, the miner would have a hardcoded address that is under the control of multiple developers, or some trusted fund manager, or some multi-sig scheme combination, again, regardless of the algorithm selected, or
- algo-based and individual - if say, for lyra6rev15, the miner would have a fee address for djm34 (responsible for most boosts of that algo), while if quark was selected instead, the fee address would be set for sp_ (responsible for most boosts of that algo).

I'd estimate that the potential returns from such a system are not really massive, but they could certainly add up to make something very much worthwhile for everyone. On the other hand, it should be simple enough to code and maintain, as it is a basic tie to Nicehash and uses plain BTC addresses for the funds routing/assignments.

This approach is still just based on good faith, and keeping the economical incentive mostly unchanged, so that it might be attractive for a good number of users. It also leaves room for private deals and private pools and what not, for any exceptional mining opportunities (new algorithms, solo mining, etc, etc).

I'll also drop a big thank you to tpruvot, which has consistently improved ccminer with new features and better usability. As he focus less on the specifics of squeezing every bit of performance from algo X or Y, he's not mentioned here as much, yet he is one of the most active coders that we have in this space.
I appreciate all developers and everyone's contributions. For a rather long time now, my single rig has been firmly pointed at a mining destination that adequately rewards 2 of the developers here for their work (you know who you are, and thank you both!)

Happy Mining!

Have you checked if you are getting the GPU clocks throttled due to high temperatures?
Higher intensity usually demands more of the GPUs, and if thermally constrained, performance can indeed get worse by raising intensity. Personally, I recommend high & fixed fan settings, to ensure lower temperatures and finding the clock sweet spot before throttling kicks in.

Oh, you are that guy! 

@SRBOOTH:

If you're wanting to run a full node just for the sake of a full node, but have otherwise no problems with the test binaries for the pruning version, you could also just run the pruning version without any parameter (specifically, without --pruning). This will have you running a regular/full node.

@smooth:

I used Boost 1.59 for the aeon-light test binaries. Should we expect trouble anytime we switch between binaries that were compiled on different Boost versions?  
If that's the case, I'd appreciate some official direction as to what version to use, so that I'd always use the same as anyone that will produce official binaries, thus preventing similar complications in the future.

Thanks!