Best work I've seen since entering cryptoworld smooth! I'm in for good. Just threw up .1BTC buy at Bittrex and gladly paid top asks 
Same here, except for a somewhat smaller amount. I have 2500 AEON at Trex.
Topic: [ANN] AEON [2019-09-27: Upgrade to version 0.13.0.0 ASAP HF@1146200 Oct 25] - page 222. (Read 625666 times)
September 02, 2015, 09:40:28 AM
Same here, except for a somewhat smaller amount. I have 2500 AEON at Trex.
September 02, 2015, 09:02:18 AM
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!
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!
September 02, 2015, 08:31:58 AM
New recommended bug fix release (0.9.3.0)
Fix bug of not using optimized hash on Windows
Improved slow-hash performance on non-AESNI
Stuck tx bug fix (from Monero)
Upgrade note: Shut down your existing node, delete your poolstate.bin file, then restart using this new version.
https://github.com/aeonix/aeon/releases/tag/v0.9.3.0
Fix bug of not using optimized hash on Windows
Improved slow-hash performance on non-AESNI
Stuck tx bug fix (from Monero)
Upgrade note: Shut down your existing node, delete your poolstate.bin file, then restart using this new version.
https://github.com/aeonix/aeon/releases/tag/v0.9.3.0
Awesome! A windows compilation when someone has a chance please
thanks...learning how to do my own this week..what a noob huh? LOL 
September 02, 2015, 07:44:47 AM
New recommended bug fix release (0.9.3.0)
Fix bug of not using optimized hash on Windows
Improved slow-hash performance on non-AESNI
Stuck tx bug fix (from Monero)
Upgrade note: Shut down your existing node, delete your poolstate.bin file, then restart using this new version.
https://github.com/aeonix/aeon/releases/tag/v0.9.3.0
Fix bug of not using optimized hash on Windows
Improved slow-hash performance on non-AESNI
Stuck tx bug fix (from Monero)
Upgrade note: Shut down your existing node, delete your poolstate.bin file, then restart using this new version.
https://github.com/aeonix/aeon/releases/tag/v0.9.3.0
September 01, 2015, 01:50:57 PM
@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 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.
Official 0.9.1.1 windows binaries were compiled with boost 1.58 static
i don't have more explanations than smooth
September 01, 2015, 09:59:06 AM
Development update
The pruning testing has gone well with no major problems reported. I will wait for testing to continue for several more days while looking into the idea of explicitly blocking older wallets from trying to restore from a pruned node.
The next major item is to be the GUI integration, which I spent some time on a while back, but put on hold to finish up pruning. I'm resuming that now.
In addition I have an additional anonymity improvement to release, which will probably come with the official pruning version. Already my opinion is that obscure little AEON has the soundest implementation of anonymity of all cryptocurrencies, with the new improvement it will be even better.
I'm also taking steps to address the mining decentralization, which I will be announcing soon.
As always feedback, suggestions, offers of assistance, donations (especially via donation mining which also helps decentralize the network), criticism, and encouragement are welcome.
The pruning testing has gone well with no major problems reported. I will wait for testing to continue for several more days while looking into the idea of explicitly blocking older wallets from trying to restore from a pruned node.
The next major item is to be the GUI integration, which I spent some time on a while back, but put on hold to finish up pruning. I'm resuming that now.
In addition I have an additional anonymity improvement to release, which will probably come with the official pruning version. Already my opinion is that obscure little AEON has the soundest implementation of anonymity of all cryptocurrencies, with the new improvement it will be even better.
I'm also taking steps to address the mining decentralization, which I will be announcing soon.
As always feedback, suggestions, offers of assistance, donations (especially via donation mining which also helps decentralize the network), criticism, and encouragement are welcome.
well tickle me curious! Is this regarding the current network's pool dominance, or an overarching fix to mining centralization???
looks like I might be buying something capable of more RAM.....
September 01, 2015, 08:43:54 AM
Best work I've seen since entering cryptoworld smooth! I'm in for good. Just threw up .1BTC buy at Bittrex and gladly paid top asks
I'm working on a non-profit charitable entity structure, planning to use crypto, with another private group that is in early stages of development. A lot of details to iron out in the foreseeable future. Aeon looking like a good candidate network, keep it rolling!!
I'm working on a non-profit charitable entity structure, planning to use crypto, with another private group that is in early stages of development. A lot of details to iron out in the foreseeable future. Aeon looking like a good candidate network, keep it rolling!!
August 31, 2015, 10:54:44 PM
Development update
The pruning testing has gone well with no major problems reported. I will wait for testing to continue for several more days while looking into the idea of explicitly blocking older wallets from trying to restore from a pruned node.
The next major item is to be the GUI integration, which I spent some time on a while back, but put on hold to finish up pruning. I'm resuming that now.
In addition I have an additional anonymity improvement to release, which will probably come with the official pruning version. Already my opinion is that obscure little AEON has the soundest implementation of anonymity of all cryptocurrencies, with the new improvement it will be even better.
I'm also taking steps to address the mining decentralization, which I will be announcing soon.
As always feedback, suggestions, offers of assistance, donations (especially via donation mining which also helps decentralize the network), criticism, and encouragement are welcome.
The pruning testing has gone well with no major problems reported. I will wait for testing to continue for several more days while looking into the idea of explicitly blocking older wallets from trying to restore from a pruned node.
The next major item is to be the GUI integration, which I spent some time on a while back, but put on hold to finish up pruning. I'm resuming that now.
In addition I have an additional anonymity improvement to release, which will probably come with the official pruning version. Already my opinion is that obscure little AEON has the soundest implementation of anonymity of all cryptocurrencies, with the new improvement it will be even better.
I'm also taking steps to address the mining decentralization, which I will be announcing soon.
As always feedback, suggestions, offers of assistance, donations (especially via donation mining which also helps decentralize the network), criticism, and encouragement are welcome.
August 31, 2015, 07:43:39 PM
... I always try and break stuff.
Oh, you are that guy!
August 31, 2015, 07:42:19 PM
@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 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 always try and break stuff. August 31, 2015, 07:40:05 PM
@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 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.
August 31, 2015, 07:33:33 PM
@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!
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!
August 31, 2015, 07:31:01 PM
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??
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??
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!
August 31, 2015, 07:14:28 PM
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??
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??
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.
August 31, 2015, 07:10:46 PM
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??
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??
August 31, 2015, 06:40:48 PM
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
August 31, 2015, 06:04:23 PM
@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.
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.
August 31, 2015, 05:56:07 PM
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...
August 31, 2015, 05:54:06 PM
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...
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.
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.
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.
August 31, 2015, 05:44:16 PM
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.
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.
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.
Jump to: