[ANN] AEON [2019-09-27: Upgrade to version 0.13.0.0 ASAP HF@1146200 Oct 25] - page 207.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: sammy007 on October 18, 2015, 01:34:13 AM

Quote from: Arux on October 17, 2015, 04:24:08 AM

not sure but i guess it's normal behavior, two shares found 15:13:22 but just before "Pool requested miner discard all previous work - probably new block on the network." so they are rejected ?

Low difficulty share is not a stale share. It's invalid share, maybe miner error.

Yeah it seems like this miner only partially works. Someone commented earlier that Wolf plans to work on the Monero version some more so whatever fixes get developed there should port over directly.

sammy007

legendary

Activity: 1904

Merit: 1003

Quote from: Arux on October 17, 2015, 04:24:08 AM

not sure but i guess it's normal behavior, two shares found 15:13:22 but just before "Pool requested miner discard all previous work - probably new block on the network." so they are rejected ?

Low difficulty share is not a stale share. It's invalid share, maybe miner error.

Arux

hero member

Activity: 500

Merit: 500

some rejected with win64 gpu miner

pool side:

Code:

2015-10-16 13:14:24 [pool] (Thread 1) Rejected low difficulty share of 3 from [email protected]
2015-10-16 13:14:24 [pool] (Thread 1) Share trust broken by [email protected]
2015-10-16 13:14:25 [pool] (Thread 1) height 618179, light 1
2015-10-16 13:14:25 [pool] (Thread 1) Rejected low difficulty share of 7 from [email protected]
2015-10-16 13:14:25 [pool] (Thread 1) Share trust broken by [email protected]

miner side:

Code:

[15:13:18] Share accepted: 5/5 (100.00%)
[15:13:18] Total Hashrate: 473.96H/s
[15:13:22] Thread 0: SHARE found (nonce 0x000028FC)!
[15:13:22] Thread 0: SHARE found (nonce 0x00002E87)!
[15:13:22] Thread 0: 479.06H/s
[15:13:22] Got something:{"jsonrpc":"2.0","method":"job","params":"blob":"0100f1ef83b10536db560eb216ca3dc929e5d8bdc246ba8babc8983b63c73d87db7bdfe0860ceb0000000008d0c221c867ecce6e795b20e00ea01c9fad98b92e2f50e11842e16e0fee2b801","job_id":"159169602952897","target":"4d621000"}}
[15:13:22] Pool requested miner discard all previous work - probably new block on the network.
[15:13:22] Request: {"method": "submit", "params": {"id": "293719172803685", "job_id": "159169602952897", "nonce": "fc280000","result": "05832f9750ccd0e0d3ceda8be48084cf230b15acb0d1be3f49edc98d7e6f9342"}, "id": 1}
[15:13:22] Request: {"method": "submit", "params": {"id": "293719172803685", "job_id": "159169602952897", "nonce": "872e0000", "result": "550885d78982dfbe4813585fa95558e7a3e6aea95797d3a116439c246d6f5924"}, "id": 1}
[15:13:22] Got something: {"id":1,"jsonrpc":"2.0","error":{"code":-1,"message":"Low difficulty share"}}
[15:13:22] Share rejected ((null)): 6/7 (85.71%)
[15:13:22] Total Hashrate: 479.06H/s
[15:13:22] Got something: {"id":1,"jsonrpc":"2.0","error":{"code":-1,"message":"Low difficulty share"}}
[15:13:22] Share rejected ((null)): 5/7 (71.43%)
[15:13:22] Total Hashrate: 479.06H/s
[15:13:26] Thread 0: 479.18H/s
[15:13:26] Detected new job, regenerating work.
[15:13:30] Thread 0: 479.06H/s
[15:13:34] Thread 0: 480.98H/s
[15:13:39] Thread 0: SHARE found (nonce 0x00001781)!
[15:13:39] Thread 0: 479.18H/s
[15:13:39] Request: {"method": "submit", "params": {"id": "293719172803685", "job_id": "159169602952897", "nonce": "81170000", "result": "d0bb1cbe2fea1d8a42e673b2ca7ab38231a3183b32eb34505874e6b50fc90b00"}, "id": 1}
[15:13:39] Got something: {"id":1,"jsonrpc":"2.0","error":null,"result":{"status":"OK"}}
[15:13:39] Share accepted: 6/8 (75.00%)
[15:13:39] Total Hashrate: 479.18H/s

not sure but i guess it's normal behavior, two shares found 15:13:22 but just before "Pool requested miner discard all previous work - probably new block on the network." so they are rejected ?

generalizethis

legendary

Activity: 1750

Merit: 1036

Facts are more efficient than fud

Any plans in the works for a web-wallet?

nioc

legendary

Activity: 1624

Merit: 1008

Quote from: smooth on October 15, 2015, 09:08:27 PM

Quote from: nioc on October 15, 2015, 07:25:14 PM

I am now running a Monero node using the 0.9 beta version which is using almost no resources. Can I run an Aeon node at the same time? My comp is not very powerful but it does not have much problem running Aeon. My internet connection is 30 Mbs down and 5 Mbs up and is hardwired if it makes a difference.

If you can run AEON by itself then yes you can very likely run AEON along with Monero 0.9.

Yes I ran them both with no issues. I will start Aeon again after I deal with restoring my Monero wallets.

languagehasmeaning

sr. member

Activity: 336

Merit: 250

Are there any estimates about the an official GUI will be ready? Is AEON also interested in the CT discussions from /r/Monero?

Arux

hero member

Activity: 500

Merit: 500

@Shrikez: perhaps your catalyst version (fglrx) is too old.
for opencl 2.0, you need at least catalyst 14.12 (=14.501) or above to use and SDK 3.0 to compile

check catalyst with:

Code:

ls /var/lib/dkms/fglrx/

or

Code:

ls /usr/src/fglrx*

and to verify if your OpenCL library path is ok, locate it

Code:

sudo updatedb
locate libOpenCL.so

Shrikez

sr. member

Activity: 400

Merit: 263

Arux thank you for the instructions.

Unfortunately I still can't get it to run.

the relevant part in makefile is:

Code:

CC		= gcc
LD		= gcc
CFLAGS 	= -D_POSIX_SOURCE -D_GNU_SOURCE -O0 -ggdb3 -std=c11 -pthread -c -I./include/
LDFLAGS	= -pthread -O0 -ggdb3
LIBS	= -ljansson -Wl,./lib/x86_64/sdk/libOpenCL.so -ldl

but when running the miner it still seems to be referring to /usr/lib/etc. instead of the AMD SDK bit I included in the miner folder.

Error:

Code:

./miner: /usr/lib/x86_64-linux-gnu/libOpenCL.so.1: version `OPENCL_2.0' not found (required by ./miner)

I checked the relevant path and all but.... Huh

I'm still kind of newbish on Linux so I hope in someone helping me out.

Thank you!

Arux

hero member

Activity: 500

Merit: 500

700 h/s for a 7950, it's much more efficient than win build.

i uploaded my (nasty) build on https://github.com/Arux-BTT/wolf-aeon-miner/releases. only if someone want to test without compiling itself Grin

i used mingw-w64. to achieve compilation, i added

Code:

#include

into main.c and

Code:

-lws2_32

into Makefile

BoscoMurray

sr. member

Activity: 450

Merit: 250

For reference, running the AMD GPU on Linux Mint 17.2, 7950 gives me 700H/s with the following config:

Code:

{
"index": 0,
"corefreq": 1000,
"memfreq": 1250,
"fanspeed": 65,
"powertune": 20,
"threads": 1,
"rawintensity": 2048,
"worksize": 32
}

It crashes eventually in all circumstances, but as stated it's a work in progress.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: nioc on October 15, 2015, 07:25:14 PM

I am now running a Monero node using the 0.9 beta version which is using almost no resources. Can I run an Aeon node at the same time? My comp is not very powerful but it does not have much problem running Aeon. My internet connection is 30 Mbs down and 5 Mbs up and is hardwired if it makes a difference.

If you can run AEON by itself then yes you can very likely run AEON along with Monero 0.9.

nioc

legendary

Activity: 1624

Merit: 1008

I am now running a Monero node using the 0.9 beta version which is using almost no resources. Can I run an Aeon node at the same time? My comp is not very powerful but it does not have much problem running Aeon. My internet connection is 30 Mbs down and 5 Mbs up and is hardwired if it makes a difference.

GingerAle

legendary

Activity: 1260

Merit: 1008

Wolf said that he'll be back to work on the 20th on the xmr miner, so i'm sure whatever improvements he makes will port right over.

Arux

hero member

Activity: 500

Merit: 500

Quote from: cryptrol on October 12, 2015, 12:53:32 PM

I built the win64 version of the AMD gpu miner.

done, i built mine with mingw-w64 linux but i needed to add ws2_32 lib else it fails
test on win7 x64, latest 15.7.1 catalyst

Quote from: cryptrol on October 12, 2015, 12:53:32 PM

On start there are some errors :

Code:

".\groestl256.cl", line xxx : warning: integer conversion resulted in a change
   of sign
   C64e(0x2a86ef4343692aef), C64e(0xf193a6c4c435f1a6),
   ^

Where xxx could be up to 303 and down to at least 225 (I can get the full output if needed).

idem

Quote from: cryptrol on October 12, 2015, 12:53:32 PM

Also, this :

Code:

"C:\Users\Richard\AppData\Local\Temp\OCL5F33.tmp.cl", line 228: warning: argument of
type "uchar *" is incompatible with parameter of type "uint *"
AESExpandKey256(ExpandedKey1);

not seen but not sure, i perhaps miss it

Quote from: cryptrol on October 12, 2015, 12:53:32 PM

And finally the results with the following config are 410H/s for a 7950 :

Code:

{
"Algorithms":
[
{
"name": "AEON",
"devices":
[
{
"index": 0,
"corefreq": 925,
"memfreq": 1250,
"fanspeed": 65,
"powertune": 20,
"threads": 1,
"rawintensity": 1024,
"worksize": 16
}
],
}
]
}

Same conf, 475H/s

Quote from: cryptrol on October 12, 2015, 12:53:32 PM

It seems going above 1024 makes the system unstable. Also I don't know what is the worksize param.
Anyone willing to share results ?

EDIT: It also crashes after some time with those parameters. The AMD driver crashes and miner stops.

on the first attempt, one minute of accepted then no crash but all rejected and ban...
second attempt, shares accepted but a few minutes later, shares found aren't sent to the pool. no new job received (job id didn't change) no crash but no communication between miner and pool. like BoscoMurray complain

Quote from: BoscoMurray on October 13, 2015, 03:45:44 PM

Anyone else have an issue with the new AMD miner in that it does start hashing, confirmed by hashrate on the pool, but after a while seems to stop finding/submitting shares?

The miner appear to be hashing, but the pool hashrate drops to zero. Is there some way to turn on logging?

Cheers
Bosco

proof of concept is ok but not usable for now

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: XMRpromotions on October 15, 2015, 12:12:09 AM

Have there been any efforts on getting a Poloniex listing? I just retweeted a request to add AEON and BBR on Cryptsy but can't recall much mentioned about Poloniex yet. Poloniex has by far the most CryptoNote coins so it seems like a logical exchange to focus on.

We have a better chance when either: The database merge happens and turns into a release, or AEON volume and value increases a lot. The memory footprint is a lot less than XMR, but both are still much larger than other wallets, and when you consider the number of wallets Poloniex has to run, you can understand why they wouldn't want to devote a huge amount of server RAM to one small coin.

I'm pretty confident it will happen, but we'll have to wait a while longer. Meanwhile, don't forget OTC is another option in addition to Bittrex. I'm aware of some pretty significant OTC trades that have happened recently.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: skidog on October 15, 2015, 04:54:23 AM

Quote from: Nik4691 on October 14, 2015, 08:58:10 PM

Quote from: skidog on October 14, 2015, 06:35:56 PM

Quote from: myagui on October 14, 2015, 01:40:20 PM

@skidog,

That is really low hashrate, is that for the Xeon i7, or the Xeon x3 1231 v3? This latter one has AES-NI, so it should run much faster. Perhaps that older Xeon i7 does not have AES-NI? That's really the key factor that most influences hashrate, other than cache, which sets the optimal number of threads.

XEON X3 1231 V3 I am mining using minergate. Maybe that is the problem. I can change. Using windows 7 pro 64bit. Any suggestions on a miner?

You use their application for mining, right? Do you set the number of cores more than the default 1 or 2?

My bad e3 is correct. A while back I switched out the cpu but kept the old operating system. Maybe that is causing the problem. I had a dual core Pentium cpu. It seems to lock up my computer when I try to switch to wolfs miner. I'm not sure why. Maybe I need to reinstall my operating system to take advantage of AES-NI. I can reinstall with linux. Any suggestion on which linux would work best with the wallet. I usually run MInt.

Mint should be fine, so use whatever you are comfortable with. I mostly use Ubuntu 14.04 LTS

skidog

legendary

Activity: 1393

Merit: 1001

Quote from: Nik4691 on October 14, 2015, 08:58:10 PM

Quote from: skidog on October 14, 2015, 06:35:56 PM

Quote from: myagui on October 14, 2015, 01:40:20 PM

@skidog,

That is really low hashrate, is that for the Xeon i7, or the Xeon x3 1231 v3? This latter one has AES-NI, so it should run much faster. Perhaps that older Xeon i7 does not have AES-NI? That's really the key factor that most influences hashrate, other than cache, which sets the optimal number of threads.

XEON X3 1231 V3 I am mining using minergate. Maybe that is the problem. I can change. Using windows 7 pro 64bit. Any suggestions on a miner?

You use their application for mining, right? Do you set the number of cores more than the default 1 or 2?

My bad e3 is correct. A while back I switched out the cpu but kept the old operating system. Maybe that is causing the problem. I had a dual core Pentium cpu. It seems to lock up my computer when I try to switch to wolfs miner. I'm not sure why. Maybe I need to reinstall my operating system to take advantage of AES-NI. I can reinstall with linux. Any suggestion on which linux would work best with the wallet. I usually run MInt.

XMRpromotions

sr. member

Activity: 336

Merit: 250

Quote from: smooth on October 14, 2015, 11:39:21 PM

Quote from: funnyman21 on October 14, 2015, 10:58:33 PM

Are you willing to elaborate about how the implementation you have in mind will be the soundest of current alternatives?

It already is, if people used the coin a bit more.

The biggest outstanding anonymity issue with cryptonote are the chain reaction effects described in MRL-0001, especially with mix 0. But people do seem to want to use mix 0 because it solves some problems they have with dust and also because the transactions are smaller, so cheaper when per-KB fees are implemented. BBR has a fix for that but it requires that people voluntarily tag their outputs. It isn't clear what the incentive is to do that, and there are some other issues with it, nor does it address the issue of people wanting to use low mixes because they are cheaper. XMR proposes to fix it with a minimum mix factor, but that won't happen until it is hard forked sometime next year.

In AEON the solution that is already implemented is to limit transactions with a mixin (fake outputs) of less than 2 to a maximum of one per block. Since we have four minute blocks that is only 360 per day (though not every block will necessarily have one so the actual number will be lower). As long as there are a few other transactions per block (with higher mix factors), the chain reaction can't occur and everyone's anonymity is protected. You can see for yourself in a chain explorer that when mix 1 or mix 2 transactions occur, they are always in the very first position (after coinbase). Any other transactions in a block will be higher mix.

Because of how this works, it also means that mix 0 or mix 1 transactions can still be used by people who really want a small cheaper transaction, but they will have to complete with their fee for that one slot in each block. That still should end up being somewhat cheaper, without jeopardizing the anonymity of the chain overall.

At the moment this doesn't quite work since the amount of usage is still too low. But at least we have the solution in place that if usage were to pick up the problem would fix itself.

I have some incremental anonymity improvements in my development version that will go out with normal releases (not including the security releases where I don't introduce anything new) but addressing the chain reactions is the biggest one and that is already implemented right now.

Creative solution!

The people that want to use a mixin of 0 (to avoid dust and have the lowest fees) may end up waiting for multiple blocks if volume picks up substantially. I suspect this would be a welcome problem to have as it means more people are using AEON and it would encourage mixin use to avoid delays.

Have there been any efforts on getting a Poloniex listing? I just retweeted a request to add AEON and BBR on Cryptsy but can't recall much mentioned about Poloniex yet. Poloniex has by far the most CryptoNote coins so it seems like a logical exchange to focus on.

smooth

legendary

Activity: 2968

Merit: 1198

Quote from: funnyman21 on October 14, 2015, 10:58:33 PM

Are you willing to elaborate about how the implementation you have in mind will be the soundest of current alternatives?

It already is, if people used the coin a bit more.

The biggest outstanding anonymity issue with cryptonote are the chain reaction effects described in MRL-0001, especially with mix 0. But people do seem to want to use mix 0 because it solves some problems they have with dust and also because the transactions are smaller, so cheaper when per-KB fees are implemented. BBR has a fix for that but it requires that people voluntarily tag their outputs. It isn't clear what the incentive is to do that, and there are some other issues with it, nor does it address the issue of people wanting to use low mixes because they are cheaper. XMR proposes to fix it with a minimum mix factor, but that won't happen until it is hard forked sometime next year.

In AEON the solution that is already implemented is to limit transactions with a mixin (fake outputs) of less than 2 to a maximum of one per block. Since we have four minute blocks that is only 360 per day (though not every block will necessarily have one so the actual number will be lower). As long as there are a few other transactions per block (with higher mix factors), the chain reaction can't occur and everyone's anonymity is protected. You can see for yourself in a chain explorer that when mix 1 or mix 2 transactions occur, they are always in the very first position (after coinbase). Any other transactions in a block will be higher mix.

Because of how this works, it also means that mix 0 or mix 1 transactions can still be used by people who really want a small cheaper transaction, but they will have to complete with their fee for that one slot in each block. That still should end up being somewhat cheaper, without jeopardizing the anonymity of the chain overall.

At the moment this doesn't quite work since the amount of usage is still too low. But at least we have the solution in place that if usage were to pick up the problem would fix itself.

I have some incremental anonymity improvements in my development version that will go out with normal releases (not including the security releases where I don't introduce anything new) but addressing the chain reactions is the biggest one and that is already implemented right now.

funnyman21

member

Activity: 109

Merit: 10

Quote from: smooth on 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.

Pruning and GUI will both be nice but I am most curious about your anonymity comments.

Are you willing to elaborate about how the implementation you have in mind will be the soundest of current alternatives?

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