Author

Topic: [ANN] AEON [2019-09-27: Upgrade to version 0.13.0.0 ASAP HF@1146200 Oct 25] - page 190. (Read 625666 times)

hero member
Activity: 500
Merit: 500
Anyone mining at Miner Gate?

Can't find any connection info for pool now.

Certainly some people are using minergate but please use one of the pools in the OP if you can to spread out the hash rate.

and don't be afraid to mine on small pool (or solomine), on a long period, your reward will be the same. (Paid less often but bigger amount)

this is the stats of my pool:

at the end, the average luck is still going close to 100%
i don't know minergate stats but it sould be similar.

for now, http://98.238.231.31:9000/#pool_blocks seems unlucky but it won't last. i put 1kh/s on it because of several reasons: spread the hash (my pool can survive a drop of 1khs),  no loss of efficiency on long period (after a unlucky series, there is a lucky one) and help to maintain several pool active.
legendary
Activity: 1246
Merit: 1000
ARK Team likes to ban and delete posts in reddit.
https://twitter.com/aeoncurrency/status/687654160045617153

Its poll time. Cast your vote!

When should we ask @Poloniex to list #aeon alongside its other #CryptoNote coins like #monero and #boolberry?

1. Now
2. After LMDB
3. After GUI


Please vote now if you have not already. There are just a few hours left in the 24 hour poll. The vote is currently tied between options 1 and 2 with 44% each with option 3 a distant 3rd at 12%

Final poll results:
24 votes
38% Now
46% After LMDB
16% After GUI


Is there any timeline for LMDB integration?

Bump ttt
legendary
Activity: 2968
Merit: 1198
Anyone mining at Miner Gate?

Can't find any connection info for pool now.

Certainly some people are using minergate but please use one of the pools in the OP if you can to spread out the hash rate.
legendary
Activity: 1400
Merit: 1000
Anyone mining at Miner Gate?

Can't find any connection info for pool now.
sr. member
Activity: 450
Merit: 250
Might want to play with settings in conf file a bit, I think I'm getting over 900 with 270 and almost 1100 h/s with 7950 using raw intensities of 768 and 1024, respectively. Can't swear to it because I'm not at home atm, but I'll check later...

Aye, cheers. It's better now. I had rawintensity of 2048. Now set at 1024 the 7950 is giving 1000 H/s.
newbie
Activity: 58
Merit: 0
I was also getting that error on an R7370. I got it set now at 1200 and im getting 1100h/s now. Any higher and my hash decreases. If i go lower than 1200 i get that error
legendary
Activity: 3136
Merit: 1116
Quote from: BoscoMurray
...

Edit: 7950 hashrate gone from ~650 to 905 with little CPU use, so my CPU is rocking it's full potential now too. Good work Wolf

Might want to play with settings in conf file a bit, I think I'm getting over 900 with 270 and almost 1100 h/s with 7950 using raw intensities of 768 and 1024, respectively. Can't swear to it because I'm not at home atm, but I'll check later...

edit: My mistake: more like 1000 on 7950, maybe up to 1025 h/s with rawintensity of 1024, and apparently 270 crashed at some point in the day. Trying it now with rawintensity set at 712 and getting ~880 h/s with 270.

editedit: Even at 712 the 270 crashed after a couple minutes with -61 error failed to enqueue or something. Seems to be working with a rawintensity of only 512, but only getting 610 h/s. Gonna mess with it some more and will add an editeditedit at some point in the future.

editeditedit: Even 640 is too high, gives this error:
Code:
[17:13:13] Error -63 when calling clEnqueueNDRangeKernel for kernel 6.

editediteditedit: Even 512 crashed after a short time with same error...
sr. member
Activity: 450
Merit: 250
Code:
main.c: In function ‘SetupXMRTest’:
main.c:502:8: error: unknown type name ‘cl_queue_properties’
  const cl_queue_properties CommandQueueProperties[] = { 0, 0, 0 };
seems correlated to opencl

check if catalyst is ok
Code:
fgl_glxgears

try to type your OpenCL 2 headers path into Makefile
Code:
CFLAGS = -D_POSIX_SOURCE -D_GNU_SOURCE $(OPT) -pthread -c -std=c11 -I/home/user/AMDAPPSDK-3.0/include
and perhaps path to OpenCL lib
Code:
LIBS = -ljansson -L/home/user/AMDAPPSDK-3.0/lib -lOpenCL -ldl


Aha, yes! Thanks. Previously I'd been adding extra paths to CFLAGS and LIBS, I think due to the way I must have installed things. On this occasion I'd forgotten the CFLAGS path.

Here's my CFLAGS and LIBS, incase it helps anyone else:
Code:
CFLAGS = -D_POSIX_SOURCE -D_GNU_SOURCE $(OPT) -pthread -c -std=c11 -I./include/
Code:
LIBS = -ljansson -Wl,./lib/x86_64/sdk/libOpenCL.so -lOpenCL -ldl


Edit: 7950 hashrate gone from ~650 to 905 with little CPU use, so my CPU is rocking it's full potential now too. Good work Wolf
hero member
Activity: 500
Merit: 500
Code:
main.c: In function ‘SetupXMRTest’:
main.c:502:8: error: unknown type name ‘cl_queue_properties’
  const cl_queue_properties CommandQueueProperties[] = { 0, 0, 0 };
seems correlated to opencl

check if catalyst is ok
Code:
fgl_glxgears

try to type your OpenCL 2 headers path into Makefile
Code:
CFLAGS = -D_POSIX_SOURCE -D_GNU_SOURCE $(OPT) -pthread -c -std=c11 -I/home/user/AMDAPPSDK-3.0/include
and perhaps path to OpenCL lib
Code:
LIBS = -ljansson -L/home/user/AMDAPPSDK-3.0/lib -lOpenCL -ldl
member
Activity: 109
Merit: 10
First, PoS is feasible but not in the short term. There are no other working implementations of cryptonote PoS yet, and developing one is beyond the resources available to this project right now. The only exception to that is the DPoS in XPB, which somewhat different from regular PoS, and not something I would like to pursue. Once there are open source implementations of cryptonote PoS we can consider adopting one. I lean toward a PoW+PoS hybrid that slowly tends toward PoS over time.

Second, the direction I would like to go is toward with this coin is to experiment with a lighter-weight variation of cryptonote that will be friendlier as a payment system for smartphones and other mobile devices. This requires initially some small tweaks and later significant blockchain improvements:

1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.

2. Increased block time for fast syncing. The block time determines the number of blocks (or headers) that need to downloaded for syncing on a lightweight client, and in addition, most AEON blocks are currently empty, which is creating wasteful bloat. Finally, all cryptonote coins have higher verification costs compared with BTC forks which leads to more orphans. Instead we should use a 4 minute blocktime, which will reduce sync time by a factor of four, and reduce orphans to a minimum. Coupled with #1 we should improve sync time on lower end devices by at least 10x. Per-block rewards will be increased by 4x to maintain the same emission schedule.

3. Signature trimming for SPV-like clients. a) tweak the transaction format using a variation of the techniques from BBR. b) add a flag to the p2p to allow lightweight clients to not download and verify signatures. They would rely on miners to maintain the integrity of the blockchain, as with SPV wallets. Full nodes will continue to store the entire chain with all signatures.

4. Blockchain pruning for scalability. I propose to expire parts of the chain altogether. After some period of time unspent coins would become unspendable and could be pruned. This will allow the blockchain to stay small forever, and not outgrow small devices. Wallets will need to automatically respend coins that are approaching the expiration window back to the same wallet, or at least recommend that the user do so. There will be a longer grandfather period for existing coins but eventually they too would expire. A way of doing long-term (but not infinite) cold storage with a prepaid storage fee may be added later (likely along with multisig). This will also improve anonymity by reducing age-based attacks.

5. Multisig and payment channels for escrow, contracts and instant payments. Cryptonote coins currently rely on a very lightweight hard-coded scripting system that makes transactions very small, easy to verify, and more secure than full-fledged scripts. I would like to maintain that lightweight system, but add a few more hard-coded cases as required for multisig (escrow, and some forms of contracts) and payment channels (trustless instant payments). This will also require a tool set (library and applications) for implementing the real-time components of payment channels.

Roadmap (schedule target, subject to change according to available resources)

1,2. Tweaked PoW, blocktime (1 week)
2.1. Cryptonote GUI wallet integration (*)
3. Signature trimming  (1-2 month*)
4. Blockchain pruning (3-4 months*)
5. Multisig and payment channels (6 months*)

* subject to evaluation of wallet integration task

Also (planned but no specific schedule)

A. 32-bit and ARM support
B. Database or collection swapping (low memory footprint)

Although my interests are primarily in the area of blockchain technology and experimental improvements to the cryptonote protocol, I invite others to join the project and work on other items such as a GUI wallet (though we can likely adapt existing GUI wallets from other cyptonote coins), mobile wallets, marketing, etc.

I have created a new donation address for the project. The amount of donations received will have some influence on the pace of work, largely because it allows me to gauge the interest of the community in a credible way, and I'm less interested in working on something that no one cares about.

Code:
Generated new wallet: WmsSWgtT1JPg5e3cK41hKXSHVpKW7e47bjgiKmWZkYrhSS5LhRemNyqayaSBtAQ6517eo5PtH9wxHVmM78JDZSUu2W8PqRiNs
view key: 71bf19a7348ede17fa487167710dac401ef1556851bfd36b76040facf051630b

EDIT: Added 32-bit and ARM support, low memory

EDIT: Added cryptonote GUI wallet integration

Is there any way this schedule can be updated? The pruning branch and mining improvements have helped Aeon already.
sr. member
Activity: 352
Merit: 250
error was spotted, i forgot to paste a line Grin

code is compiling fine now:
Code:
git clone https://github.com/Arux-BTT/wolf-aeon-miner your_local_folder
cd your_local_folder
git branch substantial_performance_increase
make

latest win64 build is solving the high cpu usage.
https://github.com/Arux-BTT/wolf-aeon-miner/releases
win64 build is just fine. A little more h/s and 0% CPU usage.
sr. member
Activity: 450
Merit: 250
error was spotted, i forgot to paste a line Grin

code is compiling fine now:
Code:
git clone https://github.com/Arux-BTT/wolf-aeon-miner your_local_folder
cd your_local_folder
git branch substantial_performance_increase
make

latest win64 build is solving the high cpu usage.
https://github.com/Arux-BTT/wolf-aeon-miner/releases

Thanks Arux. Still no go here though. I'm now getting this:

Code:
main.c: In function ‘SetupXMRTest’:
main.c:502:8: error: unknown type name ‘cl_queue_properties’
  const cl_queue_properties CommandQueueProperties[] = { 0, 0, 0 };

hero member
Activity: 500
Merit: 500
May i suggest that in the future instead of posting all the revision directly to github you do some kind of regression tests so such errors can't pop up to who always update to the last commit but happens in a test enviroment? Is just a tip not some kind of offense anyway
you're right. i should have tested but I was interrupted then time was lacking...
next time, i'll push into a distinct branch if untested.

be aware of: my repo is only a unofficial temporary (and dirty) solution in waiting of official wolf's update. (if any)
full member
Activity: 182
Merit: 100
★YoBit.Net★ 350+ Coins Exchange & Dice
error was spotted, i forgot to paste a line Grin

code is compiling fine now:
Code:
git clone https://github.com/Arux-BTT/wolf-aeon-miner your_local_folder
cd your_local_folder
git branch substantial_performance_increase
make

latest win64 build is solving the high cpu usage.
https://github.com/Arux-BTT/wolf-aeon-miner/releases

May i suggest that in the future instead of posting all the revision directly to github you do some kind of regression tests so such errors can't pop up to who always update to the last commit but happens in a test enviroment? Is just a tip not some kind of offense anyway
hero member
Activity: 500
Merit: 500
error was spotted, i forgot to paste a line Grin

code is compiling fine now:
Code:
git clone https://github.com/Arux-BTT/wolf-aeon-miner your_local_folder
cd your_local_folder
git branch substantial_performance_increase
make

latest win64 build is solving the high cpu usage.
https://github.com/Arux-BTT/wolf-aeon-miner/releases
sr. member
Activity: 450
Merit: 250
Have dependencies on the miner changed since the last iteration? I cloned from Arux's substantial_performance_increase branch, copied relevant include and lib directories for the SDK stuff, as I've done before, but when trying make I get this:

Code:
main.c:1104:25: error: ‘QueueMutex’ undeclared (first use in this function)
     pthread_mutex_lock(&QueueMutex);

Any help appreciated.

Sorry , i make a mistake on one of the last six commit. I'm afk until this evening (perhaps tomorrow).
The last commit tested successfully is the c456fa3828.
Use it until i found the error:
Code:
git checkout c456fa3828
must rollback at non buggy code.

No bother. Thanks for doing it at all! Wink
hero member
Activity: 500
Merit: 500
Have dependencies on the miner changed since the last iteration? I cloned from Arux's substantial_performance_increase branch, copied relevant include and lib directories for the SDK stuff, as I've done before, but when trying make I get this:

Code:
main.c:1104:25: error: ‘QueueMutex’ undeclared (first use in this function)
     pthread_mutex_lock(&QueueMutex);

Any help appreciated.

Sorry , i make a mistake on one of the last six commit. I'm afk until this evening (perhaps tomorrow).
The last commit tested successfully is the c456fa3828.
Use it until i found the error:
Code:
git checkout c456fa3828
must rollback at non buggy code.
sr. member
Activity: 450
Merit: 250
Have dependencies on the miner changed since the last iteration? I cloned from Arux's substantial_performance_increase branch, copied relevant include and lib directories for the SDK stuff, as I've done before, but when trying make I get this:

Code:
main.c:1104:25: error: ‘QueueMutex’ undeclared (first use in this function)
     pthread_mutex_lock(&QueueMutex);

Any help appreciated.
sr. member
Activity: 352
Merit: 250
awaiting for wolf's binaries, i copied his recent work (from xmr miner) into my repo https://github.com/Arux-BTT/wolf-aeon-miner (branch: substantial_performance_increase)
Code:
git clone https://github.com/Arux-BTT/wolf-aeon-miner your_local_folder
cd your_local_folder
git branch substantial_performance_increase
make

hashing at ~1080h/s (vs ~800 before).  feel free to use it, windows64 build available at https://github.com/Arux-BTT/wolf-aeon-miner/releases

Thanks Arux. My little Pitcairn HD7850 went from 420 to 630h/s.
Unfortunately, it still cuts 100h/s out of 850h/s from my 8core FX processor because of high CPU usage.
Its a great improvement anyway.


Tell him to pull again, CPU usage issue should be fixed.
And of course, the first thanks goes to you, legendary Wolf0   Smiley
legendary
Activity: 2968
Merit: 1198
I have decided to help both you and Boolberry because your communities have been supportive of Monero and have helped to advance CryptoNote innovation. If Shapeshift decides to add more CryptoNote coins I believe AEON and BBR should be next

https://twitter.com/XMRpromotions/status/689328498893144064

I will also send Shapeshift a follow up email

I was assuming that you and 'aeoncurrency' were the same person.

Confirm?

Who cares? https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_you%27re_a_dog

I welcome any effective support.
Jump to: