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

[QuasiPuppet]

Has anyone been able to compile Aeon on Arch? I cant get the darn aeond to compile on Arch or run if I compile on Ubuntu....

What error do you get?

It's looking for boost-1.55 but you have boost 1.58 installed.

As for the compile error, go into CMakeLists.txt, find where is says -Werror and delete that.

Ok, now I get a new error

Code:

[ 17%] Building CXX object src/CMakeFiles/cryptonote_core.dir/cryptonote_core/miner.cpp.o
In file included from /home/twiggy/Wallets/aeon/contrib/epee/include/storages/portable_storage_template_helper.h:32:0,
                 from /home/twiggy/Wallets/aeon/src/cryptonote_core/miner.cpp:44:
/home/twiggy/Wallets/aeon/contrib/epee/include/storages/portable_storage.h: In member function ‘bool epee::serialization::portable_storage::get_next_section(epee::serialization::portable_storage::harray, epee::serialization::section*&)’:
/home/twiggy/Wallets/aeon/contrib/epee/include/storages/portable_storage.h:430:16: error: converting to ‘bool’ from ‘std::nullptr_t’ requires direct-initialization [-fpermissive]
         return nullptr;
                ^
src/CMakeFiles/cryptonote_core.dir/build.make:86: recipe for target 'src/CMakeFiles/cryptonote_core.dir/cryptonote_core/miner.cpp.o' failed
make[3]: *** [src/CMakeFiles/cryptonote_core.dir/cryptonote_core/miner.cpp.o] Error 1
make[3]: Leaving directory '/home/twiggy/Wallets/aeon/build/release'
CMakeFiles/Makefile2:324: recipe for target 'src/CMakeFiles/cryptonote_core.dir/all' failed
make[2]: *** [src/CMakeFiles/cryptonote_core.dir/all] Error 2
make[2]: Leaving directory '/home/twiggy/Wallets/aeon/build/release'
Makefile:138: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/twiggy/Wallets/aeon/build/release'
Makefile:20: recipe for target 'build-release' failed
make: *** [build-release] Error 2

[1713519693]

1713519693

[1713519693]

1713519693

[1713519693]

1713519693

[1713519693]

1713519693

[1713519693]

1713519693

[1713519693]

1713519693

[smooth]

Has anyone been able to compile Aeon on Arch? I cant get the darn aeond to compile on Arch or run if I compile on Ubuntu....

What error do you get?

It's looking for boost-1.55 but you have boost 1.58 installed.

As for the compile error, go into CMakeLists.txt, find where is says -Werror and delete that.

Ok, now I get a new error

Code:

[ 17%] Building CXX object src/CMakeFiles/cryptonote_core.dir/cryptonote_core/miner.cpp.o
In file included from /home/twiggy/Wallets/aeon/contrib/epee/include/storages/portable_storage_template_helper.h:32:0,
                 from /home/twiggy/Wallets/aeon/src/cryptonote_core/miner.cpp:44:
/home/twiggy/Wallets/aeon/contrib/epee/include/storages/portable_storage.h: In member function ‘bool epee::serialization::portable_storage::get_next_section(epee::serialization::portable_storage::harray, epee::serialization::section*&)’:
/home/twiggy/Wallets/aeon/contrib/epee/include/storages/portable_storage.h:430:16: error: converting to ‘bool’ from ‘std::nullptr_t’ requires direct-initialization [-fpermissive]
         return nullptr;
                ^
src/CMakeFiles/cryptonote_core.dir/build.make:86: recipe for target 'src/CMakeFiles/cryptonote_core.dir/cryptonote_core/miner.cpp.o' failed
make[3]: *** [src/CMakeFiles/cryptonote_core.dir/cryptonote_core/miner.cpp.o] Error 1
make[3]: Leaving directory '/home/twiggy/Wallets/aeon/build/release'
CMakeFiles/Makefile2:324: recipe for target 'src/CMakeFiles/cryptonote_core.dir/all' failed
make[2]: *** [src/CMakeFiles/cryptonote_core.dir/all] Error 2
make[2]: Leaving directory '/home/twiggy/Wallets/aeon/build/release'
Makefile:138: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/twiggy/Wallets/aeon/build/release'
Makefile:20: recipe for target 'build-release' failed
make: *** [build-release] Error 2

Edit and change nullptr there to false.

Was fixed in Monero here: https://github.com/monero-project/bitmonero/commit/696225321f26c0754f0ae60d18201e375fb6ff82

I'll pull that into AEON shortly.

[smooth]

New version (0.9.4.0)

Mandatory if you are currently using 0.9.2.0 or 0.9.3.0

Recommended for all users

In order to avoid any future problems like the one that happened to MoneroMooo's pool, this release reverts the recent changes to optimize blockchain memory usage and remove stuck tx key images. It is very likely that one of these changes (possibly in connection with some existing bug) caused Mooo's blockchain to become corrupt. Those changes are also present in the pruning test so I recommend discontinuing the test until further notice.

The other recent improvements such as fixing the mining speed on Windows, anonymity improvements, transaction fee, dust reduction, etc. remain in this version.

You will need to download a bootstrap from before the 0.9.2.0-0.9.3.0 changes or resync. Your existing blockchain will be ignored. Resyncing should be significantly faster than before in most cases. The older bootstraps from OP will likely work thought they will require a bit of syncing.

The pruning test branch has been updated to 0.9.4.0, so if you are using that you will need to fetch the update and recompile or wait for a new community-provided build.

Other changes in this release

Optimize sync speed in checkpoint zone
Update seed node list

https://github.com/aeonix/aeon/releases/tag/v0.9.4.0

I was using 0.9.1.1 and just updated to 0.9.4.0

I did not download a bootstrap but just opened it.  The blockchain had been up to date on 0.9.1.1.  My comp is relatively slow.  It went thru the checkpoints in one minute as well as "blockchain initialized. last block 604734"  and 2 minutes later it was synced.

Is that correct?  Was I supposed to delete any BIN files?

You're good to go. There was never any problem with 0.9.1.1 and if you had one of the later versions it would have automatically synced from scratch.

BTW, notice the extremely fast sync time for AEON now. With the lighter PoW and 4 minute block time, sync speed is increased by up to 20x depending on hardware. More optimizations are possible, too.

[smooth]

Is normal that if i give the command bc_height (that i suppose shows the last block downloaded) shows 401 and doesn't change even after 1 hour? i have 7 peers and no idea about how is possible...

bc_height is a wallet command. In order to update the wallet view of the blockchain you need to use refresh or exit and reenter the wallet.

An alternative is the diff command in the daemon which shows real-time height and difficulty

[smooth]

This error indicates that your blockchain.bin file is corrupt. (The alt-chain supposedly connects to a block that is higher than the length of the main chain in your blockchain.bin file.)

I don't know how this happened and if you want to upload your blockchain.bin somewhere perhaps we can analyze it. However, for the time being I suggest that you either delete blockchain.bin and resync from scratch (reasonably fast with the latest version) or download one of the bootstraps.

Thank a lot, issue was fixed.

I have 2 questions, BTW:

1. Is it possible to store blockchain in any place I want (Win client)? Drive C: is too small.
2. Why aeond takes all available memory (4Gb)? Other daemons not so hungry...

1. Yes, you can use the --data-dir option to put the data elsewhere. I understand it is possible to set up a shortcut to store daemon command line options, but I don't know the details since I don't use Windows.

2. We are working on improvements. The experimental pruning version reduces memory usage almost by half. Eventually the database will reduce it to almost nothing (<100MB).

[smooth]

An investor has contacted me who wants to buy a some coins OTC. If you are looking to diversify or cash out please PM me and I will escrow it (no fee but you are free to make a donation). Minimum lots of 25K.

[exciter0]

An investor has contacted me who wants to buy a some coins OTC. If you are looking to diversify or cash out please PM me and I will escrow it (no fee but you are free to make a donation). Minimum lots of 25K.

I bet the buyer is testing whether you would dump the 400K dev bounty, Smooth *wink* *wink* 
We also have that fine OTC thread that dnaleor's running.

[rendravolt]

Wait pump 

[languagehasmeaning]

An investor has contacted me who wants to buy a some coins OTC. If you are looking to diversify or cash out please PM me and I will escrow it (no fee but you are free to make a donation). Minimum lots of 25K.

I am actually more interested in buying than selling. Why OTC now that we have an exchange? Is this for purely liquidity reasons (not enough on the exchanges)?

[kazuki49]

I'm surprised the price for this coin isn't higher but considering how Monero is also very low, I'm not bothered. There are some interesting things happening in "alt"crypto, I can still count them with one hand but its enough to keep interest.

Bitcoin is the new IBM.

[erok]

I'm surprised the price for this coin isn't higher but considering how Monero is also very low, I'm not bothered. There are some interesting things happening in "alt"crypto, I can still count them with one hand but its enough to keep interest.

Bitcoin is the new IBM.

Well put.

The bottom line is that there are no coins getting action right now from the financial district. BTC is too volatile for a real investment and is an unfortunate stepping stone to invest into other cryptos such as this. It will take people abandoning established brands to boost this. But, while people make up their minds about what the next year holds, others accumulate when there is blood in the streets.

[smooth]

Donations

We received various donations in amounts from 100-1500 and one 10 000 along with consistent --donate blocks

Thank you to all the donators!

balance: 452706.459134109056, unlocked balance: 452668.485826029737

Previously spent: 19000 (bounties)

[smooth]

Question: Is anyone still testing the --pruning version? Any issues or other observations to report? In case you weren't aware I updated it to match 0.9.4.0 so if you are testing the older one please upgrade (just follow the original instructions and you'll get the current one).

Link to pruning test version: https://bitcointalk.org/index.php?topic=641696.msg12272943#msg12272943

Link to pruning FAQ: https://bitcointalk.org/index.php?topic=641696.msg12278027#msg12278027

[myagui]

@smooth: I'm still on the --pruning version, updated right after you had posted the equivalent 0.9.4.0 source. No issues at all to report, I get solo blocks now and then, I get a peer or two dropped as 'can't supply pruned blocks'. I've been doing as well some transactions in and out, no trouble.

I'm doing a couple of high mixin transfers now, for no particular reason. Tried mixin 500, and the daemon could not find a suitable transaction split method. I figure this is expected, as such high mixin will be attempting/generating a transaction that is too large for the current block size. A couple others with mixin 100 and 200 went through, will see if there is any that bounce.

Edit: Actually, have one odd issue, though I need to look at my logs 1st to see if I make any sense of it. It looks that my daemon was ~20 blocks behind just now, even though it had been running for over 48h, and had even found a couple of blocks in the meantime. I think it has/had many peers connected all the while, will check further.

[valkoun]

buy
Aeon coin

contaktujte me

josefvalkys@gmail.com

[myagui]

@Smooth:

Reporting back on the high mixin transfers I just did while running the light-node:
Both the 100 and 200 mixin transactions bounced (balance restored in the originating wallet after about 24 hours). I then attempted re-doing the 100 mixin transfer using a full-node, and that worked out, balance is confirmed at the receiving end.

I can imagine that the light-node would have a smaller UTXO set available to work with when building any transaction, though I would expect that the only limitation that would bring, would be a higher rate of instances where the necessary outputs for a given transaction are not available/found (when doing very high mixin values).
So, used mixin 100, and was transferring 5 aeon, while the balance on the originating wallet was exactly that of having solo mined a block the day before. In this particular instance, I don't have a clue as to what would cause the transaction to not be accepted when using the light-node, and then get accepted if done with the full-node.

About the instance where I reported that my light-node was actually some ~20 blocks behind, there's nothing meaningful in the logs. The only interesting thing that I noted, is that the moment when my node caught up with the rest of the network, was right after an automatic blockchain save (which takes just a few seconds to complete on this box). Dunno if this warrants any further investigation, could well have been an isolated case of my node running low on peers, having some external connectivity drop or something...

[smooth]

@Smooth:

Reporting back on the high mixin transfers I just did while running the light-node:
Both the 100 and 200 mixin transactions bounced (balance restored in the originating wallet after about 24 hours). I then attempted re-doing the 100 mixin transfer using a full-node, and that worked out, balance is confirmed at the receiving end.

I can imagine that the light-node would have a smaller UTXO set available to work with when building any transaction, though I would expect that the only limitation that would bring, would be a higher rate of instances where the necessary outputs for a given transaction are not available/found (when doing very high mixin values).

There shouldn't be any difference between the two, but there is randomness in how transactions are constructed. So doing the same transaction multiple times even with the same wallet-daemon-settings combination can produce different results. I'm not sure why the wallet would allow creating a transaction that doesn't get mined though. I'll double check those rules.

[smooth]

@Smooth:

Reporting back on the high mixin transfers I just did while running the light-node:
Both the 100 and 200 mixin transactions bounced (balance restored in the originating wallet after about 24 hours). I then attempted re-doing the 100 mixin transfer using a full-node, and that worked out, balance is confirmed at the receiving end.

I reviewed this some more but I don't see any reason in the code why the wallet would create transactions that wouldn't be confirmed. The wallet actually uses 125% of the base size and the default mining code (which most if not all mining nodes probably use) uses 130% so there should be some extra flexibility (though I don't see why even that would be needed) in the size before transactions fail to confirm.

If you do any more tests like this please have the daemon in log level 2 (warning this may create some larger than usual log files) and save the wallet log file file. I don't suggest posting it since it might disclose some private information but perhaps you can send it to me privately to review it. Thanks.

[cryptrol]

Is there open source software to set up a pool ? I recall having seen something posted here but can't seem to find it now.

[smooth]

Is there open source software to set up a pool ? I recall having seen something posted here but can't seem to find it now.

Yes, here is the one moneromoo is using for his pool (includes various bug fixes, etc. on the mooo branch):

https://github.com/moneromooo/cryptonote-universal-pool/tree/mooo