[ANN] AEON: Scalable, private, mobile-friendly cryptocurrency

[MoneroMooo]

http://aeonpool.mooo.com/  is down

Back up now. Sorry about that, my ISP hiccuped and the dynamic DNS update did not trigger automatically this time.

[1714987773]

1714987773

[Phantas]

http://aeonpool.mooo.com/  is down

Back up now. Sorry about that, my ISP hiccuped and the dynamic DNS update did not trigger automatically this time.

no problem, thank you

[nikos64]

Cheers Smooth! It's an i7-4770, standard clocks and all, running 6 threads, above normal priority.

Why don't you run all threads/cores but in low priority? Windows can manage just fine the other jobs that way, and you can have the max hashrate too.
I even play Left 4 Dead 2 without stop mining. The hashrate drops from 850 h/s to 550 while playing but that's all, I have to do nothing else.

[smooth]

Pruning update

I'm running two pruned nodes right now, as a bit of a final performance test, after completing several functional tests.

Assuming no problem arise I will be dropping a test release within several hours.

[bangomatic]

Pruning update

I'm running two pruned nodes right now, as a bit of a final performance test, after completing several functional tests.

Assuming no problem arise I will be dropping a test release within several hours.

Great update!  Thanx!

[myagui]

Cheers Smooth! It's an i7-4770, standard clocks and all, running 6 threads, above normal priority.

Why don't you run all threads/cores but in low priority? Windows can manage just fine the other jobs that way, and you can have the max hashrate too.
I even play Left 4 Dead 2 without stop mining. The hashrate drops from 850 h/s to 550 while playing but that's all, I have to do nothing else.

These days, that box is primarily a GPU mining rig, and the current GPU work is actually very sensitive to any moderate CPU usage. Optimal performance (giving priority to current GPU work), was found by setting affinity to have 2 dedicated threads for the GPU miner. I can then do whatever on the other 6 threads, that the GPUs remain at full performance.

[nikos64]

Cheers Smooth! It's an i7-4770, standard clocks and all, running 6 threads, above normal priority.

Why don't you run all threads/cores but in low priority? Windows can manage just fine the other jobs that way, and you can have the max hashrate too.
I even play Left 4 Dead 2 without stop mining. The hashrate drops from 850 h/s to 550 while playing but that's all, I have to do nothing else.

These days, that box is primarily a GPU mining rig, and the current GPU work is actually very sensitive to any moderate CPU usage. Optimal performance (giving priority to current GPU work), was found by setting affinity to have 2 dedicated threads for the GPU miner. I can then do whatever on the other 6 threads, that the GPUs remain at full performance.

I see... I do the same thing when I have something to mine with my GPU. Not much GPU mining lately though.

[myagui]

@smooth,

As I had compiled from git just yesterday, I am also running a pruned node, right? Just wondering.
All is working well here, just found a block solo, yay! 

[smooth]

@smooth,

As I had compiled from git just yesterday, I am also running a pruned node, right? Just wondering.
All is working well here, just found a block solo, yay!  

No pruning is not in git yet, and the first version with pruning (very soon) will be a designated test version, not a release.

The current official release does have some memory and storage optimizations I came across when working on pruning that are in there.

just found a block solo

Nice!

Thank you for supporting the network!

[smooth]

Pruning update

I'm running two pruned nodes right now, as a bit of a final performance test, after completing several functional tests.

Assuming no problem arise I will be dropping a test release within several hours.

To follow up, I did discover one issue with wallet refreshes in testing. It is easily reproducible so I'm sure I will track down the cause and get it fixed soon.

EDIT: I did find the problem in the wallet and unfortunately some more work is going to be needed so the test release of pruning will be pushed back a day or two.

[shitaifan2013]

crazy trading traffic for aeon on bittrex  that way my otc order will never get filled 

[Schild_]

@smooth,

As I had compiled from git just yesterday, I am also running a pruned node, right? Just wondering.
All is working well here, just found a block solo, yay!  

No pruning is not in git yet, and the first version with pruning (very soon) will be a designated test version, not a release.

The current official release does have some memory and storage optimizations I came across when working on pruning that are in there.

just found a block solo

Nice!

Thank you for supporting the network!

Awesome. Thanks for the hard work.

[smooth]

Pruning update

I'm running two pruned nodes right now, as a bit of a final performance test, after completing several functional tests.

Assuming no problem arise I will be dropping a test release within several hours.

To follow up, I did discover one issue with wallet refreshes in testing. It is easily reproducible so I'm sure I will track down the cause and get it fixed soon.

EDIT: I did find the problem in the wallet and unfortunately some more work is going to be needed so the test release of pruning will be pushed back a day or two.

One last follow up before I drop a release (soon!)

I investigated the wallet problem. There are two ways of fixing it. One is to reduce the degree of pruning and keep more old data, and the other is to disallow syncing an old wallet from a pruned node. After implementing the first I reconsidered and decided to go with the second. Not only does the first approach reduce the amount of pruning now, it will further reduce how much pruning can be improved later.

The new approach will only support "active" wallets off a pruned  node. The pruning window is 10 000 blocks or around 28 days, so you will need to sync (open and then exit) your wallet at least once per 28 days from a pruned node to keep it up to date, otherwise you will need an unpruned node to sync the wallet. If there is no activity at all (received payments) during the offline period, then it will still be okay to sync from a pruned node, even after 28 days.

I feel this limitation is acceptable for most if not all use cases.

[myagui]

@smooth, fwiw, I concur with your reasoning on how to address this wallet refresh issue and pruning strategy. Good stuff! 

[exciter0]

If there is no activity at all (received payments) during the offline period, then it will still be okay to sync from a pruned node, even after 28 days.

Smooth, in the scenario where eventually the whole network contains only pruned nodes and users have cold wallets, if the wallets were inactive for over 28 days and users decide to buy more coins, what would happen?

I guess I'm not understanding the issue here, sorry. The requirement of having to refresh a wallet every 28 days won't work with cold wallets, I'd say.

 

[smooth]

If there is no activity at all (received payments) during the offline period, then it will still be okay to sync from a pruned node, even after 28 days.

Smooth, in the scenario where eventually the whole network contains only pruned nodes and users have cold wallets, if the wallets were inactive for over 28 days and users decide to buy more coins, what would happen?

With the current model of pruning there will never be a case that the whole network contains only pruned nodes. There still need to be some unpruned (also known as archive nodes) to provide the old blocks to new users. This is the same model used by Bitcoin currently. My long term plan is provide a mechanism of payment to ensure that people want to provide these archive nodes. Short term the seed nodes at least will run archive nodes and I'm recommending that important services (exchanges, pools, etc.) not run pruned nodes at this time so those will be there too.

Longer term there will be a different model of pruning and wallet syncing that will fully work with pruned nodes for both regular and lightweight wallets. Lightweight wallets will work this way first, probably.

[exciter0]

With the current model of pruning there will never be a case that the whole network contains only pruned nodes. There still need to be some unpruned (also known as archive nodes) to provide the old blocks to new users. This is the same model used by Bitcoin currently.

Thanks for the explanation, Smooth. If this is configurable on the daemon, I'll be happy to support an archive node. Merging LMDB support would avoid the lengthy and dreaded 12-hour "saving blockchain" pause. 

[smooth]

With the current model of pruning there will never be a case that the whole network contains only pruned nodes. There still need to be some unpruned (also known as archive nodes) to provide the old blocks to new users. This is the same model used by Bitcoin currently.

Thanks for the explanation, Smooth. If this is configurable on the daemon, I'll be happy to support an archive node.

Yes, there is a --pruned option. Without the option it runs in the traditional unpruned aka "archive node" manner.

Merging LMDB support would avoid the lengthy and dreaded 12-hour "saving blockchain" pause. 

That is planned, just waiting for that code to become fully stable with the last remaining issues worked out.

Also, the plan is for pruning to coexist with a database, and that has factored into the design. The benefit in that case is reduced, but perhaps more importantly slow-growing, database size. This will allow small devices to continue to run nodes long term without filling up storage.

[MoneroMooo]

Just a note to say that my pool appears to be comfortably past 50% at the moment, and that while I'm not planning on 51%ing aeon, you wouldn't just trust some guy on the internet not to, right ?
While Arux's pool appears to be down, the daemon can solo mine, which should still be a reasonable option for large hash miners that can handle the RAM usage.

[Phantas]

Just a note to say that my pool appears to be comfortably past 50% at the moment, and that while I'm not planning on 51%ing aeon, you wouldn't just trust some guy on the internet not to, right ?
While Arux's pool appears to be down, the daemon can solo mine, which should still be a reasonable option for large hash miners that can handle the RAM usage.

I think, also minergate is alive.