Not sure who to exactly reply to, but for MacOS users of Java miner, my apologies but I do not include an argon2i library precompiled, as I don't have a mac to do so on. Please compile using the Linux instructions on the release page, which will hopefully work. Let me know if they don't.

@wenjiannin -- just to confirm, this voting is for Arionum or is it for the MUT rebrand "Arion" -- also, they had previously agreed to use ARION instead of ARO as their ticker, to avoid this confusion, does this indicate that they have backed out of that agreement?

Basically, Arionum != Arion. Arion is a rebrand of MUT; Arionum is a new blockchain with no relationship to prior projects.

Java miner also does multithreading (more then one hasher) and also supports affinity, and best-effort stable memory use for max speeds.

Read a bit about it here: https://forum.arionum.com/viewtopic.php?f=11&t=28

Ryzen 1700x with a good (max memory channels, high bandwidth) memory layout can get 25-30h/s iirc. Some tweaking may be required, it would be best to join the discord #mining channel so that other Ryzen owners could give you a hand.

Well, given your statements, you clearly did not know for Arionum; I made no statement about Bitcoin.

Bitcoin is vulnerable to miner collusion at 51% because miners choose transactions.

Pointing out that Arionum is different, I had hoped, would clear up your confusion why those of us who are aware of how Arionum works recognize that small numbers of miners with large hashrates aren't concerning along the FUD dimension you mentioned.

Hope that clears it up for you.

A lot of folks are confusing some perceived lack of fairness of miners "reward" with a failure to decentralize.

Again, transactions are _not_ picked by miners. Miners _confirm_ via "discovering" a valid hash for proto-blocks that _nodes_ pick. Not miners.

So, a few miners having a large % of the hashrate isn't alarming from a decentralization standpoint, these guys are just spending lots of money to acquire more ARO very early in the project. This is a valid choice for them; it doesn't hurt ARO 'cept for FUD'ders who haven't bothered reading about ARO or understanding where the decentralization comes from.

Decentralization of transaction / block formation / validation of blocks --> these tasks happen at the nodes, not the miners.

Miners are not the sources of decentralization for this coin...

Not sure how else I can describe it, since people seem intent on ignoring this.

After you find your first valid nonce, your address will show up in the Historic section of the pool. (main page -- scroll down).

All the current miners use a C++/C library under the covers via various abstractions. _Currently_ there is no pure C++ miner that I'm aware of

Awesome, glad to hear that solved it!

Hmm, so, channels of memory is basically, check your physical placement of memory modules on the motherboard -- they should be in the pattern that the motherboard tells you to, to achieve dual channel.

From the stats you posted, Runs is kind of low / strange / concerning, but fundamentally those stats seem to indicate you are "fully loaded"... so we'd need to look elsewhere to figure out.

Hop into Discord to chat with me, if you like.

Check to make sure your memory is in dual channel configuration on the physical motherboard. Also, give version 0.2.3 a try, latest (0.2.4.1) improved affinity for some cpus and did not improve it for others... still figuring out best config, hard to do as I don't have any ryzens to try on...

Fairly sure that is not what I stated, but feel free to expand on why it led you to that conclusion.

From my understanding and current code layout, concentrated "attack" on ARO in this fashion would just lead to legitimate, non-participatory nodes having a very large blacklist locally as none of the blocks from the bad apple nodes would be accepted, whether solo mined, mined on "bad" pools, or any other fashion. It'd behave more like a fork, with a segment of the network hashing away on a blockchain now totally disconnected from the rest of the network. "Good" miners on this "attack" fork would get all their nonces rejected on the "bad" pools; all the "Bad" miners on this "attack" fork would get all their nonces rejected on the "good" pools.

It would be easy to spot, and for owners of nodes that care, easy to bypass. It would not be possible in this fashion to "subvert" the legitimate network nodes.

Didn't see anyone else reply to this but it seems important to mention

This isn't BTC. Fees are fixed, common, known and non-variable (same rule against all transactions). Block size is variable based on past block's nearness to size cap. But, what decides transaction inclusion? Miners? Nope. Nodes. So, the health of the network -- its vulnerability, so to speak, is controlled by the distributed nodes, not the miners. 50-60-70% "mining" ownership doesn't confer any special power to determine block direction. If they run a solo mining gig and attempt to alter transaction / mempool, all the other nodes will reject them. It'd be good to do a more rigorous analysis on the vulnerabilities, risks, and benefits of this approach vs. the BTC approach, but the traditional mining-based 51% rule quite literally does not apply here.

Hope that helps a bit.

Safe to ignore. Try using fewer threads (edit config.cfg and find the only number near the end -- reduce it by one) and retest to see how it impacts your H/s -- some people get a little bit more if they use fewer hashers, varies from computer to computer.


Streams = # of threads active

Runs = kind of, how many "kernels" are run on each thread during last reporting period

H/run = how many hashes are done in each Kernel.

Cur H/s = The instantaneous hashes per second based on the executed kernels

Cur TiC% = an estimate based on wall clock vs. recorded times in the threads, how much CPU time the threads are getting. It is not super accurate, anything over 80% is usually good

Cur WL% = an estimate of "wait loss" or how long new kernels are sitting around waiting for old kernels to complete. Ignore it; just a kind of statistic for advanced tuning.

Argon % = within the kernels, how much time is spent computing Argon2i hashes, in %. Over time should trend towards > 99.99%

Sha % = within the kernels, how much time is spent computing the 5-rounds SHA-512, in %. Will be very small.

Shares = raw # of nonces found, including rejected

Finds = raw # of blocks found, including rejected (todo: I will exclude rejected)

Reject = raw # of nonces that failed to confirm, due to "bad timing" -- block update during submit -- network problem, or any other rejection (perhaps you OC'd too hard and math errors...)



Hope that helps!

At present, the library has special code paths for AVX, AVX2 and AVX512f. I hope to include some additional optimizations, but they will probably be along the SSE path; I haven't evaluated if AES instructions would offer any speedup.

Would be happy to help you out via discord channel, just pm me -- ProgrammerDan there.

If your hash rate is relatively low, your rate of finding hashes will be low. The pool functions as follows:

Each nonce discovery earns you "shares" on the current block, based on the "DL" of the nonce you found. The lower the DL, the more valuable the nonce and the more Shares you earn for that block.

When the block is finally discovered by the pool, everyone with shares on that block get a % of the discovered Arionum based on the sum of the Shares they earned within the block.

The shares are then added to the "Historic" shares. Anyone with shares in Historic are also paid out when a block is found by the pool, based on the % of shares they have vs. total shares in historic.

This is to benefit both fast miners and long-term miners. So your 5 nonce discoveries will have earned you Arionum (1) on the same block as when you submitted the share (2) on subsequent blocks. Historic shares decay by some % each new block that is discovered, they don't remain forever.

The pool pays out to Arionum Wallets once you've earned 10 Aronium on the pool.



As for frequency of discovering a nonce, this is related to "overall pool difficulty". The difficulty has been bouncing between 100 and 150m    (shows inverted in miner -- 50m to 100m) -- and I've been seeing a share discovery on average every 25,000 hashes.

So, if after 15 hours you've found 5 hashes, I'd suspect your H/s is between 2 and 5h/s.


Discovery of nonces is random; the prior analysis is only applicable for a large number of hashes. In my case, the average I quoted is based on 2 days of continuous mining and 2.35 million hashes.

Hope that helps some folks.

GPU miner is free, the developer (guli) just asks for small donation % of mined (default 1%):

https://bitbucket.org/guli13/arionum-gpu-miner

enjoy!

This is pretty typical!

Yes, you absolutely can.

I usually do Folding@Home on GPU while mining ARO on CPU. They leave each other alone, works great.

Allocate and reuse the memory that Argon hashes within. 512MB is reserved per hashing thread, and not released or deallocated until the entire program is terminated.

Something you'd never, ever do if you cared about secure argon2i hashing, but for speed hashing...

New release of Java Miner w/ prebuilds for Windows:

https://github.com/ProgrammerDan/arionum-java/releases/tag/0.2.3

I strongly recommend updating. Testing users saw 25-50% increase in hashing speeds. In some rare cases, 100% increase. This will vary from system configuration to configuration. Tested ~24 hours on my test systems (i7 7700k, Atom 2.4Ghz) with many successful share submissions.

Current benchmark changes:

Linux Mint 18.3, i7-7700k: 11.25h/s ---> 14.25h/s

Windows 10 Pro, i7 6600U: ~2.5H/s --> 6H/s