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

If your IP is 198.175.x.x please PM me. It looks like something is wrong with your node, and I'd like to get to the bottom of it. Thanks.

EDIT: resolved

It went as described hashrate from 5.5 to 22 and diff from 7 to 60 (Linux Mint Qiana / Pentium(R) Dual-Core CPU       T4300  @ 2.10GHz)

I'm an angel of common sense
99% of forum members are very far from understanding many important details. They can't "verify signatures" but have to trust instead (light-client model in social communication). This is dangerous in case we talk about privacy. I can't promise to read the thread but you can ping me with PM.

It will be very interesting to see details about relative CPU / GPU performance of light version and native C++/asm hash rate on actual embedded CPU.

Hardfork is possible only in case people agree with. It's easy to change PoW with low hashrate network. Later there will be a lot of miners against because they already invested into HW. Bitcoin is the best example.

Those are good suggestions dlightman!

What is your level of interest? You are obviously quite knowledgable so I hope you stick around and contribute to this coin!

I'm going to stick with the CryptoNight Lite experiment for now and see how it goes. I expect this coin to be in an active development phase for some time with a number of necessary hard forks so if things don't work out we can always change it.

Scratchpad in RAM is about 8-10 times slower than scratchpad in cache. Speed on embedded CPU depends also on x64 mul/div and aes-ni. Emulation of both will be really slow. Do you plan to remove these instructions also?

In case of low-end device and light-client being two days behind it's probably more user friendly to start from transactions (check if there is some incoming coins). In case there are some incoming transactions you can display amounts as not verified yet and check PoW in the background. This way user will wait several second for downloading and transactions verification.

Exactly, yes, that's why I called them a "lightweight client model"


Full nodes will still verify signatures (but as I mentioned earlier this is not critical path).


It could be. If you are two days behind when you open your wallet, that is 144 seconds to sync. Quite a long wait.

Also, I'm not sure that 10 h/s is achievable on a mobile device with scratchpad in RAM. Maybe, but that is aggressive. It is more realistic if scratchpad is in cache.

In case a node doesn't verifies signatures we don't have to consider it as a full node i.e. we can't rely on such node's decisions because they will accept correct PoW with wrong signature. We have to consider such nodes as light wallets. Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

Let's calculate scratchpad reduction benefit for a low-end device in case of current block verification:

- 120 seconds block target time
- 10 h/s hash calculation speed

In this case one block verification takes 0.083333% of one CPU core time. Is this a showstopper for mobile device?

I edited above to mention that I will be adding a lightweight client model that does not verify signatures.

Also, in current CN coins, even putting aside the low-loaded chain issue, signature verification is quite fast compared to PoW and is not fully optimized. Even with a moderately loaded chain, CryptoNight PoW will be significant for full nodes. Finally, signature verification is not critical path; PoW verification is.

For current blocks relative time of PoW calculation is less than total signature verification time. The only scenario where you get significant advantage from fast PoW in block verification speed is a low-loaded chain.

I've looked at the range of CPU designs and roadmaps and I'm pretty sure that 1 MB/core is a better sweet spot than 2 MB/core, for at least the next several years, in addition to being 2x (or a bit more) faster. 2 MB isn't even optimal on most current higher end desktop and server CPUs, and is definitely a poor fit for anything below that

I will be evaluating the GPU performance but I don't expect a large change, in fact the ratio may improve.

No, checkpoints don't address verification because verification and sync speed both matter even (or perhaps especially) for current blocks. I will also be adding an SPV-like lightweight client model where signatures will not be verified but the block header must still be verified.

As far as mining rigs with embedded CPUs, maybe (and is indeed already possible with the original cryptonight, as the are some embedded CPUs with 2mb/core, but they are rare), but I don't really see it as competitive with people mining on the enormous installed base of embedded CPUs that already exist with zero capital cost. Note this is different from GPUs since high end GPUs are not a mainstream product.

I've stressed the most important part of quoted text.

I don't think that reduced scratchpad will give significant benefits to anybody because:

1. 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon.
2. Signature verification time is more important than PoW verification time in case of 100+ transaction per block.

Proper implementation of checkpoints will solve the full chain verification problem better than scratchpad reduction.

From the other hand small scratchpad will remove one of ASIC / GPU protection layer. It will be easier to build dedicated mining hardware: for example one can assemble a mining rig with embedded CPUs. I don't think that this is a desirable.

Can you measure relative GPU advantage over CPU with reduced scratchpad?
Original CryptoNight implementation is very good from this point of view: GPU is about 2 times faster. This is quite fair.

To make it faster to verify and more efficient on mobile and mainstream (not high end) desktop CPUs. See roadmap

Hello!

What's the purpose of changing PoW?

Minimum mining reward

When created this coin was a clone/fork of Monero. At that time Monero did not have code implementing the minimum reward, although that was always part of the Monero specification (as being <1% inflation per year) and has recently been added to the code (though will not have any effect for approximately eight years).

As currently described, the mining rewards of this coin will decline quickly to a negligible level and will eventually go to actual zero. I believe this is unsound for any decentralized PoW coin, but also especially unsound for a coin without a fixed maximum blocksize, and my intent is to bring the structure fully back in line with Monero by merging the code for the minimum mining reward.

This arguably represents a small change in the specifications (though in some sense not since there is no divergence yet and won't be for several years), and one which will make the coin less deflationary or possibly somewhat inflationary. Actually being inflationary is in fact quite unlikely in practice since lost coins will likely exceed that rate of new coins in the final "minimum reward" state (especially with the pruning of stale outputs).

If there are strong objections to making this change, I will have to consider leaving the code alone and making a new fork instead.

Mine ("Works for me. Hash rate went up about 3.5 times, dififculty 10 times. Everything else seems fine.") was Fedora 20 on x86_64.

These days it's very rare thing to see dev as dedicated as you.

There is no exchange, only OTC trading. https://bitcointalksearch.org/topic/aeon-buy-and-sell-thread-1012944

I would like to push getting back onto exchanges once the latest software updates are done and I have seed nodes set up to restore normal service (i.e. people can actually download and run the software without assistance which is not the case now).

I've placed an order for a dedicated seed node in a data center to be paid out of my pocket for now (possibly the donations fund can cover the cost later).

Nobody knows, no exchanges.

what is the actual price now?

Thanks for the test reports. Please note the OS and hardware if possible. Thanks.