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

[SRBOOTH]

@SRBOOTH:

There's no external GPU solo miners for any cryptonote as far as I know. Most definitely not for nvidia, since ccminer will only work with pools. If you really want to solo mine with nvidias (or AMDs AFAIK), you'll need to setup a private pool. That should be an interesting/fun project btw.   Happy Mining!

Edit: on the pruned version compiled for windows, I've posted (unofficial) binaries just yesterday:
https://bitcointalk.org/index.php?topic=641696.msg12285871#msg12285871

Official ones should not take long I suppose, since Arux is back from all his summer partying  

Edit ^2: the light-node (pruned) working well for me so far. I have made a couple of transfers without any issues, I have solo mined a block, and have gone through the cycle seeing a misbehaving peer get blocked. Good stuff!   

Sweet!! and thanks for the info @myagui !! I am going to try and set a pool up for myself , I think smooth was looking to do the same.

[1714053431]

1714053431

[1714053431]

1714053431

[1714053431]

1714053431

[1714053431]

1714053431

[exciter0]

Can somebody give me a brief summary of what I need to do to set up a pool. I've done it a few times before (for XMR) but I'm not really up on which versions of the code to use for AEON, any patches needed, etc.

Post if you feel it is of general interest, otherwise PM.

Thanks!

Pretty much the same steps to getting a xmr pool working. Use MoneroMoo's fork, he has already added CN-lite.

Trying to remember the steps here, I used Ubuntu 15.04, but should be the same steps as on 14.04...

Assuming everything's installed on the same server, start up the daemon and simplewallet:

Code:

aeond --rpc-bind-ip 1.2.3.4 --rpc-bind-port 9998
simplewallet --wallet-file aeon-pool-wallet.bin --daemon-address 1.2.3.4:9998

I used non-default rpc port 9998 since I run many pools on the same server ;-)

Then install the pre-reqs and the pool code:

Code:

apt-get install git redis-server libboost1.55-all-dev nodejs-dev nodejs-legacy npm cmake libssl-dev
service redis-server start
git clone https://github.com/moneromooo/cryptonote-universal-pool aeon-pool
cd aeon-pool 
git checkout aeon-light
npm rebuild

Then edit  ~/aeon-pool/config.json
I disabled payments since it's a private pool...and I made sure the pool fee is 100%  

Code:

{
    "coin": "AEON",
    "symbol": "AEON",

 ...

    "poolServer": {
        "enabled": true,
        "clusterForks": "auto",
        "poolAddress": "WmthHeYEvTz5kSgsJviaVKEEExkRZZLduB5pfrJ2aWWf3m1dE7PTvdxKVyc9MAuhbCSisqe69uopkKiq2rbxbpzY2zeRRMGAp",
        "blockRefreshInterval": 500,
        "minerTimeout": 5000,
        "ports": [
            {
                "port": 5555,
                "difficulty": 30000,
                "desc": "Mid range hardware"
            },
            {
                "port": 4321,
                "difficulty": 40000,
                "desc": "High end hardware"
            }

...

    "payments": {
        "enabled": false,
        "interval": 600,
        "maxAddresses": 50,
        "mixin": 0,
        "transferFee": 5000000000,
        "minPayment": 100000000000,
        "denomination": 100000000000
    },
    "api": {
        "enabled": true,
        "hashrateWindow": 600,
        "updateInterval": 5,
        "port": 8118,
        "blocks": 30,
        "payments": 30,
        "password": "secret"
    },

    "daemon": {
        "host": "1.2.3.4",
        "port": 9998
    },

    "wallet": {
        "host": "1.2.3.4",
        "port": 8082
    },

    "redis": {
        "host": "127.0.0.1",
        "port": 6379
    }

start the pool with node init.js

Open another terminal and install your favorite web server:
apt-get install nginx
copy the aeon pool web pages to the doc root directory

Code:

mkdir /var/www/html/aeon
cp ~/aeon-pool/website-example/* /var/www/html/aeon

edit /var/www/html/aeon/config.js

Code:

var api = "http://1.2.3.4:8118";

var coinUnits = 1000000000000;

var poolHost = "1.2.3.4";

var irc = "irc.freenode.net/#";

var email = "support@localhost";

var cryptonatorWidget = ["AEON-BTC", "AEON-USD"];

var easyminerDownload = "https://github.com/zone117x/cryptonote-easy-miner/releases/";

var blockchainExplorer = "http://chainradar.com/aeon/block/";

var transactionExplorer = "http://chainradar.com/aeon/transaction/";

I think there's one more edit to either /var/www/html/aeon/index.html or /var/www/html/aeon/pages/home.html to get the hashrate to report correctly...

EDIT:  Here we go, you need to edit /var/www/html/aeon/pages/home.html to get it to show the hashrate properly...change from 60 to 240

Code:

       update: function(){

            $('#networkLastBlockFound').timeago('update', new Date(lastStats.network.timestamp * 1000).toISOString());

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

Credits to Moneromoo, he helped me out through PM and from his postings.

[smooth]

Apologies for this TLDR question: Do I need to run the client on each comp where I want solo (gpu)?

The only way to solo mine with a GPU is to run your own pool, since the built in daemon miner can't GPU mine and the GPU miners can't connect directly to the daemon. As I am looking at setting up a pool I may have more advice on this later. EDIT: I see exciter0 posted some instructions. Thanks exciter0!

Likewise, if you run your own pool you can have as many of your own computers connecting to it as you want and you are still effectively solo mining.

[SRBOOTH]

Apologies for this TLDR question: Do I need to run the client on each comp where I want solo (gpu)?

The only way to solo mine with a GPU is to run your own pool, since the built in daemon miner can't GPU mine and the GPU miners can't connect directly to the daemon. As I am looking at setting up a pool I may have more advice on this later. EDIT: I see exciter0 posted some instructions. Thanks exciter0!

Likewise, if you run your own pool you can have as many of your own computers connecting to it as you want and you are still effectively solo mining.

Very nice!! yes thank you exciter0 ....I'm  running Windows 2008 on a Dell R410...But I'm thinking of wiping it for Linux. I'm decent at Linux and need to keep learning, any suggestions for what flavor to run on that server so as to use it as a pool machine??  Or anyone out there with a cryptonote pool "how to " for Windows?

[exciter0]

Pruning (aka Light Full Node) test release

This release optionally prunes the blockchain by dropping no-longer-needed information once it is processed and verified by your node.

I had a chance to test this out. It freed up about 1GB in both RAM and file size for blockchain-pruned.bin
This is a significant saving, indeed!

However, I wonder if users should really run pruned nodes knowing LMDB will be added in the near future.
Additionally, they might unknowingly run a pruned node and find out some of their coins may not be showing up in the balance. I tested an old wallet and sure enough, with pruned blocks simplewallet cannot verify all so my total balance of coin came up less than expected. Is there a safeguard in simplewallet that can be implemented to tell the user that he must synch with an archive node?

I realized many are bitching about not having enough memory to run the daemon and such, and this is a great solution; but let's get real....4 extra GB of RAM is less than $20 these days so everyone should have at least 8GB RAM on their systems.  
But I'm guessing pruned nodes are targeted for mobile devices?

[exciter0]

Apologies for this TLDR question: Do I need to run the client on each comp where I want solo (gpu)?

The only way to solo mine with a GPU is to run your own pool, since the built in daemon miner can't GPU mine and the GPU miners can't connect directly to the daemon. As I am looking at setting up a pool I may have more advice on this later. EDIT: I see exciter0 posted some instructions. Thanks exciter0!

Likewise, if you run your own pool you can have as many of your own computers connecting to it as you want and you are still effectively solo mining.

Very nice!! yes thank you exciter0 ....I'm  running Windows 2008 on a Dell R410...But I'm thinking of wiping it for Linux. I'm decent at Linux and need to keep learning, any suggestions for what flavor to run on that server so as to use it as a pool machine??  Or anyone out there with a cryptonote pool "how to " for Windows?

You can always run ubuntu as a hyperv VM... or better yet, run Windows 2008 as a linux KVM VM. As for myself, I run my pool as a vm on VMware esxi. I would stick with plain Ubuntu, even though Linux Mint is more pleasing visually.

[smooth]

Pruning (aka Light Full Node) test release

This release optionally prunes the blockchain by dropping no-longer-needed information once it is processed and verified by your node.

I had a chance to test this out. It freed up about 1GB in both RAM and file size for blockchain-pruned.bin
This is a significant saving, indeed!

However, I wonder if users should really run pruned nodes knowing LMDB will be added in the near future.

It's complementary. The disk savings are permanent and ever-increasing. The current LMDB doubles the starting disk footprint too, although hopefully that ratio can be improved.

Additionally, they might unknowingly run a pruned node and find out some of their coins may not be showing up in the balance. I tested an old wallet and sure enough, with pruned blocks simplewallet cannot verify all so my total balance of coin came up less than expected. Is there a safeguard in simplewallet that can be implemented to tell the user that he must synch with an archive node?

Now that's odd. I don't think any received payments should be missing (so for example fully cold storage wallets are okay to do this) only if you had made payments out of the wallet those would not be rescanned.

If you can take a closer look and maybe provide details (PM is okay) that would be helpful.

I realized many are bitching about not having enough memory to run the daemon and such, and this is a great solution; but let's get real....4 extra GB of RAM is less than $20 these days so everyone should have at least 8GB RAM on their systems.  
But I'm guessing pruned nodes are targeted for mobile devices?

The storage savings is a big deal for mobile and embedded devices (we want people to run always-on nodes at very low power and cost) but also for cheap computers. There are a bunch of $100-$150 laptops now that are quite usable but ship with 32 GB of SSD storage, non-upgradable. They'll run AEON nodes just fine but not if the blockchain grows to much. Bitcoin has a 40 GB blockchain right now. Not even possible to run an unpruned node on those computers even if you wanted to.

[SRBOOTH]

I just ran pruned client , double checking instructions and didn't see any reduction in RAM usage. Copied blockchain.bin to desktop, renamed blockchain-pruned.bin, pasted back into appdata Aeon folder. Run new client, saw pruning in the log, save after sync. Re-run client as batch file (aeond.exe --pruning) , resync and rechecked RAM useage is the same. Did I miss something? 

[exciter0]

I should clarify, I did a rescan connected to a pruned node using my wallet.keys file, so it scanned from the beginning...
Had I used my synched up wallet file then yes my balance would not be affected.  

Now that's odd. I don't think any received payments should be missing (so for example fully cold storage wallets are okay to do this) only if you had made payments out of the wallet those would not be rescanned.

If you can take a closer look and maybe provide details (PM is okay) that would be helpful.

[smooth]

Yes I understood. The balance should be higher than the correct number, not lower, because all incoming payments should be there but outgoing may not. If you see something different please report it.

EDIT: Also, for this reason, there is no risk of losing coins even making the mistake of rescanning with a pruned node. You just may get a balance that is higher than correct, and some payments may fail if they try to spend coins that were actually spent already. But I think it should also be possible to fix the node so it will refuse to allow wallet scanning of old blocks if running in pruned mode, so that would give a clean error message instead of confusing results. I'll look into that.

I should clarify, I did a rescan connected to a pruned node using my wallet.keys file, so it scanned from the beginning...
Had I used my synched up wallet file then yes my balance would not be affected.  

Now that's odd. I don't think any received payments should be missing (so for example fully cold storage wallets are okay to do this) only if you had made payments out of the wallet those would not be rescanned.

If you can take a closer look and maybe provide details (PM is okay) that would be helpful.

[exciter0]

My mistake!  You are absolutely right, my balance ended up much more than actual... my poor eyes missed an extra digit in my rescanned balance.   

Agree on adding feature to prevent scanning of old blocks...

Yes I understood. The balance should be higher than the correct number, not lower, because all incoming payments should be there but outgoing may not. If you see something different please report it.

EDIT: Also, for this reason, there is no risk of losing coins even making the mistake of rescanning with a pruned node. You just may get a balance that is higher than correct, and some payments may fail if they try to spend coins that were actually spent already. But I think it should also be possible to fix the node so it will refuse to allow wallet scanning of old blocks if running in pruned mode, so that would give a clean error message instead of confusing results. I'll look into that.

I should clarify, I did a rescan connected to a pruned node using my wallet.keys file, so it scanned from the beginning...
Had I used my synched up wallet file then yes my balance would not be affected.  

Now that's odd. I don't think any received payments should be missing (so for example fully cold storage wallets are okay to do this) only if you had made payments out of the wallet those would not be rescanned.

If you can take a closer look and maybe provide details (PM is okay) that would be helpful.

[exciter0]

I just ran pruned client , double checking instructions and didn't see any reduction in RAM usage. Copied blockchain.bin to desktop, renamed blockchain-pruned.bin, pasted back into appdata Aeon folder. Run new client, saw pruning in the log, save after sync. Re-run client as batch file (aeond.exe --pruning) , resync and rechecked RAM useage is the same. Did I miss something? 

You may need to reboot windows to free up the RAM
Reboot and run the daemon again to see the reduction...

[myagui]

@SRBOOTH:

Also, a quick look at the AEON appdata folder will tell you if pruning executed correctly at least once (and saved).
You should find that blockchain.bin is about 2.8GB, while blockchain-pruned.bin is about 1.66GB.

[SRBOOTH]

Thank you exciter0 and myagui, you both were correct , here is results...the RAM usage was commonly at 3.87GB and is now at a steady 3.1GB, I happened to shoot it at 3.67GB

[SRBOOTH]

Just tried to run full client and fails.....logfile report states

15-Aug-31 17:07:29.363946 aeon v0.9.1.1()
2015-Aug-31 17:07:29.382046 Module folder: aeond
2015-Aug-31 17:07:29.392046 Initializing p2p server...
2015-Aug-31 17:07:29.409547 ERROR c:\users\user\aeon\src\p2p\net_node.inl:110 Exception at [node_server::init_config], what=unsupported version
2015-Aug-31 17:07:29.427647 ERROR c:\users\user\aeon\src\p2p\net_node.inl:273 Failed to init config.
2015-Aug-31 17:07:29.448247 ERROR C:\Users\user\aeon\src\daemon\daemon.cpp:174 Failed to initialize p2p server.
2015-Aug-31 17:07:29.463847 Mining has been stopped, 0 finished


Light version starts and runs ok......
Help??

[smooth]

Just tried to run full client and fails.....logfile report states

15-Aug-31 17:07:29.363946 aeon v0.9.1.1()
2015-Aug-31 17:07:29.382046 Module folder: aeond
2015-Aug-31 17:07:29.392046 Initializing p2p server...
2015-Aug-31 17:07:29.409547 ERROR c:\users\user\aeon\src\p2p\net_node.inl:110 Exception at [node_server::init_config], what=unsupported version
2015-Aug-31 17:07:29.427647 ERROR c:\users\user\aeon\src\p2p\net_node.inl:273 Failed to init config.
2015-Aug-31 17:07:29.448247 ERROR C:\Users\user\aeon\src\daemon\daemon.cpp:174 Failed to initialize p2p server.
2015-Aug-31 17:07:29.463847 Mining has been stopped, 0 finished


Light version starts and runs ok......
Help??

You need version 0.9.2.0. Or you can delete your p2pstate.bin file.

EDIT: "unsupported version" indicates an incompatibility with the boost version used to compile the binary, not with the version of AEON being used. If the problem had to do with AEON the message might be "unsupported class version" though it isn't clear to me the class version was even changed on the peerlist file.  

Anyway, I'll note in the future that preserving all of your .bin files before using test versions is a good idea. For now you will need to either delete the offending .bin file (probably peerstate.bin) or keep using the test version (you can run unpruned if you want by removing the --pruning" flag) or talk to the people who are building the binaries about using consistent boost versions.

[SRBOOTH]

Just tried to run full client and fails.....logfile report states

15-Aug-31 17:07:29.363946 aeon v0.9.1.1()
2015-Aug-31 17:07:29.382046 Module folder: aeond
2015-Aug-31 17:07:29.392046 Initializing p2p server...
2015-Aug-31 17:07:29.409547 ERROR c:\users\user\aeon\src\p2p\net_node.inl:110 Exception at [node_server::init_config], what=unsupported version
2015-Aug-31 17:07:29.427647 ERROR c:\users\user\aeon\src\p2p\net_node.inl:273 Failed to init config.
2015-Aug-31 17:07:29.448247 ERROR C:\Users\user\aeon\src\daemon\daemon.cpp:174 Failed to initialize p2p server.
2015-Aug-31 17:07:29.463847 Mining has been stopped, 0 finished


Light version starts and runs ok......
Help??

You need version 0.9.2.0. Or you can delete your p2pstate.bin file.

EDIT: "unsupported version" indicates an incompatibility with the boost version used to compile the binary, not with the version of AEON being used. If the problem had to do with AEON the message might be "unsupported class version" though it isn't clear to me the class version was even changed on the peerlist file.  

Anyway, I'll note in the future that preserving all of your .bin files before using test versions is a good idea. For now you will need to either delete the offending .bin file (probably peerstate.bin) or keep using the test version (you can run unpruned if you want by removing the --pruning" flag) or talk to the people who are building the binaries about using consistent boost versions.

Thank smooth, great!

[myagui]

@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!

[smooth]

@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!

I'm not sure, as I was only vaguely aware of this issue, and the boost documentation is rather poor. Looking in the release notes, I see nothing about version incompatibility since 1.45, which is quite old (none of the AEON builds would have used something older than that right?):

http://www.boost.org/doc/libs/1_59_0/libs/serialization/doc/release.html

So I don't see a good reason for the "unsupported version" failure to occur at all. Maybe there is another explanation.

Still, let's get Arux to report on the boost version being used for the official Windows builds and people can try to use the same version for unofficial builds as well.

[SRBOOTH]

@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!

I did just that with 9.2 (without pruning) It is "upgrading blockchain format" as I type this   I always try and break stuff.