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

[MoneroMooo]

This is a reminder that, as of now, Minergate and Chainradar are both on the WRONG fork of the Aeon blockhain, as they seem to still not have updated their daemon.

Current block height is 594648.

Note that while chainradar shows 599580, this does not mean they have more cumulative weight, as the new block target is 4 minutes.

[kazuki49]

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I would like to point other solution to the RAM usage but no Cryptonote coin but Monero is developing one from scratch.

[exciter0]

+1
Would rather see LMDB support come before GUI. CN light is already heading in the right direction low end PC's.

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I would like to point other solution to the RAM usage but no Cryptonote coin but Monero is developing one from scratch.

[smooth]

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.

In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.

I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.

However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.

[macorcina]

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.

In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.

I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.

However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.

I notice demon load all blockchain in ram,  3.1 gb

[smooth]

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.

In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.

I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.

However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.

I notice demon load all blockchain in ram,  3.1 gb

Interesting. On my test systems it is about 5 GB. I'll continue to investigate.

[exciter0]

confirming  5009MB RAM on my system, blockchain.bin itself is 2.9GB

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.

In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.

I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.

However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.

I notice demon load all blockchain in ram,  3.1 gb

Interesting. On my test systems it is about 5 GB. I'll continue to investigate.

[smooth]

The file is 2.9 GB but that also contains redundant information. The actual blockchain itself is about 1.3 GB.

For example, block hashes are stored three times -- once a block hash to block map, once in block hash to height map, and once in the previous block field of each header. This is all entirely reasonable except that I haven't been able to get the numbers to make sense with what is actually being used.

confirming  5009MB RAM on my system, blockchain.bin itself is 2.9GB

smooth, do you have plans to use the current LMDB that is being developed on Monero? Don't you think it is a good idea to release it on AEON first to see how it would play out on Monero.

I plan to use it but it is clearly not quite ready (no official release from Monero and bug fixes still being committed for it, on which I have been helping MoneroMooo). I feel merging it now would likely cause problems and would certainly cause additional work continuing to merge bug fixes.

In hindsight if AEON had existed in its present form developing a database for it first would have been a reasonable idea.

I have a pruning solution that is almost ready to release for AEON which will reduce memory usage and even with a database will still be useful to limit disk usage for smaller devices with limited storage.

However, I'm having some issues with tracking down the source of a lot of excess RAM usage. The AEON blockchain, in terms of actual data, is only about 1.3 GB, so the (unpruned) memory usage of roughly 5 GB seems quite excessive. I have accounted for a lot of the extra copies of data being stored (correctly) but the numbers still don't add up. The same sort of extra memory use persists with pruning and I'm trying to figure out why.

I notice demon load all blockchain in ram,  3.1 gb

Interesting. On my test systems it is about 5 GB. I'll continue to investigate.

[macorcina]

On linux mint 17 64 bit on disk blokchain  3.1 GB (3102867674 bytes)
 pid aeon In RAM
heap  1/   3,8 Gb
.........2/   310 Mb
..........3/  128 Mb
..........4/  128 Mb
..........5/  128 Mb
after this stack 9075 //  13 times average 70 - 60 Mb total around 1GB

if this something help....

If it's possible not to load all blockchain in ram, only part .....
And some incremental write  blockchain on disk  .....

Like DSH coin >
blocksindexes.dat
blocks.dat
blockscache.dat


                            

[H.arkness]

is a gui wallet for this coin? something with a regular interface

[smooth]

is a gui wallet for this coin? something with a regular interface

Coming soon. You could probably get some of the third party Monero wallets to work, since the APIs are similar or identical.

[smooth]

On linux mint 17 64 bit on disk blokchain  3.1 GB (3102867674 bytes)
 pid aeon In RAM
heap  1/   3,8 Gb
.........2/   310 Mb
..........3/  128 Mb
..........4/  128 Mb
..........5/  128 Mb
after this stack 9075 //  13 times average 70 - 60 Mb total around 1GB

if this something help....

Thank you that is somewhat helpful. I will look at the memory maps more closely myself. I wouldn't expect the stacks to be fully mapped but maybe I'm incorrect. Anyway, I'm continuing to investigate.

[macorcina]

On linux mint 17 64 bit on disk blokchain  3.1 GB (3102867674 bytes)
 pid aeon In RAM
heap  1/   3,8 Gb
.........2/   310 Mb
..........3/  128 Mb
..........4/  128 Mb
..........5/  128 Mb
after this stack 9075 //  13 times average 70 - 60 Mb total around 1GB

if this something help....

Thank you that is somewhat helpful. I will look at the memory maps more closely myself. I wouldn't expect the stacks to be fully mapped but maybe I'm incorrect. Anyway, I'm continuing to investigate.

ok. i'm glad if I help something

[H.arkness]

bought some aeon, lets see where this goes, hopefully to the moon and beyond

[smooth]

bought some aeon, lets see where this goes, hopefully to the moon and beyond

Welcome!

[macorcina]

bought some aeon, lets see where this goes, hopefully to the moon and beyond

47 000 aeon ?

[smooth]

New feature -- donation mining

Introduction

I've commited a new feature to github master: easy donation mining.

By adding the flag --donate to your daemon, you can automatically solo mine on behalf of the donation address. If you are using scripts to start your daemon, please add this flag.

This helps support the project directly with the mined coins going to the donation fund (and helps support the coin value by reducing the number of coins being mined and dumped) but more importantly helps support and decentralize the mining network for the coin. A huge problem with most small coin projects is that their mining networks are not only weak but also very concentrated. In our case, roughly 1/3 of the hash power is on MoneroMooo's pool, and at times that has been >50%.

In my opinion, a stronger and more robust coin network supported by software features and active support for the mining network by the user base will contribute directly to increased coin value, which in turn will encourage more mining, and attract more users. The result can be a virtuous circle where the coin becomes both more valuable and more secure!

tldr: add --donate when starting your daemon to support the project and the network

Additional details

By default, the --donate option uses only a single thread, which given our lightweight hashing algorithm, should have minimal impact on performance, heat, or power use on most current computers, since it will use only one core (or even just part of a core) and in most cases only a small portion of your cache. I'm interested in reports about how this works out on your hardware. When reporting your observations, be sure to specify the exact CPU model, amount of RAM, etc.

The usual --mining-threads option (followed by the number of threads to use) can be added if you do not mind a larger impact on your computer (performance, power use, etc.) and/or want to increase your support for the project and the network. In this case you can use the show_hr commend to optimize the number of threads vs. hash rate. Your cache size in megabytes or a slightly smaller number is a good start (e.g. 3 MB cache, try 2-3 threads).

Alternately, you can use the --start-mining option (followed by your own address) to mine to solo mine to your own wallet instead of donating. I still strongly encourage everyone to do this if you don't want to donate your resources. I'm more interested in supporting the network than I am in donations. As with all solo mining, you should not expect to receive (or donate) coins on a regular basis. Instead, view it as more of a lottery/raffle/drawing where you are occasionally rewarded for supporting the network.

In the future I plan to expand this feature into something more like Monero's upcoming smart mining, where it adjusts to computer usage, power source, etc. and automatically mines to your own wallet by default if you don't opt-in to donations. The upcoming GUI will support some of these enhancements. Feedback and suggestions welcome.

Please test, and just as importantly, please support the network!

[kcanup]

Looks good going here, keeping my eye on here on future developments. Keep up the good work Aeon Team 

[smooth]

Looks good going here, keeping my eye on here on future developments. Keep up the good work Aeon Team 

Thank you!

[Schild_]

Looks good going here, keeping my eye on here on future developments. Keep up the good work Aeon Team 

I second that. Bought an nice amount of coin because everything is going for it. I'll be glad to mine once this function is on the GUI.