[ANN] AEON: Scalable, private, mobile-friendly cryptocurrency

[smooth]

What's the purpose of changing PoW?

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

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.

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

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. 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.

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.

[dlightman]

What's the purpose of changing PoW?

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

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.

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

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. 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.

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 that 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 matters even for current blocks.

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.

[smooth]

What's the purpose of changing PoW?

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

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.

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

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. 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.

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 that 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 matters even for current blocks.

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 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.

[dlightman]

What's the purpose of changing PoW?

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

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.

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

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. 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.

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 that 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 matters even for current blocks.

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 edited above to mention that I will be adding a lightweight client model that does not verify signatures.

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?

[smooth]

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.

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

Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

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

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?

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.

[dlightman]

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.

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

Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

Full nodes will still verify signatures.

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?

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.

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.

[smooth]

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.

[dlightman]

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.

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.

[papa_lazzarou]

Release Phoenix standalone test (PLEASE TEST!)

I have created a standalone test setup for the upcoming release Phoenix. Please test and report any issues.

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)

[smooth]

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

[h0g0f0g0]

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA

[smooth]

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA

Thanks!

Reminder, this is a bench test and does not connect to the live network. See test instructions here: https://bitcointalk.org/index.php?topic=641696.msg11299446#msg11299446

[nikos64]

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA

Well, the Windows build synchronized with the main chain in the AppData\Roaming\aeon directory.
Didn't supposed to do that, right?

[muchoman]

Windows build does not work for me and there is no aeone dir.

[smooth]

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA

Well, the Windows build synchronized with the main chain in the AppData\Roaming\aeon directory.
Didn't supposed to do that, right?

That is strange.

I don't know what those builds are. I would hold off on trying them until h0g0f0g0 explains what he built. Sounds like maybe he didn't switch to the branch before compiling.

[smooth]

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.

I got in touch with the node owner and we diagnosed a firewall problem. Fortunately, no impact on the network although he did lose some mined blocks (orphaned).

Here's an update on the donation balance. Nothing has been spent from the wallet:

balance: 113845.066127230582, unlocked balance: 113845.066127230582

[smooth]

Seed node is now up, and github master has been updated accordingly.

If you are already connected to the network this does not affect you, only new users.

[h0g0f0g0]

Updated binaries (with seed node included):

Windows:

https://mega.co.nz/#!IIcWyYgA!9oFezJX1YKSpI_wUgjTEEYB9Fch5ViDH-wsZ_R6WpXo

Linux:

https://mega.co.nz/#!gM1XQLqb!R5oCb_nlEtAvqlw5esiQelfNmuQj-IWo3gWHg2BVC4w

These builds are made by following steps described in op to save time for others. If it's not working please post an error message or screenshot but for me it worked fine on both OSes.

[Phantas]

Updated binaries (with seed node included):

Windows:

https://mega.co.nz/#!IIcWyYgA!9oFezJX1YKSpI_wUgjTEEYB9Fch5ViDH-wsZ_R6WpXo

Linux:

https://mega.co.nz/#!gM1XQLqb!R5oCb_nlEtAvqlw5esiQelfNmuQj-IWo3gWHg2BVC4w

These builds are made by following steps described in op to save time for others. If it's not working please post an error message or screenshot but for me it worked fine on both OSes.

Thank you for your support

[Arux]

Release Phoenix standalone test (PLEASE TEST!)

Done, windows 7 64 bits on intel Penryn/Harpertown (no aes instructions) / 4gb of ram

...blocks being mined with a block target of 1 second, with the difficulty converging to your hash rate

happened

Once you get to block 1000 ... see the difficulty increase by a factor of 8, your hash rate double

#1000: diff 18 --> ~140-150   hashrate: 18-->41

test perfomed with my own building according to the OP instructions (thanks to Cryptrol  )